Date: Thu, 28 Aug 2008 04:12:58 +0300 From: Giorgos Keramidas <keramida@freebsd.org> To: Chuck Robey <chuckr@telenix.org> Cc: FreeBSD-arch@freebsd.org Subject: Re: an argument of make(1) Message-ID: <8763pmt011.fsf@kobe.laptop> In-Reply-To: <48B58846.6040400@telenix.org> (Chuck Robey's message of "Wed, 27 Aug 2008 13:00:54 -0400") References: <48B58846.6040400@telenix.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 27 Aug 2008 13:00:54 -0400, Chuck Robey <chuckr@telenix.org> wrote: > 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: I can certainly feel the `pain' of reluctantly choosing GNU make, or even of going the automake/autoconf/libtool way. I have written a fair amount of build glue myself too, and I know that I'd love to have BSD make in other systems too. Since the topic of (re)using FreeBSD make on non-BSD platforms seems to pop up more or less every 4-6 months the last year, I've started at least two attempts at porting 'FreeBSD make' to non BSD systems. The last attempt was aiming for a 'clean' set of minimal changes to the source of make. And it's done. At least the *binary* of make builds and tries to pull bsd.*.mk files on Linux and Solaris 10 here. The actual *source* code changes needed to build a BSD-make executable on Linux are pretty 'small': keramida@mithra:/home/keramida/tools$ uname -a Linux mithra 2.6.24-19-generic #1 SMP Fri Jul 11 23:41:49 UTC 2008 i686 GNU/Linux keramida@mithra:/home/keramida/tools$ hg short -r1 1:664527963082 | 2008-07-25 16:47 +0300 | keramida: Import FreeBSD make-20080724 snapshot (svn 180782) The diff from the first snapshot import of FreeBSD make touches only a few files: keramida@mithra:/home/keramida/tools$ hg diff -r 1:tip bin/make | diffstat -p1 bin/make/Makefile | 8 +++++- bin/make/compat.c | 67 +++++++++++++++++++++++++++++++++++++++++++++++++++ bin/make/compat.h | 36 +++++++++++++++++++++++++++ bin/make/job.c | 8 +++++- bin/make/main.c | 17 ++++++++++++ bin/make/pathnames.h | 2 - 6 files changed, 135 insertions(+), 3 deletions(-) keramida@mithra:/home/keramida/tools$ Now I'm looking for some spare time to clean-up the changes a bit and integrate them in `http://hg.hellug.gr/bmake/gker/'. The tricky part is, however, that a lot of the functionality of make(1) depends on the `share/mk/bsd.*.mk' files. I have finished writing the automake glue that installs these in `$prefix/share/mk' but now I am kind of stuck while thinking about a good way to make the bsd.*.mk files actually usable on, say, FreeBSD, Linux and Solaris. > 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. Both -v and -V are taken, and I don't really like the idea of adding long options to make(1). Maybe we can partially ``hijack'' the -v option to also display a verbose version string, i.e.: % make -v FreeBSD make (version 5200408120) make: no target to make. % It's probably ok to print a version number when 'being extra verbose' :) > 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. make(1) is actually pretty 'easy' to compile on, say, Linux, as I wrote above. The only bits that are missing on Linux are: * An errc() function. I added one in compat.c of my diffstat output above, and this accounts for most of the lines in the patches. * Our make(1) uses arc4random(). #ifdef HAVE_ARC4RANDOM and a few lines to call srandom() or srandomdev() and random() when it's unavailable are probably `ok' for this. * FreeBSD make uses getprogname(), but saving argv[0] and re-using that is trivial to add when HAVE_GETPROGNAME if undefined. * On FreeBSD/pc98 systems make tries to get the value of the "machdep.ispc98" by calling sysctlbyname("machdep.ispc98", ...). Since this part of the code is to be able to build make on pre-7.0 FreeBSD/pc98 systems, it may be ok to #ifdef HAVE_SYSCTLBYNAME and ignore this compatibility code on non-FreeBSD systems. This pretty much sums all the source code changes I had to make to build on Linux and Solaris. I'll see how much of the changes I can clean up and post online at `http://hg.hellug.gr/bmake/gker/'. It should be pretty easy, so please ping me in a couple of days if I haven't followed up with an "ACK, all done now". The 'porting' of share/mk/bsd.*.mk files may be a bit trickier, and it may even turn out to be much more difficult. I can certainly use all the help I can get there... - Giorgos
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8763pmt011.fsf>