>> Things should be decoupled ... -make and -base don't really talk or depend >> on each other. > > Not entirely true. Currently -base depends on -make for configuration. >
Thanks, I see your point ... which is a very good one :-) You're suggesting that, for example, in a binary distribution (say, Debian) you could install gnustep-base without installing gnustep-make. Then you can also install any other GNUstep software that is binary packaged by the distribution. You don't need gnustep-make, because everything is in the FHS locations and you're not building anything, you're just installing binary packages. I agree it would be a nice thing :-) In that case, yes, you would need GNUstep.conf, yet you have no gnustep-make installed. I suppose the right way of addressing the issue is to create a 'gnustep-common' package, that only installs GNUstep.conf. Then, on top of that, you can install gnustep-make and/or gnustep-base; you only install gnustep-make if you want to build. We could make all this explicit by extracting the creation of GNUstep.conf into a separate software ... to be installed before gnustep-make. It sounds very clumsy though ;-) At the moment, I'd leave everything as it is (a packager could still install GNUstep.conf in a separate package to get the effect above). Moving the creation of GNUstep.conf into gnustep-base doesn't make much sense, because gnustep-make can't work without it. You may want to use gnustep-make without gnustep-base (eg, for building documentation or resources or java stuff, or for building using non-gnustep-base foundation libraries, eg on apple-apple-apple or gnu-fd-nil), and at the moment you can't build gnustep-base without gnustep-make anyway ;-) Anyway, good idea to keep it in mind, I mean, yes, conceptually, the step of creating GNUstep.conf is separate from gnustep-make and gnustep-base. It's a "preliminary" step if you want. ;-) >> Yes ... we're not really "almost done". :-( ... we also need to have >> gnustep-base load >> the directory structure from GNUstep.conf and use it when searching for stuff >> at runtime :-/ > > For long lived processes this might be fine but for short lived tools you're > imposing a considerable startup delay. There is already such a delay, since we are already reading GNUstep.conf. I doubt adding ten more lines or so to read would make any difference in speed. If we could avoid reading the file altogether, that would be faster. ;-) I imagine the 20 lines GNUstep.conf file will always be in the kernel cache so it will all be extremely fast. Maybe we could benchmark it, but even for a Unix command-line utility that has to be as fast as 'grep' or 'sed' or those thingies, I'm not sure it would make a measurable difference. If it makes a considerable difference, presumably you'd disable GNUstep.conf and just run from hardcoded values. That would work and be as fast as you can get :-) > I added PLATFORM_SUPPORT as a step in avoiding that. > > If you said something like: > > GNUSTEP_INSTALLATION_DOMAIN=PLATFORM_LIBS > > you'd get your library installing into /usr/lib and so forth. > > So any GNUSTEP_* spec uses OpenStep domain layout. > Any PLATFORM_* spec uses the local platform specifics. Oh ... I see. I looked at that ... but the current idea/trend is rather that, when you use the Unix FHS (for example), the GNUstep dirs are mapped onto local Unix FHS dirs. All access to the dirs goes through the API anyway. So, GNUSTEP_SYSTEM_ROOT/Tools ends up mapped into /usr/bin. GNUSTEP_LOCAL_ROOT/Library/Libraries is mapped to /usr/local/lib, etc. Of course the libs have to do the mapping from the GNUstep API to the native filesystem. This mapping comes from GNUstep.conf (or is hardcoded in the lib). So, rather than have both the GNUstep filesystem and the native filesystem in the same installation, you'd have either the GNUstep one or the native one. ;-) Thanks _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev