Follow-up Comment #14, bug #25356 (project gnustep):
I managed to reproduce this, and to track it down.
First of all, if you do './configure' directly inside Source/pathconfig, the
correct installation domain (SYSTEM) is used.
The problem only occurs if you do './configure' at the top-level. In that
case, the wrong installation domain (LOCAL) is used. This is down to
gnustep-config not being able to locate installation-domain.conf; and this is
because installation-domain.conf is expected to be found in the same directly
as GNUstep.conf, but GNUstep.conf in this case is wrongly assumed to be in
./GNUstep.conf.
What seems to happen is that the top-level ./configure sources GNUstep.sh
before running pathconfig's ./configure. That causes GNUSTEP_CONFIG_FILE to
be set to what should be at runtime (./GNUstep.conf) instead of what it is at
compile time (/etc/GNUstep/GNUstep.conf).
Is there an easy way to decide at what stage to run the sub-configure ?
Else, maybe we could remove the separate Source/pathconfig/configure, and put
the path config code back to where it was (before GNUstep.sh is sourced), with
the additional benefit of speeding up the configuration (sub-configures are
slow as they duplicate a whole bunch of tests (host, target, etc) that are
already run top-level). :-)
Anyway, I'll look at it in more detail tomorrow.
Thanks
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?25356>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
_______________________________________________
Bug-gnustep mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-gnustep
