From owner-freebsd-arch@FreeBSD.ORG Wed Aug 27 17:45:30 2008 Return-Path: Delivered-To: FreeBSD-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DBD4D106568C for ; Wed, 27 Aug 2008 17:45:30 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id C6AE98FC1C for ; Wed, 27 Aug 2008 17:45:30 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 79F341A4D81; Wed, 27 Aug 2008 10:45:30 -0700 (PDT) Date: Wed, 27 Aug 2008 10:45:30 -0700 From: Alfred Perlstein To: Chuck Robey Message-ID: <20080827174530.GZ16977@elvis.mu.org> References: <48B58846.6040400@telenix.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48B58846.6040400@telenix.org> User-Agent: Mutt/1.4.2.3i Cc: FreeBSD-arch@FreeBSD.org Subject: Re: an argument of make(1) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2008 17:45:31 -0000 The only excuse I have for top posting here is that I agree with the entirety of this email. -Alfred * Chuck Robey [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@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" -- - Alfred Perlstein