Re: GNUstep framework install question

[Nicola Pero]

> Anyhow, I've then noticed that there are no make variables like $(AWK) 
> or $(SED) available like they used to be in the NeXT make process. How 
> does one cope with the situation where one should use i.e. nawk instead 
> of awk? Just curious ...

Well - the problem is that SED and AWK would be set to be the sed/awk
which were available on the system when gnustep-make was *configured*.

With GNU/Linux, where people normally update their systems very often and
mess them up a lot, I can easily see the situation where they configure
and install gnustep-make with a version of awk, then later on they change
the awk they're using, and the AWK variable in gnustep-make would no
longer be correct.

So, if gnustep-make does hardcode at configure time the full path to AWK,
SED and all other unix tools, you would need to reconfigure and reinstall
gnustep-make each time any of these tools is changed!  <sure that would be
possible if the whole system was built around gnustep-make :-) but it's
not>

I think normally it should be safe to expect 'sed' and 'awk' to point to
the preferred sed and awk tools available on the system ... if someone
wants to use mawk instead of gawk, normally he would use symlinks and PATH
to have the system find the preferred awk when awk is requested.  I'm sure
on systems (eg Debian) where you can have multiple awks, the preferred one
is always available as awk.

So - I think using 'awk' is fine - that should automatically give you the
preferred awk available on the platform, if the platform is set up
correctly. :-)

But perhaps your question is another, more subtle one ... What we could do
is, add

SED = sed
AWK = awk

to the gnustep-make makefiles.  That way, everything behaves exactly as it
does now, but it allows you to change the awk used in a specific run of a
GNUmakefile by doing

AWK=mawk make

I'm in favour of doing this, but ... but in my experience, as soon as we
add

SED = sed

to the makefiles, someone will soon submit a patch which looks up sed in
configure.in, then sets

SED = @SED@

which as I explained before it's going to cause more problems than it
solves.  So if we add SED = sed and AWK = awk, we need to add verbose
comments trying to explain to people that we define SED and AWK so that
they can be overridden on the command line, but that actually 'sed' and
'awk' are what we always want to use.

Let me know if I misunderstood your question :-)