[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gnustep-make experiment
Re: gnustep-make experiment
Thu, 8 Feb 2007 14:13:32 +0100 (CET)
>> So we could have a small makefile fragment, let's call it find-
>> that searches for gnustep-make on disk and sets GNUSTEP_MAKEFILES
>> to the best
>> match. I'll write that makefile fragment, and it will be
>> maintained inside
>I don't get this one, you want to let the fragment search for gnustep-
>make? Where will it search? Isn't it expensive to search all
>locations everytime? I'm not convinced that this can happen
Here is an example -- put this at the top of your GNUmakefile, just before
include $(GNUSTEP_MAKEFILES)/common.make --
GNUSTEP_MAKEFILES = $(word 1, \
$(wildcard /usr/GNUstep/System/Library/Makefiles) \
$(wildcard /var/lib/GNUstep/System/Library/Makefiles) \
$(wildcard /usr/local/GNUstep/System/Library/Makefiles) \
$(wildcard /opt/GNUstep/System/Library/Makefiles) \
the result is that:
* if you source GNUstep.sh or have your GNUstep environment properly setup, it
* if you set GNUSTEP_MAKEFILES, it gets used
* if you have done none of those, the makefile will look for gnustep-make in
those standard locations
in the order; if it finds it, it will use it.
* else, you'll have an error
With this 'hack' and gnustep-make from trunk, I can compile stuff with no
Please note that this is just a draft to give the idea, we should polish the
code. Don't use
it in real projects yet ;-)
And yes, checking that those 5 dirs exist will be done every time so in theory
would slow down
your compilation. In practice, on any OS they will be in the kernel's cache
and you will
see no difference in compilation times (if read disk access really mattered,
the actual makefiles fragments from gnustep-make's directory would be the
anyway!). So, no, it really doesn't matter. I even timed it and I can't see
>My configure scripts has options to specify the gnustep-make
>installation you want to use (though of course it tests a few
>hardcoded locations as a fallback, but only once, at configure time).
>I think the 'configure' script should be maintained inside gnustep-
>make (the script which generates the config.make, usually not a real
>You probably don't want to run configure everytime you call make ;-)
Looks good. I suppose that could be another option (I prefer
would prefer a makefile fragment though). ;-)
In fact, if we put the makefile bootstrap code into a separate file, we
can do a lot better than the above. Ie, we can actually check that
GNUSTEP_MAKEFILES is set/found, and print a nice warning message if not.
At that point I'm not sure what is missing compared to a configure script.
It's better because you just type 'make' and here you go.
>>> BTW: personally I'm not quite sure whether I understand that /etc/
>>> GNUstep.conf thing :-) Is it necessary or optional?
>> It is necessary. The reason is that it allows gnustep-make and
>> gnustep-base to have a common understanding of where the various
>> directories are.
>> The GNUstep.conf file describes the GNUstep filesystem and both
>> gnustep-make and gnustep-base read it to know where to find things.
> Well, I'm talking about FHS, why would they need to know?
They would need to know because you can have different FHSes. Different
Linux distributions could/will put things in different places. Windows
does put things in different places. We will get asked to be able to put
things in different places. That's the whole point of the exercise ;-)
I suppose we could hardcode all values into gnustep-make and gnustep-base
but then they couldn't be relocated. If you can control the locations from
a config file instead, it becomes easier to relocate them. Relocating is often
a useful trick when building packages (eg), so it looked like a good feature
to have. :-)
> In an FHS the gstep-base just needs a (fallback) prefix like other
> libraries to know where to look for associated files. Eg
> ./configure --prefix=/opt/gnustep-base-15
Hopefully we can support the full standard range of GNU --bindir=...
--xxxdir=yyy options that let you configure exactly where you want
everything to go. That requires us to store those option values
Re: gnustep-make experiment, Helge Hess, 2007/02/10
Re: gnustep-make experiment, Nicola Pero, 2007/02/08