[kepler-users] Advice on proper handling of platform specific binary libraries

[Chad Berkley]

Hi Tom,

I haven't had a chance to fully digest your email yet (been busy on 
another project), but just thought I'd point out that the build system 
has something like this already built in for java code.  The 
osextension.txt file can be used to add compilation/runtime dependencies 
to specific classes based on the OS.  See the apple-extensions module 
for an example.  The build system checks to see if a module has the 
osextension.txt file in it's module-info directory, then only compiles 
and adds to the classpath the files that are for the current OS.  This 
is documented here:

https://kepler-project.org/developers/teams/build/documentation/build-system-instructions#OSSpecificExtensions

I haven't tried to use this for native code, nor was it developed for 
that purpose, but it could probably be extended to do so pretty easily.

Let me know if you have any questions.

chad


Thomas M. Parris wrote:
> Absolutely!  Thanks for your help.  I'm working on this now.  I tried
> Approach #3, but the search path for the dlls can't find the libraries
> stored in another module.
> 
> -- Tom
> 
> -----Original Message-----
> From: Daniel Crawl [mailto:crawl at sdsc.edu] 
> Sent: Friday, June 25, 2010 4:44 PM
> To: Thomas M. Parris
> Cc: 'Kepler Users'
> Subject: Re: [kepler-users] Advice on proper handling of platform specific
> binary libraries
> 
> 
> Hi Tom,
> 
> I like approach #1 since it provides better encapsulation than the other
> approaches.
> 
> The build system can be updated to do this. However, I only have access to a
> small number of platforms, so if I send you my updates, are you willing to
> test them?
> 
> Thanks,
> 
>    --dan
> 
> On 6/25/10 8:48 AM, Thomas M. Parris wrote:
>> [I sent the following to Kepler-Dev last week.  But it probabably got 
>> lost in the flurry of work surrounging the 2.0 release (congrats!).  
>> So, I'm resending this slightly edited version to Kepler-Users. -- 
>> Tom]
>>
>> Greetings Keplerites:
>>
>> I could use some advice/pointers an the proper way to handle 
>> distribution of platform specific binary libraries through the Keple 
>> build system for a local workgrop module.
>>
>> Background:
>> 1. We have succesfully integrated our own local module (isciences) and 
>> associated svn repository into the Kepler build process.  It works 
>> very well.  Developers can post new/updated actors and everyone else 
>> gets them (along with any other Kepler updates) when they "ant run"
>>
>> 2. Some of our actors make use of JNI to connect to legacy code (e.g., 
>> GDAL).  This worked really well when we were all on Windows 32 bit 
>> platforms.  We just stuck the DLLs in the lib directory, added them to 
>> the svn repository, and then we were off and running.
>>
>> 3. Now we have a mix of Windows 32 and 64 bit platforms and (to my
>> knowledge) different JNI DLLs need to be built for each platform.  We 
>> can do this.  But it's not clear to me how best to handle the file layout.
>>
>> Query:
>> 1. How to we set this up so the build process is both seamless for 
>> users on both platforms and transparent to the code for our actors?
>>
>> 2. Possible Approach #1: We can create subdirectories in the lib 
>> directory for each platform (e.g., Win32, Win64, MacOS, ...).  But 
>> then we need some mechanism to tell the build process to link with one 
>> subdriectory versus another based on the user's platform.  Is there an 
>> easy way to do this with the current build system?
>>
>> 3. Possible Approach #2: We create multiple versions of our module for 
>> each platform (e.g., isciencesW32, isciencesW64, ...) and have the 
>> user specify the one they want to use based on their platform in .  
>> This seems like an admin nightmare because it requires keeping the 
>> code base in multiple repostories in sync when the only difference is 
>> the contents of the lib directory.
>>
>> 4. Possible Approach #3: We create multiple versions of a local 
>> library module in addition to a core module for our actors.  In this 
>> case, we might create modules for GDAL that contain just the lib 
>> directories built for that plaform (e.g., GDAL_Win32, GDAL_Win64, ...) 
>> in addition to our module for actors coded in Java.  In this case, the 
>> modules.txt file would look something like:
>>
>> 	isciences svn+ssh://localhost/localpath
>> 	GDAL_Win32 svn+ssh://localhost/localpath
>> 	*kepler
>>
>> This would solve at least a portion of the administrative hassles with 
>> #3 above (though I think we would still need isciences32 and 
>> isciences64 "wrapper" modules that only contain the proper modules-txt
> data).
>> I'm probably missing something obvious, and would welcome any 
>> suggestions, pointers, examples of how others have addressed this issue.
>>
>> Many thanks,
>> Tom
>> ----------------------------------------------------
>> Thomas M. Parris
>> Vice President
>> ISciences, LLC
>> ----------------------------------------------------
>>
>> _______________________________________________
>> Kepler-users mailing list
>> Kepler-users at kepler-project.org
>> http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-users
>>
>>    
> 
> _______________________________________________
> Kepler-users mailing list
> Kepler-users at kepler-project.org
> http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-users