Re: make question
On Apr 28, 2011, at 7:37 PM, Arnaud Lacombe wrote: On Thu, Apr 28, 2011 at 11:52 AM, Hartmut Brandt hartmut.bra...@dlr.de wrote: I think we can change this, because it would break makefiles that assume that the entire script is given to the shell in one piece. I'm not sure to parse that. We can change it because it would break stuff. That said, if something was to be broken, it would already shows up when using -j N, and thus should be considered as a bug. There's bugs in the code which does the output which makes it wrong often... So there's bugs both ways... There's archival history here in hackers@. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: make question
On Thu, Apr 28, 2011 at 08:50:27PM +0200, Hartmut Brandt wrote: On Thu, 28 Apr 2011, Roman Divacky wrote: RDOn Thu, Apr 28, 2011 at 05:52:58PM +0200, Hartmut Brandt wrote: RD Hi Roman, RD RD On Wed, 27 Apr 2011, Roman Divacky wrote: RD RD RDYou seem to have messed with bsd make so I have a question for you :) RD RD Yeah, that was some time ago ... RD RD RDWhen a job is about to be executed in JobStart() a pipe is created with RD RDits ends connected to job-inPipe/job-outPipe. When the job is actually RD RDcreated in JobExec() the ps.out is set to job-outPipe so that in RD RDJobDoOutput() we can read from that pipe and basically just parse the output RD RDfor shell-noPrint and leaving it out from the output. This is meant (I think) RD RDfor supressing the filter thing. Ie. that if we do some @command the RD RDrestoration of setting of quiet mode is filtered out. RD RD RD RD RD RDIn -B mode we do it differently, as we invoke one shell per command we don't RD RDhave to insert quiet/verbose commands and thus avoid all the piping/parsing RD RDdance. RD RD RD RDSo my question is - why don't we invoke one shell per command by default RD RDand avoid the piping/parsing? Is this because of performance? I think that RD RDthe piping/parsing of the output can have worse impact than invoking a shell RD RDfor every command. Especially given that most targets consists of just one RD RDcommand. RD RD The answer is in /usr/share/doc/psd/12.make. This is so one can write RD something like RD RD debug: RD DEBUG_FLAGS=-g RD for i in $(SUBDIR); do RD $(MAKE) -C $$i all RD done RD RD instead of: RD RD debug: RD DEBUG_FLAGS=-g \ RD for i in $(SUBDIR); do \ RD $(MAKE) -C $$i all ; \ RD done RD RD -B means 'backward compatible' and does what the original v7 make did: one RD shell per command. This means you don't have to write the backslashes and RD the shell variable will be seen in the sub-makes and programs. RD RD I think we can change this, because it would break makefiles that assume RD that the entire script is given to the shell in one piece. RD RDI think you answered the question why we parse the target. But I asked why RDwe parse the output from it. My intention was to say why we use one shell for all commands for a given rule. If we'd use one shell per line the above would not work, because the first shell would see just the environment variable assignment (which would be completly useless). The next shell would see a partial 'for' statement and complain, and would not have the environment variable and so on. So this is not so much about parsing, but about execution. I suppose that the tricky point is with @-lines in the middle of a multi-line script. Unless I am reading the code wrong the one shell per command is the default mode. see in main.c: /* * Be compatible if user did not specify -j and did not explicitly * turned compatibility on */ if (!compatMake !forceJobs) compatMake = TRUE; You have to specify -j to turn off the compat mode. RDAnyway, so you think it would be ok to change it to one shell per command and RDavoid the shell output parsing or not? Unless I misunderstand the question I would say no, because this would certainly render makefiles invalid that rely on the multi-line scripts beeing handled by a single shell. I think the chances of this breakage are pretty low as this is the default mode. RDI am interested in this so that make -j* lets the command know that the RDoutput is a TTY, eg. clang can emit coloured warnings. Hmm. I see. Just a wild guess: couldn't we use a pty to talk to the shell? If that could work the question is of course what one would expect from something like: make 21 make.out I looked at what gnu make does and I think they do pretty much the same what I suggested. Ie. one shell per command with no parsing of output by printing directly to stdout. Thus they have no problem with the process detecting stdout being a tty. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
RE: make question
s/can/can't/ harti From: Arnaud Lacombe [lacom...@gmail.com] Sent: Friday, April 29, 2011 3:37 AM To: Brandt, Hartmut Cc: Roman Divacky; hack...@freebsd.org Subject: Re: make question Hi, On Thu, Apr 28, 2011 at 11:52 AM, Hartmut Brandt hartmut.bra...@dlr.de wrote: I think we can change this, because it would break makefiles that assume that the entire script is given to the shell in one piece. I'm not sure to parse that. We can change it because it would break stuff. That said, if something was to be broken, it would already shows up when using -j N, and thus should be considered as a bug. - Arnaud ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: make question
On Fri, 29 Apr 2011, Roman Divacky wrote: RDOn Thu, Apr 28, 2011 at 08:50:27PM +0200, Hartmut Brandt wrote: RD On Thu, 28 Apr 2011, Roman Divacky wrote: RD RD RDOn Thu, Apr 28, 2011 at 05:52:58PM +0200, Hartmut Brandt wrote: RD RD Hi Roman, RD RD RD RD On Wed, 27 Apr 2011, Roman Divacky wrote: RD RD RD RD RDYou seem to have messed with bsd make so I have a question for you :) RD RD RD RD Yeah, that was some time ago ... RD RD RD RD RDWhen a job is about to be executed in JobStart() a pipe is created with RD RD RDits ends connected to job-inPipe/job-outPipe. When the job is actually RD RD RDcreated in JobExec() the ps.out is set to job-outPipe so that in RD RD RDJobDoOutput() we can read from that pipe and basically just parse the output RD RD RDfor shell-noPrint and leaving it out from the output. This is meant (I think) RD RD RDfor supressing the filter thing. Ie. that if we do some @command the RD RD RDrestoration of setting of quiet mode is filtered out. RD RD RD RD RD RD RD RD RDIn -B mode we do it differently, as we invoke one shell per command we don't RD RD RDhave to insert quiet/verbose commands and thus avoid all the piping/parsing RD RD RDdance. RD RD RD RD RD RDSo my question is - why don't we invoke one shell per command by default RD RD RDand avoid the piping/parsing? Is this because of performance? I think that RD RD RDthe piping/parsing of the output can have worse impact than invoking a shell RD RD RDfor every command. Especially given that most targets consists of just one RD RD RDcommand. RD RD RD RD The answer is in /usr/share/doc/psd/12.make. This is so one can write RD RD something like RD RD RD RD debug: RD RD DEBUG_FLAGS=-g RD RD for i in $(SUBDIR); do RD RD $(MAKE) -C $$i all RD RD done RD RD RD RD instead of: RD RD RD RD debug: RD RD DEBUG_FLAGS=-g \ RD RD for i in $(SUBDIR); do \ RD RD $(MAKE) -C $$i all ; \ RD RD done RD RD RD RD -B means 'backward compatible' and does what the original v7 make did: one RD RD shell per command. This means you don't have to write the backslashes and RD RD the shell variable will be seen in the sub-makes and programs. RD RD RD RD I think we can change this, because it would break makefiles that assume RD RD that the entire script is given to the shell in one piece. RD RD RD RDI think you answered the question why we parse the target. But I asked why RD RDwe parse the output from it. RD RD My intention was to say why we use one shell for all commands for a given RD rule. If we'd use one shell per line the above would not work, because the RD first shell would see just the environment variable assignment (which RD would be completly useless). The next shell would see a partial 'for' RD statement and complain, and would not have the environment variable and so RD on. So this is not so much about parsing, but about execution. RD RD I suppose that the tricky point is with @-lines in the middle of a RD multi-line script. RD RDUnless I am reading the code wrong the one shell per command is the default RDmode. RD RDsee in main.c: RD RD/* RD * Be compatible if user did not specify -j and did not explicitly RD * turned compatibility on RD */ RDif (!compatMake !forceJobs) RDcompatMake = TRUE; RD RDYou have to specify -j to turn off the compat mode. Wow. This breakage was introduced in our make in 1996 by an import from NetBSD (I did not check why they introduced it). I fail to see the logic in this handling of the -B option (if the user doesn't provide it, I (make) do it, unless the user said -j). But, the good side is, we can probably change the behavior of the non-compat mode, because the probability of there beeing makefiles that rely on it is now rather low. In any case I recommend to check what is the performance implication of executing a lot more shells in -j mode. I expect this to be in the noise level, but a check would not hurt... harti ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: make question
Hi, This whole area is quite a mess. See for instance bin/10985 on interactions between -j, -B and .NOTPARALLEL -- Bob Bishop r...@gid.co.uk ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: make question
Hi Roman, On Wed, 27 Apr 2011, Roman Divacky wrote: RDYou seem to have messed with bsd make so I have a question for you :) Yeah, that was some time ago ... RDWhen a job is about to be executed in JobStart() a pipe is created with RDits ends connected to job-inPipe/job-outPipe. When the job is actually RDcreated in JobExec() the ps.out is set to job-outPipe so that in RDJobDoOutput() we can read from that pipe and basically just parse the output RDfor shell-noPrint and leaving it out from the output. This is meant (I think) RDfor supressing the filter thing. Ie. that if we do some @command the RDrestoration of setting of quiet mode is filtered out. RD RD RDIn -B mode we do it differently, as we invoke one shell per command we don't RDhave to insert quiet/verbose commands and thus avoid all the piping/parsing RDdance. RD RDSo my question is - why don't we invoke one shell per command by default RDand avoid the piping/parsing? Is this because of performance? I think that RDthe piping/parsing of the output can have worse impact than invoking a shell RDfor every command. Especially given that most targets consists of just one RDcommand. The answer is in /usr/share/doc/psd/12.make. This is so one can write something like debug: DEBUG_FLAGS=-g for i in $(SUBDIR); do $(MAKE) -C $$i all done instead of: debug: DEBUG_FLAGS=-g \ for i in $(SUBDIR); do \ $(MAKE) -C $$i all ; \ done -B means 'backward compatible' and does what the original v7 make did: one shell per command. This means you don't have to write the backslashes and the shell variable will be seen in the sub-makes and programs. I think we can change this, because it would break makefiles that assume that the entire script is given to the shell in one piece. harti ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: make question
On Thu, Apr 28, 2011 at 05:52:58PM +0200, Hartmut Brandt wrote: Hi Roman, On Wed, 27 Apr 2011, Roman Divacky wrote: RDYou seem to have messed with bsd make so I have a question for you :) Yeah, that was some time ago ... RDWhen a job is about to be executed in JobStart() a pipe is created with RDits ends connected to job-inPipe/job-outPipe. When the job is actually RDcreated in JobExec() the ps.out is set to job-outPipe so that in RDJobDoOutput() we can read from that pipe and basically just parse the output RDfor shell-noPrint and leaving it out from the output. This is meant (I think) RDfor supressing the filter thing. Ie. that if we do some @command the RDrestoration of setting of quiet mode is filtered out. RD RD RDIn -B mode we do it differently, as we invoke one shell per command we don't RDhave to insert quiet/verbose commands and thus avoid all the piping/parsing RDdance. RD RDSo my question is - why don't we invoke one shell per command by default RDand avoid the piping/parsing? Is this because of performance? I think that RDthe piping/parsing of the output can have worse impact than invoking a shell RDfor every command. Especially given that most targets consists of just one RDcommand. The answer is in /usr/share/doc/psd/12.make. This is so one can write something like debug: DEBUG_FLAGS=-g for i in $(SUBDIR); do $(MAKE) -C $$i all done instead of: debug: DEBUG_FLAGS=-g \ for i in $(SUBDIR); do \ $(MAKE) -C $$i all ; \ done -B means 'backward compatible' and does what the original v7 make did: one shell per command. This means you don't have to write the backslashes and the shell variable will be seen in the sub-makes and programs. I think we can change this, because it would break makefiles that assume that the entire script is given to the shell in one piece. I think you answered the question why we parse the target. But I asked why we parse the output from it. Anyway, so you think it would be ok to change it to one shell per command and avoid the shell output parsing or not? I am interested in this so that make -j* lets the command know that the output is a TTY, eg. clang can emit coloured warnings. Thank you, roman ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: make question
On Thu, 28 Apr 2011, Roman Divacky wrote: RDOn Thu, Apr 28, 2011 at 05:52:58PM +0200, Hartmut Brandt wrote: RD Hi Roman, RD RD On Wed, 27 Apr 2011, Roman Divacky wrote: RD RD RDYou seem to have messed with bsd make so I have a question for you :) RD RD Yeah, that was some time ago ... RD RD RDWhen a job is about to be executed in JobStart() a pipe is created with RD RDits ends connected to job-inPipe/job-outPipe. When the job is actually RD RDcreated in JobExec() the ps.out is set to job-outPipe so that in RD RDJobDoOutput() we can read from that pipe and basically just parse the output RD RDfor shell-noPrint and leaving it out from the output. This is meant (I think) RD RDfor supressing the filter thing. Ie. that if we do some @command the RD RDrestoration of setting of quiet mode is filtered out. RD RD RD RD RD RDIn -B mode we do it differently, as we invoke one shell per command we don't RD RDhave to insert quiet/verbose commands and thus avoid all the piping/parsing RD RDdance. RD RD RD RDSo my question is - why don't we invoke one shell per command by default RD RDand avoid the piping/parsing? Is this because of performance? I think that RD RDthe piping/parsing of the output can have worse impact than invoking a shell RD RDfor every command. Especially given that most targets consists of just one RD RDcommand. RD RD The answer is in /usr/share/doc/psd/12.make. This is so one can write RD something like RD RD debug: RDDEBUG_FLAGS=-g RDfor i in $(SUBDIR); do RD$(MAKE) -C $$i all RDdone RD RD instead of: RD RD debug: RDDEBUG_FLAGS=-g \ RDfor i in $(SUBDIR); do \ RD$(MAKE) -C $$i all ; \ RDdone RD RD -B means 'backward compatible' and does what the original v7 make did: one RD shell per command. This means you don't have to write the backslashes and RD the shell variable will be seen in the sub-makes and programs. RD RD I think we can change this, because it would break makefiles that assume RD that the entire script is given to the shell in one piece. RD RDI think you answered the question why we parse the target. But I asked why RDwe parse the output from it. My intention was to say why we use one shell for all commands for a given rule. If we'd use one shell per line the above would not work, because the first shell would see just the environment variable assignment (which would be completly useless). The next shell would see a partial 'for' statement and complain, and would not have the environment variable and so on. So this is not so much about parsing, but about execution. I suppose that the tricky point is with @-lines in the middle of a multi-line script. RDAnyway, so you think it would be ok to change it to one shell per command and RDavoid the shell output parsing or not? Unless I misunderstand the question I would say no, because this would certainly render makefiles invalid that rely on the multi-line scripts beeing handled by a single shell. RDI am interested in this so that make -j* lets the command know that the RDoutput is a TTY, eg. clang can emit coloured warnings. Hmm. I see. Just a wild guess: couldn't we use a pty to talk to the shell? If that could work the question is of course what one would expect from something like: make 21 make.out harti ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: make question
Hi, On Thu, Apr 28, 2011 at 11:52 AM, Hartmut Brandt hartmut.bra...@dlr.de wrote: I think we can change this, because it would break makefiles that assume that the entire script is given to the shell in one piece. I'm not sure to parse that. We can change it because it would break stuff. That said, if something was to be broken, it would already shows up when using -j N, and thus should be considered as a bug. - Arnaud ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
make question
hi harti! You seem to have messed with bsd make so I have a question for you :) When a job is about to be executed in JobStart() a pipe is created with its ends connected to job-inPipe/job-outPipe. When the job is actually created in JobExec() the ps.out is set to job-outPipe so that in JobDoOutput() we can read from that pipe and basically just parse the output for shell-noPrint and leaving it out from the output. This is meant (I think) for supressing the filter thing. Ie. that if we do some @command the restoration of setting of quiet mode is filtered out. In -B mode we do it differently, as we invoke one shell per command we don't have to insert quiet/verbose commands and thus avoid all the piping/parsing dance. So my question is - why don't we invoke one shell per command by default and avoid the piping/parsing? Is this because of performance? I think that the piping/parsing of the output can have worse impact than invoking a shell for every command. Especially given that most targets consists of just one command. Thank you for the answer! Roman ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: BSD make question
On Thu, Aug 07, 2003 at 02:50:51PM -0400, Andrew Gallatin wrote: Ruslan Ermilov writes: On Thu, Aug 07, 2003 at 02:42:30PM -0400, Andrew Gallatin wrote: Using BSD make, how can I apply different rules based on different directories while using only a single makefile? There's a .CURDIR variable that can be used to conditionalize parts of a makefile. Ie, the appended Makefile results in the following compilations: gcc -DLIB -c lib/foo.c -o lib/foo.o gcc -DLIB -c lib/bar.c -o lib/bar.o gcc -DMCP -c mcp/baz.c -o mcp/baz.o Is it possible to do something similar with BSD make? It just works as is with bmake. What's your problem, Drew? ;-) $ make -n cc -O -pipe -march=pentiumpro -c lib/foo.c ;) But its missing the -DLIB or -DMCP. Thanks for the .CURDIR hint. Ah, didn't notice it. Try this: .for f in $(LIB) $(f:.c=.o): $(f) gcc -DLIB -c $ -o $@ .endfor .for f in $(MCP) $(f:.c=.o): $(f) gcc -DMCP -c $ -o $@ .endfor Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software Ltd, [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
Re: BSD make question
Ruslan Ermilov writes: Ah, didn't notice it. Try this: .for f in $(LIB) $(f:.c=.o): $(f) gcc -DLIB -c $ -o $@ .endfor Thanks! That works. Drew ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: BSD make question
Ruslan Ermilov writes: On Thu, Aug 07, 2003 at 02:42:30PM -0400, Andrew Gallatin wrote: Using BSD make, how can I apply different rules based on different directories while using only a single makefile? There's a .CURDIR variable that can be used to conditionalize parts of a makefile. Ie, the appended Makefile results in the following compilations: gcc -DLIB -c lib/foo.c -o lib/foo.o gcc -DLIB -c lib/bar.c -o lib/bar.o gcc -DMCP -c mcp/baz.c -o mcp/baz.o Is it possible to do something similar with BSD make? It just works as is with bmake. What's your problem, Drew? ;-) $ make -n cc -O -pipe -march=pentiumpro -c lib/foo.c ;) But its missing the -DLIB or -DMCP. Thanks for the .CURDIR hint. Drew ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: BSD make question
On Thu, Aug 07, 2003 at 02:42:30PM -0400, Andrew Gallatin wrote: Using BSD make, how can I apply different rules based on different directories while using only a single makefile? There's a .CURDIR variable that can be used to conditionalize parts of a makefile. Ie, the appended Makefile results in the following compilations: gcc -DLIB -c lib/foo.c -o lib/foo.o gcc -DLIB -c lib/bar.c -o lib/bar.o gcc -DMCP -c mcp/baz.c -o mcp/baz.o Is it possible to do something similar with BSD make? It just works as is with bmake. What's your problem, Drew? ;-) $ make -n cc -O -pipe -march=pentiumpro -c lib/foo.c cc -O -pipe -march=pentiumpro -c lib/bar.c cc -O -pipe -march=pentiumpro -c mcp/baz.c ### .SUFFIXES: .SUFFIXES: .o .c LIB=\ lib/foo.c \ lib/bar.c MCP=\ mcp/baz.c all: $(LIB:.c=.o) $(MCP:.c=.o) lib/%.o: lib/%.c gcc -DLIB -c $ -o $@ mcp/%.o: mcp/%.c gcc -DMCP -c $ -o $@ .PHONY: clean clean: rm -f $(LIB:.c=.o) $(MCP:.c=.o) ### -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software Ltd, [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
BSD make question
Using BSD make, how can I apply different rules based on different directories while using only a single makefile? Ie, the appended Makefile results in the following compilations: gcc -DLIB -c lib/foo.c -o lib/foo.o gcc -DLIB -c lib/bar.c -o lib/bar.o gcc -DMCP -c mcp/baz.c -o mcp/baz.o Is it possible to do something similar with BSD make? Drew ### .SUFFIXES: .SUFFIXES: .o .c LIB=\ lib/foo.c \ lib/bar.c MCP=\ mcp/baz.c all: $(LIB:.c=.o) $(MCP:.c=.o) lib/%.o: lib/%.c gcc -DLIB -c $ -o $@ mcp/%.o: mcp/%.c gcc -DMCP -c $ -o $@ .PHONY: clean clean: rm -f $(LIB:.c=.o) $(MCP:.c=.o) ### ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make question
On Fri, May 12, 2000 at 11:05:03PM +0200, Samuel Tardieu wrote: but make prefers the .ads.lo rule instead of the .adb.lo, despites the order in the .SUFFIXES. Using "make -d s" to trace dependencies and rules, I get: FWIW, this works correctly on ~3.4-R. It must have gotten broken somewhere between there and here. If you can locate the commit that actually broke it (or even tell us the version strings (`strings $(which make) | grep \$FreeBSD`) for your version), that would help to fix it. I am having difficulties to implement the following rule in BSD make: to produce file foobar.o, then start from foobar.adb if it exists, foobar.ads otherwise. I want this to be compatible with both BSD and GNU make. I tried: .SUFFIXES: .adb .ads .lo .adb.lo: command .ads.lo: command [...] SuffFindDeps (broca-exceptions.lo) trying broca-exceptions.S...not there trying broca-exceptions.adb...got it using existing source broca-exceptions.ads applying .ads - .lo to "broca-exceptions.lo" broca-exceptions.adb has been found and should have been used, but this "using existing source" message (coming after!) bugs me. The wrong rule is then being selected. Any hint of where it can come from? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message -- Signature withheld by request of author. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Make question
Am I confused or is there a bug in make(1).. ? Why is 'make foo' failing but 'gmake foo' succeeding? $ cat makefile foo: var1=yes; test "$$var1" = "no" var2=". $$var2"; echo OK $ make foo var1=yes; test "$var1" = "no" var2=". $var2"; echo OK *** Error code 1 Stop in /root. $ gmake foo var1=yes; test "$var1" = "no" var2=". $var2"; echo OK OK This happens on -current and -stable. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
