Guys, On 12/24/05, Leopold Toetsch <[EMAIL PROTECTED]> wrote: > > > On Dec 24, 2005, at 21:07, Nick Glencross wrote: > > > ... The configuration comes when the application is additionally linked > > with null_config.o, parrot_config.o or install_config. > > This was an initial attempt that allowed even an installed parrot to > find the runtime by linking a config file with it. Any improvements and > generalizations are of course very welcome. > As a shared parrot executable has to load the shared parrot lib anyway, > there is no need to keep the config in the executable for that case.
(This doesn't really follow on from Leo's comments) Although it's not a huge nuisance, it would be nice not to have to build the libparrot library twice. during the build. I guess there are possible approaches to avoid this, such as: * Build libparrot, and then augment it later with the correct config vars (Archive libs allow this, not sure if it is portable with shared libs) * Bootstrap install_config.o earlier in the build process so that it is can be placed in libparrot. In each case, if the install config is already in libparrot, then it should still be able to link against it with: $(LINK) main.o parrot_config.o -llibparrot # Simplified for example purposes That way, libparrot is ready for installation, but can be used in the build environment. The question is, is there a minimal amount of code that can create the frozen configuration data that goes into install_config.o, or is the whole parrot runtime required, in which case there isn't any benefit to thet latter approach...? Yet another alternative is just to build a small library out of install_config.o (e.g. libparrot_config.so or .a) which you would normally link with (e.g. -lparrot -lparrot_config). This doesn't sit too badly with another patch which I want to revive which makes the config vars optional for applications that don't need it (which might be rare, I know). Also, with pkgconfig people normally wouldn't know what they were linking with.... Nick
