[Chicken-hackers] [PATCH] Small improvement in Make's handling of variables, and a question about other common variables

[Peter Bex]

[CCing Felix as he may have valuable historic insight and advice on this]

Hi all,

As I noticed in the pkgsrc script for building CHICKEN, we're being
somewhat inconsistent and incompatible with common UNIX practice in
our handling of user-settable variables in the Makefiles.

Some like PREFIX, DESTDIR and PLATFORM but also C_COMPILER etc, can be
provided from the environment.  When Make encounters an undefined
variable or a variable assignment using the "?=" operator, this Make
variable will get the value from the corresponding environment variable.

This is highly undesirable for "internal" variables, but for those
which are user-settable like the ones I mentioned and various directory
prefixes, that's a Good Thing, as you can set environment variables in
your shell startup file and all Makefiles will pick up on them.  There
are some typical conventions on what variables will be accepted (but
those don't seem to be formally standardized anywhere I can see, except
for http://pubs.opengroup.org/onlinepubs/9699919799/utilities/make.html;
more on that later).

Anyway, long story short, I think it's a good idea to stick closer
to commonly found conventions and to allow all the configurable
directory prefixes to be copied from the environment.

This patch does that, but it also changes the meaning of two variables:
INCDIR points to the chicken-specific directory, which is kind of
dangerous if there's another program which also uses this variable
name to indicate the toplevel include dir.  *usually* this is called
INCLUDEDIR, though, so I've decided to introduce this option and rename
INCDIR to CHICKENINCDIR "just in case".  You'll notice that this nicely
matches the CHICKENLIBDIR which was already there.  It's also clearer,
as you would expect INCDIR and LIBDIR to be at the same "level", but
it *will* break the install for everyone who was overriding INCDIR.
Luckily, INCDIR isn't documented ;)

The other one that changes is MANDIR.  Unfortunately, common convention
is that MANDIR points to /usr/man, and MAN1DIR, MAN2DIR etc point to
the specific directories for these manual sections.  So, this
had to change unfortunately.  Otherwise, making this variable settable
from the environment would break the build when people have MANDIR set
to the usual meaning.  I guess MANDIR won't be overridden too often
anyway except by packagers (who should be paying closer attention to NEWS
than "ordinary" users), so I think this breakage is acceptable.

Finally, regarding the Make page in the Single Unix Spec; that mentions
tool names like CC, LD and options like CFLAGS.  It might be worthwhile
trying to switch to those conventions, but for two things:

- It would probably break a lot more usages than the MANDIR and INCDIR
   changes, because people will be using specific C compilers more
   often (even if it's just a different version of their compiler).
   Linkers and assemblers less so, probably, but it may be done.

- I'm unsure how cross-compilation is usually handled.  There's only
   one "CC" AFAIK, but CHICKEN needs (at most) three, in order to
   distinguish between compiling this machine versus on the host
   (when cross-compiling CHICKEN itself to another "host" platform)
   the target machine (compiling with CHICKEN on the host machine to
   another machine to run the final program on).

So, all in all, it may be safer to avoid re-using the common CFLAGS etc.
My patch doesn't touch the tool variables because I think this warrants
more up-front discussion.

However, it is possible to inherit those the host and target C compilers
from $(CC), like we do now for $(C_COMPILER).  Nothing would really
change there.  One advantage is that if you _don't_ set C_COMPILER,
it will use the default built into GNU Make, which is probably a good
default as good package managers will try to override that value when
building binaries for a particular OS.  This potentially means less
fiddling with variables when building CHICKEN.

But, like I said, it will probably break a shitload of scripts and
programs.  To remedy that we can let C_COMPILER / C_COMPILER_OPTIONS
inherit from CC / CFLAGS by using "?=" judiciously:

######################################################################################################
# Optionally start with this:
ifneq ($(origin C_COMPILER)$(origin C_COMPILER_OPTIONS),undefinedundefined)
$(warning $$(C_COMPILER) and $$(C_COMPILER_OPTIONS) are obsolete; use $$(CC) 
and $$(CFLAGS) instead)
endif

C_COMPILER?=$(CC)
C_COMPILER_OPTIONS?=$(CFLAGS)

# and keep, unchanged:
TARGET_C_COMPILER ?= $(C_COMPILER)
######################################################################################################

This will allow us to gradually phase out C_COMPILER; we obsolete it
first, then after 4.10.0, maybe change $(warning) to $(error) and
finally remove it in 4.11.0.  This means it won't immediately break
existing scripts or configs which override C_COMPILER.

Thoughts?  Ideas?

And, at Felix: what was the reason you didn't use CC but your own
C_COMPILER variable?

Cheers,
Peter
-- 
http://www.more-magic.net

0001-Make-the-handling-of-variables-for-directory-prefixe.patch
Description: Text document