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

[Thomas M. Parris]

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