(not having really followed the thread, just chipping in on building
stuff)
At the moment this isn't used in all base headers (and gui still lags
behind, there we only have cleaned up most of the implementation
files).
What I don't see is how this mechanism could have helped in your
case.
Agreed ... it seems to me that it is correct behavior for gui to
build using the *installed* base library.
When building base, base should use its own headers, not the
installed ones.
When building gui, gui should use its own headers, not installed
ones, and so on.
But gui should use the installed base headers, and back should use
installed base and gui headers.
That's because base, gui, and back are all separate packages.
Yes. :-)
Anything else introduces dependencies between the packages that make
maintenance too complicated. ;-)
Now, it might be nice to be able to build a core package entirely
standalone without reference to installed headers, but I think
that's a special case we haven't addressed ... it would presumably
need a mechanism to tell gnustep-make to refrain from looking for
installed headers (eg by supplying a special version of GNUstep.conf
and using the environment variable to get it used instead of the
default one).
There would be various ways of doing this. They all involve
installing "temporarily" gnustep-base somewhere locally (either using
a special local GNUstep tree, or using DESTDIR),
then using the locally installed gnustep-base headers. I'm not sure
that it is really particularly useful ... I can't really think of a
good reason why the standard procedure of compiling/installing
packages separately wouldn't be good enough. You can always use a
script if the problem is not wanting to type 'make / make install'
multiple times :-)
Thanks
_______________________________________________
Gnustep-dev mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/gnustep-dev
