Re: gnustep-make experiment

[Nicola Pero]

>> So we could have a small makefile fragment, let's call it find- 
>> gnustep.make,
>> 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
>> gnustep-make.
>
>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  
>automagically.

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) \
 $(wildcard /System/Library/Makefiles))

the result is that:

 * if you source GNUstep.sh or have your GNUstep environment properly setup, it 
gets used

 * 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 
environment variable
set whatsoever.

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, 
then reading
the actual makefiles fragments from gnustep-make's directory would be the 
dominant factor
anyway!).  So, no, it really doesn't matter.  I even timed it and I can't see 
any reproducible
difference.


>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  
>autoconf configure).
>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 
somewhere.

Thanks