an argument of make(1)
Alfred Perlstein
alfred at freebsd.org
Wed Aug 27 17:45:31 UTC 2008
The only excuse I have for top posting here is that I agree
with the entirety of this email.
-Alfred
* Chuck Robey <chuckr at telenix.org> [080827 10:28] wrote:
> -----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-----
> _______________________________________________
> freebsd-arch at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"
--
- Alfred Perlstein
More information about the freebsd-arch
mailing list