Date: Wed, 27 Aug 2008 13:00:54 -0400 From: Chuck Robey <chuckr@telenix.org> To: FreeBSD-arch@FreeBSD.org Subject: an argument of make(1) Message-ID: <48B58846.6040400@telenix.org>
next in thread | raw e-mail | index | archive | help
-----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-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48B58846.6040400>