JAVA_HOME vs. FHS [was: Re: SableVM SDK - suggested patch]
"Grzegorz B. Prokopski" <[email protected]> Sat, 21 May 2005 16:10:40 -0400
| Newsgroups | gmane.comp.java.vm.sablevm.devel |
|---|---|
| Organization | SableVM - LGPL'ed Free Java VM http://sablevm.org |
| Message-ID | <[email protected]> |
On Sat, 2005-21-05 at 00:00 -0400, David Bélanger wrote: > What about this patch for SableVM SDK? > > It specifies bindir, libdir, ... via module specific configure > options. Ok, let's first see what would be the best approach here. The problem is that we have *two* standards to follow. One is FHS, which tells us where to install binaries, native libraries, manual pages, and other architecture-independant data. The other is the de facto standard which is JAVA_HOME structure. Ideally we should try to conform to both. The current solution in SableVM SDK is imperfect. For example I simply drop the binaries to something like /usr/local/lib/sablevm/bin, and jars to /usr/local/lib/sablevm/lib. This is easier to do and follows the latter standard, but not the first one. What I see as a solution here, is to install all our binaries into standard FHS locations, but give them -sablevm suffix (like we do already for some of them) to avoid conflicts with system-wide installations if they are done after, or if we're asked to install our versions. Then in JAVA_HOME - only put (relative!) symlinks to these binaries. The same for .jars, which should go into sth. like /usr/local/share/sablevm, as architecture-independant data, and for manuals, which would go into /usr/local/man/. I'd be glad to hear any better ideas, but unless you have some, it would be best to work on patches would realize the above solution. So yes, the $prefix/lib/sablevm would pretty much become a symlink pool, which I don't think is any problem (just make them relative, not absolute). Actually, having binaries and manual pages for them installed in FHS locations means easier access to manuals, which is not the case when they're hidden in /usr/local/lib/sablevm/man dirs. The last, but not the least. Altough I prefer to make only minimal changes to upstream sources, I would not be afraid of cosmetic changes like changing names of the binaries [*]. If you have any questions about some general ideas or solutions behind SableVM SDK build system, etc. I'll be glad to answer. HTH, Grzegorz B. Prokopski [*] When changing the names of binaries bear in mind, that in SableVM SDK there are scripts in 'bin' source directory (they're used at stage 3-'EXTRA' of compilation/configuration), which refer to not yet installed binaries, libraries, jars etc. So you need to update them if the names of not yet installed components change. -- Grzegorz B. Prokopski <[email protected]> SableVM - Free, LGPL'ed Java VM http://sablevm.org Why SableVM ?!? http://sablevm.org/wiki/Features Debian GNU/Linux - the Free OS http://www.debian.org