Date: Thu, 28 Aug 2008 19:51:39 -0400 From: Chuck Robey <chuckr@telenix.org> To: Alfred Perlstein <alfred@freebsd.org> Cc: FreeBSD-arch@FreeBSD.org Subject: Re: an argument of make(1) Message-ID: <48B73A0B.401@telenix.org> In-Reply-To: <20080827174530.GZ16977@elvis.mu.org> References: <48B58846.6040400@telenix.org> <20080827174530.GZ16977@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alfred Perlstein wrote: > The only excuse I have for top posting here is that I agree > with the entirety of this email. Well, thanks, I wanted to get a feeling if I was alone in feeling this way; I guess I'm not. With this in mind, I've ported our BSD make tool twice (I lost my first try, felt fairly stupid for having to do it twice). Now I have this much agreement, I feel good enough about this to begin my own effort to make all the changes I asked for. I intend to code up changes in separate patches, so folks won't get a "all or nothing" option from me. My only problem in this is, since my health went bad on me, now I'm kinda more disabled than I used to me, I can't work as many hours as I used to, so it's definitely going to make me longer than most others. On top of this, I honestly don't cooperate all that well. I can take orders fine, but I generally either do it all or let YOU do it all, I'm just not a really great team player. So, if you have the time, leave it to me, I'll get it done, but if you want it soon, well, you might want to do it yourself. Other than that, I don't much see where this needs more discussion right now, unless someone has some more suggestions about what changes you want. I'm only (myself) interested in code portability, version options, and make conditionals test capabilities. I don't really want to craft a copy of GNU make. We can discuss this more when I have patches to show off. Once again, thanks for the clear, rapid response. > > -Alfred > > * Chuck Robey <chuckr@telenix.org> [080827 10:28] 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: > > 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. _______________________________________________ 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" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAki3OgsACgkQz62J6PPcoOl00gCgjo1YlwlDSrcahO8DK+VijWx/ w90An028vyzNklvjS97D/yv5qO+IDquP =ADNQ -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48B73A0B.401>