an argument of make(1)

[Chuck Robey]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I am posting this to our arch list; if I'm wrong, we can move this.  I want to
argue for some changes to our great make(1) tool.

I've long been a fan of make, and in particular, FreeBSD's make.  In my own
career, I've often had to do more custom creation of Makefiles, and while there
are some folks here who definitely DO know our make better, I think I can
honestly say I know it pretty well.  In creating tools for customers, I've
often been forced, unwillingly, to go to the GNU make tool.  The reason is just
one of compatibility.  There are several different reasons for this, which I
want to list:

1) while the GNU make has the -v to allow one to both identify the tool and the
version, FreeBSD's make has no such facility, that I'm aware of.  You can't test
& capture the type of make here, except by the rather inadequate trapping of
getting no response at all.

2) while some parts of our make don't advertise it, they can be made compatible
to the gmake's tools.  "include" is a good example (the FreeBSD "include" docs
claim that it only works as ".include", but that's a prevarication (and a very
good thing it is).  What I'd like to argue for is that some things like "if"
have their compatibility with gmake enhanced.  No, don't make it a mirror image,
just make it possible for a programmer to craft a limited set of tests that will
work in both places.

If you give programmers the ability to detect what make they're in, the ability
to craft a limited set of compatible tests, and also the other side (endif
stuff) then everything else for portability can be done by using those limits.

If something like this were done, then it allows a programmer, finally, to write
a REALLY portable makefile.  It would still allow one to make use of all of
make(1)'s great command set, but not to kill it's use in a gmake-only system.

OK, that'st the major argument.  I'm going to ask for one thing here, but it's
truly extra, just my own bias's showing thru.  I wish that a fair number of the
changes that have gone into make be taken back.  I'm not talking about those
that enhanced it's operation, I'm talking about all of the changes that, while
trying to increase the elegance of the code, have really destroyed it's porrting
portability, in a major way.  Make used to depend on a smaller set of libraries,
and those libraries were largely those available on other systems, so the task
for a programmer, to port our make(1) to a different platform wasn't all that
hard to do.  Nowadays, with a great number of the changes having been crafted to
change dependencies to FreeBSD-only tools, it's a real bear to port it.

The code involved is nearly all very, very portable; it's the way that the
libraries have been constituted that makes porting this a really bad job.  If
someone would make up a libmake.so.1, which in itself could be make really
portable, that would also go a great long way to improving the popularity of our
make(1).  I'm NOT asking to roll back any of the distinct improvements that have
gone in, only the changes that ruined it's porting-ability (yea, that's
portabilty, I just wanted to really point that out again).

OK, if someone were to come up with swuch a set of changes, would they be dead
on arrival?  I know that no one gets prior approval for FreeBSD (I completely
agree with that), just didn't want to be totally at odds with everyone, if I'm
the only one who sees it this way.

Thanks for your time.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAki1iEUACgkQz62J6PPcoOkniQCfWg+wlDrQ6rC+g2jGip12Q1VF
koQAnRv4Sjs6xnebEEipKcGF1lXYZmRP
=6ike
-----END PGP SIGNATURE-----