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

[Daniel Crawl]

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