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:[email protected]] 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 > >
