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