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

[Thomas M. Parris]

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
>
>