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

[Aleksej Saushev]

  Hello,

Peter Bex <address@hidden> writes:

> 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 ;)

I couldn't find evidence for "usually INCLUDEDIR". NetBSD calls it "INCSDIR",
FreeBSD calls it "INCLUDEDIR", OpenBSD doesn't bother calling it, they use
"/usr/include" inline, autoconf calls it "includedir".

> 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).

CC points to the compiler. When cross-compiling it is cross-compiler.
In this case CFLAGS holds flags for this cross-compiler.

If, for some reason, you need other additional tools, you add them.
E.g. HOST_CC, HOST_CXX, HOST_LD, whatever (with variables to pass flags
like HOST_CFLAGS, HOST_LDFLAGS and so on).

> 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?

I like it.


-- 
HE CE3OH...