Re: Improving GNU make compatibility in BSD make (+ patch)
On Fri, May 31, 2002 at 11:46:03PM -0500, Dan Nelson wrote: Automake avoids the issue entirely by simply listing the dependencies itself, so envuidgid: envuidgid.o $(CC) $(LDFLAGS) -o $@ $^ becomes $(CC) $(LDFLAGS) -o $@ envuidgid.o This is not always possible. If you have a VPATH, then you need make(1) to expand $^ to the full path it used to find the dependancy. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Improving GNU make compatibility in BSD make (+ patch)
On Thu, May 30, 2002 at 07:42:28PM -0700, Jos Backus wrote: The GNU make info file says: `$^' The names of all the prerequisites, with spaces between them. For prerequisites which are archive members, only the member named is used (*note Archives::). A target has only one prerequisite on each other file it depends on, no matter how many times each file is listed as a prerequisite. So if you list a prerequisite more than once for a target, the value of `$^' contains just one copy of the name. I tried to add support for this a while back, but never got it working right. Nor did Will who worked on our make file a while. I'll have to see if your patch does everything $^ should do. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Improving GNU make compatibility in BSD make (+ patch)
Jos Backus wrote: On Sun, Jun 02, 2002 at 08:07:16PM -0600, Lyndon Nerenberg wrote: --lyndon (who doesn't understand why this is an issue, after having just converted a *whole* lot of source to work with POSIX make. Standards? Who gives a f*** (I guess ...)) I just checked the Open Group make definition and I can't find either $^ or $. So if we want to be truly standards-compliant perhaps we should remove support for $ :-) Intentionally stepping on the option value namespace in the absence of a ratified standard is a really stupid thing to do. But POSIX is N-P incomplete for some problems. On purpose. This is because POSIX is not meant to be a useful standard, it is meant to be an exclusionary standard for competition for government contracts. It was primarily meant to keep VAX/VMS, VM/CMS, Windows, and other OS software from vendors without at least an SVR3 source license and a per unit royalty agreement with ATT/USL from competing on contracts like Desktop II, Desktop III, AFCAC 451, and so on, and to prevent inclusion of such OS's on the GSA purchasing schedule. POSIX is the minimum list of conformance requirements which the UNIX vendors involved could agree on, because their UNIX implementations already conformed. POSIX is so fuzzy in so many areas because there were conflicting implementations, and they had to write it so that all of them complied with POSIX by default, once the standard was ratified and made into a CLIN requirement for government contracts. Do you *really* believe that someone would design a standard with no way to do a lot of things OSs at the time could already do, *on purpose*, without some ulterior motive? That POSIX file locking semantics are the work of an engineering genius? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Improving GNU make compatibility in BSD make (+ patch)
Lyndon Nerenberg wrote: Writing portable makefiles is already enough of a pain in the ass. No. It's not. I've written Makefile's that predate the consolidation during and after The UNIX Wars; they run fine, unmodified, on 140 different vendor versions of UNIX. You are smearing the necessary distinctions between mapping the problem space, abstraction of complexity, and non-intersection of mapping sets. All versions of make are attempts to map the same problem space. The more commands a make supports -- the richer the syntax it supports -- the more terse any given Makefile can be made to solve an arbitrary problem in the problem space. The more terse a Makefile, the higher its abstraction of the complexity of the problem to which it is being brought to bear. But each make has its own way of mapping the problem space; you can break the space into cubes, or you can break it into non-cubic trapezoids, or any of a number of elements of abstraction for a given space: and that gives you one mapping set. POSIX make semantics map the problem space, but they do so in a coarse fashion. What this means is that they are unable to be as terse as a make with a richer set of available mapping semantics (e.g. BSD make or GNU make). The upshot being that restricting yourself to POSIX make semantics means that your Makefile for an arbitrary problem will, with certain exceptions, end up being larger than a Makefile written to use additional features, above and beyond the POSIX features. In other words, a mapping set that is a superset of the POSIX mapping set -- or one, whose intersection with the POSIX mapping set is not the POSIX mapping set (i.e. it is missing some POSIX semantics). You need to be very careful with standards. When you build a mapping of a problem space, if that problem space is already mapped by a standard (e.g. POSIX), then you should minimally conform to the standard (conforming is defined as the standard set intersection with your implementations set yeilding the standard set). You also need to be very careful with extensions. Extensions, even in standards conforming implementations, are a problem in several ways: o If the standard is ever extended, there is a risk that your extension will conflict with the new instance of the standard. In general, revised standards will conform with existing standards (this is a definition for revised standard vs. new standard). o If your extensions are used, then software written to consume the standard interfaces is portable to your implementation, but software written to consume the interfaces exported by your implementation are *not* portable to other standards conformant implementations. In other words, you have attacked the standard through embrace and extend, and you have encouraged the creation of non-compliant consumers of the standard defined interfaces. This is the basis of The UNIX Wars, and it is also the basis of many people's complaints about Microsoft. o Your extensions may conflict with the extensions of third parties, which will damage the portability of the third parties application to your system. o Failure to adhere to standards damages the standards process by rendering standards meaningless in the face of defacto standards based, not on intelligent, informed consensus, but on market share. So ... why are we even having this discussion? Mostly, it's because people are too lazy to take their extensions to make syntax for finer granularity mapping of the problem space through the standards process, and want to make defacto standards: when you can't win fairly, cheat. I would still prefer that programs that need GNU make syntax use GNU make, and programs that need BSD make syntax use BSD make (and specifically, use the BSD make from the OP make source tree). If you are going to build non-standards-conforming Makefile's, at least be honest about the fact that they aren't conforming, and don't hide the origin of the non-conformance, so that you avoid conflicting future contributions as a result of conflicting divergence from the common superset of the standard (i.e. the attempted defacto standard end-run around the standards process). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Improving GNU make compatibility in BSD make (+ patch)
The reason that autoconf automake can only run under gmake is gmake will re-read included file if the included file itself is modified by some rules. BSD make does not! so they do not work with BSD make. for example: DEP_FILES = aaa.d bbb.d ccc.d $(DEP_FILES): %.d : %.cpp @echo Generating auto dependency for $ @$(SHELL) -ec '$(GXX) -MM $(CXXFLAGS) $ \ | sed '\''s/\($*\)\.o[ :]*/\1.o $@ : /g'\'' $@; \ [ -s $@ ] || rm -f $@' -include $(DEP_FILES) when aaa.d and bbb.d and ccc.d are updated, gmake will re-readed it in while BSD make not. in this example, if I use BSD make, I must first create target depend in Makefile and run the stupid make depend command everytime I modified my source code, with gmake, I can always run make without additional steps and it will generates auto-depend rule before compiling real source code. David Xu - Original Message - From: Terry Lambert [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, May 31, 2002 4:38 PM Subject: Re: Improving GNU make compatibility in BSD make (+ patch) Jos Backus wrote: So BSD make interpreting either `$^' or `$+' as its own `$' would improve compatibility with GNU make Makefiles. I am just not sure which of the two GNU make variables maps better to our `$'. This patch implements the former: The biggest problem with GNU make that I've seen is re-expansion of variable variables. The suggested fix doesn't address that, so it won't fix the most common compatability problem. If we are going to evolve make into gmake (not a good idea, IMO), then probably the place to start is any port that requires gmake to get it working under make. I'm not sure, but I believe the other BSD's, and OpenPorts have modified make syntax somewhat. It's probably a good idea to keep compatability with options in the OpenPorts camp, more than any other, if it ever evolves to fulfill its potential properly. I really hate that many autoconf/automake scripts generate code that can ony be run by gmake, and sometimes also requires that /bin/sh actually be bash instead of sh. It also occurs to me (from experience with perl), that in any language where it's posible to do something in more than one way, it is then impossible to differentiate the right way from the wrong way. 8-(. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Improving GNU make compatibility in BSD make (+ patch)
Terry Lambert wrote: Jos Backus wrote: On Fri, May 31, 2002 at 01:38:17AM -0700, Terry Lambert wrote: The biggest problem with GNU make that I've seen is re-expansion of variable variables. The suggested fix doesn't address that, so it won't fix the most common compatability problem. So what? It fixes (in a backward-compatible way because ``$^'' isn't used in BSD make) one incompatibility without which I have to have two different Makefiles in the simple case I am thinking about. It's at least an incremental improvement that doesn't break anything afaIcs. 1) Please see the references I cited. I believe $^ is used in a BSD make, even if it's not in the FreeBSD make, and that in a future version of FreeNSD make, it ought to have the function of the BSD make that uses it, not GNU make. 2) I am not comfortable with changing FreeBSD make into GNU make. 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. 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. 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. 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. 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. 7) What are you going to do when you need to compile on AIX? Same thing. 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 ? -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Improving GNU make compatibility in BSD make (+ patch)
Sergey == Sergey Babkin [EMAIL PROTECTED] writes: Sergey I would really like all the existing make branches (BSD, Sergey GNU, SVR4) converge to a single syntax. Otherwise it's too Sergey much pain, and the only workaround is either to use only the Sergey classic V7 make features or write makefiles for gmake since Sergey it's readily available on all the platforms. Fine. We all adopt the Plan 9 mk and make Presotto the gatekeeper of any further enhancements. --lyndon (who doesn't understand why this is an issue, after having just converted a *whole* lot of source to work with POSIX make. Standards? Who gives a f*** (I guess ...)) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Improving GNU make compatibility in BSD make (+ patch)
On Sun, Jun 02, 2002 at 08:07:16PM -0600, Lyndon Nerenberg wrote: --lyndon (who doesn't understand why this is an issue, after having just converted a *whole* lot of source to work with POSIX make. Standards? Who gives a f*** (I guess ...)) I just checked the Open Group make definition and I can't find either $^ or $. So if we want to be truly standards-compliant perhaps we should remove support for $ :-) -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer; To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Improving GNU make compatibility in BSD make (+ patch)
Jos == Jos Backus [EMAIL PROTECTED] writes: Jos I just checked the Open Group make definition and I can't find Jos either $^ or $. So if we want to be truly standards-compliant Jos perhaps we should remove support for $ :-) We are POSIX compliant right now (I think -- I haven't done a strict comparison between (our) BSD make and POSIX). BSD does have things that aren't in POSIX, as does GNUmake. Removing the historical BSD syntax would just break things, so I wouldn't advocate that. We can depricate the BSD extensions if that seems useful. That's not the same as adding new incompatible extensions to make (ours, GNUs, or anyone elses). Writing portable makefiles is already enough of a pain in the ass. --lyndon (death to feeping creaturism!) (And yes, I would really miss the BSD/GNU if/then/else makefile constructs if we went POSIX-anal on this.) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Improving GNU make compatibility in BSD make (+ patch)
On Sun, Jun 02, 2002 at 08:33:08PM -0600, Lyndon Nerenberg wrote: We are POSIX compliant right now (I think -- I haven't done a strict comparison between (our) BSD make and POSIX). BSD does have things that aren't in POSIX, as does GNUmake. Removing the historical BSD syntax would just break things, so I wouldn't advocate that. Neither would I; claiming that strict POSIX-compliance is the end-all goal makes no sense imo. We can depricate the BSD extensions if that seems useful. That's not the same as adding new incompatible extensions to make (ours, GNUs, or anyone elses). My proposal for adding $^ as an alias for $ does not add any incompatibilities, neither with POSIX nor with any existing BSD make. Only Terry has said that BSD make used to use $^ but so far he hasn't shown any proof that this is still in use anywhere. Writing portable makefiles is already enough of a pain in the ass. Writing Makefiles is a pain, period. --lyndon (death to feeping creaturism!) (And yes, I would really miss the BSD/GNU if/then/else makefile constructs if we went POSIX-anal on this.) Needless to say, I'm certainly not advocating that we do this. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer; To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Improving GNU make compatibility in BSD make (+ patch)
Jos == Jos Backus [EMAIL PROTECTED] writes: Writing portable makefiles is already enough of a pain in the ass. Jos Writing Makefiles is a pain, period. Writing makefiles is easy. Writing *portable* makefiles is a pain. There *is* a difference. --lyndon To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Improving GNU make compatibility in BSD make (+ patch)
On Sun, Jun 02, 2002 at 10:39:02PM -0600, Lyndon Nerenberg wrote: Jos == Jos Backus [EMAIL PROTECTED] writes: Writing portable makefiles is already enough of a pain in the ass. Jos Writing Makefiles is a pain, period. Writing makefiles is easy. Writing *portable* makefiles is a pain. There *is* a difference. I agree with the portable part. For small projects, Makefiles are fine imo. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer; To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Improving GNU make compatibility in BSD make (+ patch)
Jos == Jos Backus [EMAIL PROTECTED] writes: Jos My proposal for adding $^ as an alias for $ does not add any Jos incompatibilities, neither with POSIX nor with any existing BSD Jos make. Yes, and no. Adding new features doesn't break existing code, but it encourages new code to use the new features in a non-compatible way. The import of tcsh on top of csh is a classic of this. What we have works. It's not cool and/or sexy. But it works. If you *need* the features of GNUmake, use GNUmake. --lyndon To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Improving GNU make compatibility in BSD make (+ patch)
On Sun, Jun 02, 2002 at 11:28:49PM -0600, Lyndon Nerenberg wrote: Jos == Jos Backus [EMAIL PROTECTED] writes: Jos My proposal for adding $^ as an alias for $ does not add any Jos incompatibilities, neither with POSIX nor with any existing BSD Jos make. Yes, and no. Adding new features doesn't break existing code, but it encourages new code to use the new features in a non-compatible way. The import of tcsh on top of csh is a classic of this. What we have works. It's not cool and/or sexy. But it works. If you *need* the features of GNUmake, use GNUmake. Sigh. BSD make and GNU make already _share_ this same feature, it's just that they _name_ it differently: $ v.s. $^. If POSIX would only adopt one (or both) we could follow their lead and be done with it. But that's not going to happen any time soon. --lyndon -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer; To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Improving GNU make compatibility in BSD make (+ patch)
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 [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Improving GNU make compatibility in BSD make (+ patch)
On Fri, May 31, 2002 at 10:05:27PM -0700, Jos Backus wrote:
That's a good idea, thanks. I just sent an e-mail coining the concept to
[EMAIL PROTECTED]
Fyi, I just sent a patch to to help-make; who knows Paul may accept it.
--- expand.c.orig Mon Jun 19 13:23:35 2000
+++ expand.cSat Jun 1 00:42:11 2002
@@ -373,6 +373,11 @@
/* A $ followed by a random char is a variable reference:
$a is equivalent to $(a). */
+
+ /* Treat $ as $^ for compatibility with BSD make. */
+ if (*p == '')
+ *p = '^';
+
{
/* We could do the expanding here, but this way
avoids code repetition at a small performance cost. */
--
Jos Backus _/ _/_/_/Santa Clara, CA
_/ _/ _/
_/ _/_/_/
_/ _/ _/_/
[EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Improving GNU make compatibility in BSD make (+ patch)
Jos Backus wrote: Fyi: it appears nobody is really interested in having BSD make and GNU make converge a little, so I am not going waste any more time on this. I'm really against GNU-ifying BSD make. Unless you're getting a lot of off-list hate-mail for the idea, though, my count is 2/2(including you)/1 abstain. Two days in the week following Memorial Day weekend (where you get Monday off, so you can have 9 days in a row for 4 days of vacation time) is hardly enough time to build a roaring consensus, one way or the other... Are you sure you aren't just being a little bit impatient here? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Improving GNU make compatibility in BSD make (+ patch)
On Sat, Jun 01, 2002 at 01:14:18AM -0700, Terry Lambert wrote: Jos Backus wrote: Fyi: it appears nobody is really interested in having BSD make and GNU make converge a little, so I am not going waste any more time on this. I'm really against GNU-ifying BSD make. I hope you don't see any problems with generally improving compatibility between the two? Unless you're getting a lot of off-list hate-mail for the idea, though, my count is 2/2(including you)/1 abstain. Two days in the week following Memorial Day weekend (where you get Monday off, so you can have 9 days in a row for 4 days of vacation time) is hardly enough time to build a roaring consensus, one way or the other... Are you sure you aren't just being a little bit impatient here? Perhaps a bit, yes, you're right. Let's see what other responses come in. Maybe Paul Smith will accept my patch to GNU make, that would work as well. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer; To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Improving GNU make compatibility in BSD make (+ patch)
Jos Backus wrote: On Sat, Jun 01, 2002 at 01:14:18AM -0700, Terry Lambert wrote: Jos Backus wrote: Fyi: it appears nobody is really interested in having BSD make and GNU make converge a little, so I am not going waste any more time on this. I'm really against GNU-ifying BSD make. I hope you don't see any problems with generally improving compatibility between the two? As long as any changes do not conflict with OpenBSD make, NetBSD make, BSDi make, Darwin make, or OP make. It's a lot easier to change gmake, I think... I think OP make is most important: http://openpackages.org/ -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Improving GNU make compatibility in BSD make (+ patch)
On Sat, Jun 01, 2002 at 01:37:43AM -0700, Terry Lambert wrote: Jos Backus wrote: I hope you don't see any problems with generally improving compatibility between the two? As long as any changes do not conflict with OpenBSD make, NetBSD make, BSDi make, Darwin make, or OP make. Well, you are saying that some BSD make out there uses $^ so that pretty much rules out changing it. It's a lot easier to change gmake, I think... It took me about the same amount of time to create both patches... I think OP make is most important: http://openpackages.org/ You could buddy this patch for me :-) Index: generate.c === RCS file: /cvs/op/tools/make/generate.c,v retrieving revision 1.7 diff -u -r1.7 generate.c --- generate.c 2001/07/03 14:23:10 1.7 +++ generate.c 2002/06/01 09:04:22 @@ -40,6 +40,7 @@ M(TARGET), M(OODATE), M(ALLSRC), + M(GALLSRC), M(IMPSRC), M(PREFIX), M(ARCHIVE), Index: var.c === RCS file: /cvs/op/tools/make/var.c,v retrieving revision 1.13 diff -u -r1.13 var.c --- var.c 2001/05/29 15:29:24 1.13 +++ var.c 2002/06/01 09:04:23 @@ -144,6 +144,7 @@ MEMBER, OODATE, ALLSRC, +GALLSRC, IMPSRC, FTARGET, DTARGET, @@ -277,6 +278,10 @@ break; case K_ALLSRC % MAGICSLOTS1: if (name[0] == ALLSRC[0] len == 1) + return ALLSRC_INDEX; + break; +case K_GALLSRC % MAGICSLOTS1: + if (name[0] == GALLSRC[0] len == 1) return ALLSRC_INDEX; break; case K_IMPSRC % MAGICSLOTS1: Index: var.h === RCS file: /cvs/op/tools/make/var.h,v retrieving revision 1.1 diff -u -r1.1 var.h --- var.h 2001/05/29 13:39:59 1.1 +++ var.h 2002/06/01 09:04:23 @@ -65,7 +65,8 @@ #define MEMBER_INDEX 3 #define OODATE_INDEX 4 #define ALLSRC_INDEX 5 -#define IMPSRC_INDEX 6 +#define GALLSRC_INDEX 6 +#define IMPSRC_INDEX 7 extern char *Varq_Value(int, GNode *); extern void Varq_Set(int, const char *, GNode *); extern void Varq_Append(int, const char *, GNode *); Index: var_int.h === RCS file: /cvs/op/tools/make/var_int.h,v retrieving revision 1.1 diff -u -r1.1 var_int.h --- var_int.h 2001/05/29 13:39:59 1.1 +++ var_int.h 2002/06/01 09:04:23 @@ -29,6 +29,7 @@ #define TARGET @ /* Target of dependency */ #define OODATE ? /* All out-of-date sources */ #define ALLSRC /* All sources */ +#define GALLSRC ^ /* All sources, GNU make style */ #define IMPSRC /* Source implied by transformation */ #define PREFIX * /* Common prefix */ #define ARCHIVE ! /* Archive in archive(member) syntax */ -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer; To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Improving GNU make compatibility in BSD make (+ patch)
On 05/31/02 19:53, Jos Backus wrote: Fyi: it appears nobody is really interested in having BSD make and GNU make converge a little, so I am not going waste any more time on this. Actually, I think it's a great idea. It should make life much easier for people creating and maintaining ports. The tone of Terry's reply to your mail seemed to be My opinion is the only one that counts here and I disagree with you. My advice would be to not mistake the sheer volume of Terry's constant bitching at anyone trying to do real productive work with anything FreeBSD-policy-like. -- Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Improving GNU make compatibility in BSD make (+ patch)
On Sat, Jun 01, 2002 at 11:45:15AM -0600, Ian wrote: Actually, I think it's a great idea. It should make life much easier for people creating and maintaining ports. My thoughts exactly. The tone of Terry's reply to your mail seemed to be My opinion is the only one that counts here and I disagree with you. My advice would be to not mistake the sheer volume of Terry's constant bitching at anyone trying to do real productive work with anything FreeBSD-policy-like. Thanks, will do :-) Any if anybody with make clue wants to review the OP make patch I posted, that would be appreciated. The patch is available at: http://www.catnook.com/patches/op-make.patch -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer; To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Improving GNU make compatibility in BSD make (+ patch)
Ian wrote: On 05/31/02 19:53, Jos Backus wrote: Fyi: it appears nobody is really interested in having BSD make and GNU make converge a little, so I am not going waste any more time on this. Actually, I think it's a great idea. It should make life much easier for people creating and maintaining ports. The tone of Terry's reply to your mail seemed to be My opinion is the only one that counts here and I disagree with you. My advice would be to not mistake the sheer volume of Terry's constant bitching at anyone trying to do real productive work with anything FreeBSD-policy-like. That's not really fair. *I'm* the one who pointed out that, so far, he only got four opinions, other than his own, and that it was Memorial Day Week, and the opinions were split equally for those actually expressing something other than I don't care, so throwing in the towel too easily was a bad thing. It's really annoying that you've attempted to dismiss my concerns as bitching. If you think it's a good idea, then please, argue on technical merit; I've restricted myself to technical arguments, the least you could do is to do the same. As to your statement It should make life much easier for people creating and maintaining ports.: No, it won't. What it will do is result in some small subset of ports that expect GNU make working with BSD make, until some random point in the future, when they use a GNU make feature that's not implemented. You either need to make it a superset, or you need to not bother. The intersection set is not useful, particularly if it takes part of the name space, and doesn't give back any new functionality. BSD make can't afford this, since it has an historical tradition of using single characters for options. The GNU tradition, if there is one, is to add features that take a paragraph to invoke (e.g. if we go down this road, we are on the road to getopt_long problems, like those recently discussed in -ports and -current). BSD make must be extremely frugal with its name space, because it is so small, compared to the name space of GNU make. There are already problems with name space collisions with other BSD make implementations symbol option variables. If I had to make a choice between slowly converging on GNU make vs. just switching over to GNU make, I would say that FreeBSD ought to just switch over. I would object to that, since it would bloat Makefiles, and make us incompatabile with other BSDs. As you redundantly point out (since I've already pointed it out three times, now, belieing your characterization of bitching so that you can avoid the technical problems with your position), yeah, that's my opinion. But it's one informed by 22 years of programming experience. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Improving GNU make compatibility in BSD make (+ patch)
Jos Backus wrote: On Sat, Jun 01, 2002 at 11:45:15AM -0600, Ian wrote: Actually, I think it's a great idea. It should make life much easier for people creating and maintaining ports. My thoughts exactly. Any port that switches to BSD make because the Makefile uses this *one* GNU make specific feature, and it becomes implemented in BSD make, is just asking for it. Any existing port maintainer doing a proper risk analysis will not fall into this trap. A maintainer of a new port *might* have marginal benefit (which I would argue would be transient, at best) IFF this is the only GNU make specific feature that the Makefile uses (this is a small subset of potential work). You are assuming that someone who uses one GNU make specific feature now, will not use more GNU make specific features in future versions of their code, going forward. I would argue that this is a low probability bet: o They are already using GNU make as their baseline for selection of which features they are going to exploit o The have implicitly demonstrated their lack of care for portability in their use of the feature in the first place o Programmers naturally gravitate towards use of more and more esoteric features of tools as they learn to use their tools o We have to assume that GNU make is at least moderately well designed for this discussion -- if it isn't, it would be a bad idea to imitate it -- and so the other features it implements but BSD make does not also have their purpose within that design. This will promote their use by programmers The most likely outcome is that the maintainer for the original GNU make specific code will include more GNU make specific features in the Makefiles, over time, going forward. When this happens, the port maintainer will be faced with one of two options: A) Switch the port back to GNU make, wasting the work they did to switch it to BSD make in the first place B) Modify the BSD make to implement the newly used GNU make feature, so that the port does not have to be switched Both of these options are effort intensive. Both of them entail work that would not be necessary, had the porter simply made the port depend on the GNU make port (gmake), like all other similar ports currently do. If you want to make the argument that implementation of GNU features in all tools and/or a switch to GNU tools would result in more software being available for FreeBSD: make that argument, don't try to approach it tangentially and sneak the idea in under everyone's radar. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Improving GNU make compatibility in BSD make (+ patch)
Jos Backus wrote: So BSD make interpreting either `$^' or `$+' as its own `$' would improve compatibility with GNU make Makefiles. I am just not sure which of the two GNU make variables maps better to our `$'. This patch implements the former: The biggest problem with GNU make that I've seen is re-expansion of variable variables. The suggested fix doesn't address that, so it won't fix the most common compatability problem. If we are going to evolve make into gmake (not a good idea, IMO), then probably the place to start is any port that requires gmake to get it working under make. I'm not sure, but I believe the other BSD's, and OpenPorts have modified make syntax somewhat. It's probably a good idea to keep compatability with options in the OpenPorts camp, more than any other, if it ever evolves to fulfill its potential properly. I really hate that many autoconf/automake scripts generate code that can ony be run by gmake, and sometimes also requires that /bin/sh actually be bash instead of sh. It also occurs to me (from experience with perl), that in any language where it's posible to do something in more than one way, it is then impossible to differentiate the right way from the wrong way. 8-(. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Improving GNU make compatibility in BSD make (+ patch)
On Fri, May 31, 2002 at 01:38:17AM -0700, Terry Lambert wrote: The biggest problem with GNU make that I've seen is re-expansion of variable variables. The suggested fix doesn't address that, so it won't fix the most common compatability problem. So what? It fixes (in a backward-compatible way because ``$^'' isn't used in BSD make) one incompatibility without which I have to have two different Makefiles in the simple case I am thinking about. It's at least an incremental improvement that doesn't break anything afaIcs. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer; To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Improving GNU make compatibility in BSD make (+ patch)
Jos Backus wrote: On Fri, May 31, 2002 at 01:38:17AM -0700, Terry Lambert wrote: The biggest problem with GNU make that I've seen is re-expansion of variable variables. The suggested fix doesn't address that, so it won't fix the most common compatability problem. So what? It fixes (in a backward-compatible way because ``$^'' isn't used in BSD make) one incompatibility without which I have to have two different Makefiles in the simple case I am thinking about. It's at least an incremental improvement that doesn't break anything afaIcs. 1) Please see the references I cited. I believe $^ is used in a BSD make, even if it's not in the FreeBSD make, and that in a future version of FreeNSD make, it ought to have the function of the BSD make that uses it, not GNU make. 2) I am not comfortable with changing FreeBSD make into GNU make. 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. 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. 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. 6) What are you going to do, when you need to compile on Solaris? 7) What are you going to do when you need to compile on AIX? 8) How is make different from cc or tar? If we are going to add the features, why not just use GNU make instead? 9) Why not just use Linux instead? That last is a reductio ad absurdum... but I really don't see what making this change accomplishes, other than making FreeBSD toe the GNU line. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Improving GNU make compatibility in BSD make (+ patch)
Fyi: it appears nobody is really interested in having BSD make and GNU make converge a little, so I am not going waste any more time on this. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer; To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Improving GNU make compatibility in BSD make (+ patch)
what would you want to do? On Fri, 31 May 2002, Jos Backus wrote: Fyi: it appears nobody is really interested in having BSD make and GNU make converge a little, so I am not going waste any more time on this. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer; To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Improving GNU make compatibility in BSD make (+ patch)
On Fri, May 31, 2002 at 06:55:54PM -0700, Julian Elischer wrote: what would you want to do? On Fri, 31 May 2002, Jos Backus wrote: Fyi: it appears nobody is really interested in having BSD make and GNU make converge a little, so I am not going waste any more time on this. BSD make and GNU make use different symbols for .ALLSRC: GNU make uses $^ and BSD make uses $. All my tiny patch to BSD make does is have BSD make treat $^ as $. This fixes the problem of the mktool Makefile which with this patch is executed properly by both make's. Perhaps there is a better way to achieve this but I don't see it. Since BSD make (or OpenBSD make, for that matter) doesn't currently use $^ I thought it was a pretty safe and useful change. Thanks for caring! CC?=gcc OPT=-O2 -march=i686 #DEBUG=-g -pedantic -Wall -Werror LDFLAGS=-s CFLAGS=$(OPT) $(DEBUG) PROGS=envuidgid setugid tcpaccept tcplisten execlp bsok babysit BINMODE?=555 prefix=/usr/local bindir=$(prefix)/bin .c.o: $(CC) $(CFLAGS) -c $ all: $(PROGS) envuidgid: envuidgid.o $(CC) $(LDFLAGS) -o $@ $^ setugid: setugid.o setonlygid.o $(CC) $(LDFLAGS) -o $@ $^ tcpaccept: tcpaccept.o signal_action.o $(CC) $(LDFLAGS) -o $@ $^ tcplisten: tcplisten.o $(CC) $(LDFLAGS) -o $@ $^ execlp: execlp.o $(CC) $(LDFLAGS) -o $@ $^ babysit: babysit.o signal_action.o file_lock.o $(CC) $(LDFLAGS) -o $@ $^ bsok: bsok.o $(CC) $(LDFLAGS) -o $@ $^ $(bindir): mkdir -pm 755 $(bindir) clean: rm -f $(PROGS) install: $(PROGS) $(bindir) install -m $(BINMODE) $(PROGS) $(bindir) -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer; To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Improving GNU make compatibility in BSD make (+ patch)
In the last episode (May 31), Jos Backus said: On Fri, May 31, 2002 at 06:55:54PM -0700, Julian Elischer wrote: On Fri, 31 May 2002, Jos Backus wrote: Fyi: it appears nobody is really interested in having BSD make and GNU make converge a little, so I am not going waste any more time on this. what would you want to do? BSD make and GNU make use different symbols for .ALLSRC: GNU make uses $^ and BSD make uses $. All my tiny patch to BSD make does is have BSD make treat $^ as $. This fixes the problem of the mktool Makefile which with this patch is executed properly by both make's. Perhaps there is a better way to achieve this but I don't see it. Since BSD make (or OpenBSD make, for that matter) doesn't currently use $^ I thought it was a pretty safe and useful change. That doesn't fix Tru64 make, which uses $ like BSD make, or Solaris make, which has neither. In fact, based on this sample, I suggest you submit a patch to the gmake people adding $, which obviously is the defacto standard :) Automake avoids the issue entirely by simply listing the dependencies itself, so envuidgid: envuidgid.o $(CC) $(LDFLAGS) -o $@ $^ becomes $(CC) $(LDFLAGS) -o $@ envuidgid.o -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Improving GNU make compatibility in BSD make (+ patch)
On Fri, May 31, 2002 at 11:46:03PM -0500, Dan Nelson wrote: That doesn't fix Tru64 make, which uses $ like BSD make, or Solaris make, which has neither. In fact, based on this sample, I suggest you submit a patch to the gmake people adding $, which obviously is the defacto standard :) That's a good idea, thanks. I just sent an e-mail coining the concept to [EMAIL PROTECTED] Automake avoids the issue entirely by simply listing the dependencies itself, so envuidgid: envuidgid.o $(CC) $(LDFLAGS) -o $@ $^ becomes $(CC) $(LDFLAGS) -o $@ envuidgid.o Ugly but portable, I guess. It would be better to be able to use pattern rules instead; less duplication. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer; To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Improving GNU make compatibility in BSD make (+ patch)
In the last episode (May 31), Jos Backus said: On Fri, May 31, 2002 at 11:46:03PM -0500, Dan Nelson wrote: Automake avoids the issue entirely by simply listing the dependencies itself, so envuidgid: envuidgid.o $(CC) $(LDFLAGS) -o $@ $^ becomes $(CC) $(LDFLAGS) -o $@ envuidgid.o Ugly but portable, I guess. It would be better to be able to use pattern rules instead; less duplication. It ends up creating a make variable for each target containing the object files (envuidguid_OBJECTS=envuidgid.o for example) and uses that on the dependency and link lines, so it's not too bad. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Improving GNU make compatibility in BSD make (+ patch)
The GNU make info file says:
`$^'
The names of all the prerequisites, with spaces between them. For
prerequisites which are archive members, only the member named is
used (*note Archives::). A target has only one prerequisite on
each other file it depends on, no matter how many times each file
is listed as a prerequisite. So if you list a prerequisite more
than once for a target, the value of `$^' contains just one copy
of the name.
`$+'
This is like `$^', but prerequisites listed more than once are
duplicated in the order they were listed in the makefile. This is
primarily useful for use in linking commands where it is
meaningful to repeat library file names in a particular order.
The make(1) manpage says:
.ALLSRC The list of all sources for this target; also known as
`'.
So BSD make interpreting either `$^' or `$+' as its own `$' would improve
compatibility with GNU make Makefiles. I am just not sure which of the two GNU
make variables maps better to our `$'. This patch implements the former:
--- var.c Sat Apr 13 03:16:56 2002
+++ var.c.new Thu May 30 19:32:01 2002
@@ -1489,6 +1489,8 @@
name[0] = str[1];
name[1] = '\0';
+ if (name[0] == '^')
+ name[0] = '';
v = VarFind (name, ctxt, FIND_ENV | FIND_GLOBAL | FIND_CMD);
if (v == (Var *)NULL) {
--
Jos Backus _/ _/_/_/Santa Clara, CA
_/ _/ _/
_/ _/_/_/
_/ _/ _/_/
[EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
