Date: Sun, 02 Jun 2002 22:57:47 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Sergey Babkin <babkin@bellatlantic.net> Cc: jos@catnook.com, freebsd-hackers@freebsd.org Subject: Re: Improving GNU make compatibility in BSD make (+ patch) Message-ID: <3CFB055B.FC5FE632@mindspring.com> References: <20020531024250.GA90997@lizzy.catnook.com> <3CF73679.A5AB7886@mindspring.com> <20020531170746.GA93242@lizzy.catnook.com> <3CF7EDC5.CF27B997@mindspring.com> <3CFAAED2.F98FD7B4@bellatlantic.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Sergey Babkin wrote: > I would really like all the existing make branches (BSD, GNU, SVR4) > converge to a single syntax. Otherwise it's too much pain, and the > only workaround is either to use only the classic V7 make features > or write makefiles for gmake since it's readily available on all > the platforms. I'd like it too, but it's not going to happen, any more than there will end up being a single file for init (ttys vs. inittab) or a single syntax for that file. v7 is an exaggeration, I think, unless you think the move to remove the __STDC__ and __P() code recently has been a mistake. The common subset, I think, is the same subset supported by AIX's "make". This all comes back to "if features exist, people will use them", which really argues *againt* incremental convergence even being possible. > > 3) I am not comfortable adding features to FreeBSD make which > > render makefiles, which are then written to use these newly > > added features, non-portable to other BSD systems. > > That's easy: don't write makefiles that use these features. Document > them as strongly deprecated and compatibility-only. Yet, here we are, sanctioning code that uses these deprecated features, by adding the features to a program that currently punishes their use... > > 4) There are *already* enough cases where people have written > > "sh" scripts with "bash" syntax, so that they *claim* they > > are "sh" scripts, but are in fact "bash" scripts. I would > > hate to see the same thing happen to "makefiles" to turn > > them into "gmakefiles". > > I agree. If any such additions are made, they should be only enabled > by a command-line options. On the other hand, you can just use gmake > to the same effect. This was my argument. Use "gmake". Admit the non-portability of your Makefile's syntax. Own up to your mistakes. > > 5) What you've added is a synonym for something that's already > > there; it is better to change the makefile to use the existing > > syntax, then it is to change the "make" to add new syntax. > > It means changing every makefile. To remove a feature that's defined "deprecated before implemented"; not really a heavy problem. > > 6) What are you going to do, when you need to compile on Solaris? > > SVR4 make extensions are totally incompatible with BSD make extensions, > so nothing changes in this respect: the BSD makefiles don't work > on SVR4. You mean "Makefiles with BSD specific syntax don't work on SVR4"; the thing that makes a Makefile non-portable is its use of non-portable syntax. And that a problem you resolve by chaning the Makefile, not all instances of "make". > > 7) What are you going to do when you need to compile on AIX? > > Same thing. "Use gmake instead", I guess you mean, unless you work for IBM in Austin, and have the kerys to the AFS on which the source code for the AIX version of "make" is hidden, and plan to change AIX "make" to support GNU syntax, as well. > > 8) How is "make" different from "cc" or "tar"? If we are going > > to add the features, why not "just use GNU make instead"? > > Aren't we already using GCC and GNU tar ? Or am I completely missng > the point of this point ? Yes and yes. 8-). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3CFB055B.FC5FE632>