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
On Fri, 29 Apr 2011, Roman Divacky wrote: RD>On Thu, Apr 28, 2011 at 08:50:27PM +0200, Hartmut Brandt wrote: RD>> On Thu, 28 Apr 2011, Roman Divacky wrote: RD>> RD>> RD>On 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>> RD>You 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>> RD>When a job is about to be executed in JobStart() a pipe is created with RD>> RD>> RD>its ends connected to job->inPipe/job->outPipe. When the job is actually RD>> RD>> RD>created in JobExec() the ps.out is set to job->outPipe so that in RD>> RD>> RD>JobDoOutput() we can read from that pipe and basically just parse the output RD>> RD>> RD>for shell->noPrint and leaving it out from the output. This is meant (I think) RD>> RD>> RD>for supressing the "filter" thing. Ie. that if we do some @command the RD>> RD>> RD>restoration of setting of quiet mode is filtered out. RD>> RD>> RD> RD>> RD>> RD> RD>> RD>> RD>In -B mode we do it differently, as we invoke one shell per command we don't RD>> RD>> RD>have to insert quiet/verbose commands and thus avoid all the piping/parsing RD>> RD>> RD>dance. RD>> RD>> RD> RD>> RD>> RD>So my question is - why don't we invoke one shell per command by default RD>> RD>> RD>and avoid the piping/parsing? Is this because of performance? I think that RD>> RD>> RD>the piping/parsing of the output can have worse impact than invoking a shell RD>> RD>> RD>for every command. Especially given that most targets consists of just one RD>> RD>> RD>command. 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>> RD>I think you answered the question why we parse the target. But I asked why RD>> RD>we 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> RD>Unless I am reading the code wrong the "one shell per command" is the default RD>mode. RD> RD>see in main.c: RD> RD>/* RD> * Be compatible if user did not specify -j and did not explicitly RD> * turned compatibility on RD> */ RD>if (!compatMake && !forceJobs) RD>compatMake = TRUE; RD> RD>You 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
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 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 Thu, Apr 28, 2011 at 08:50:27PM +0200, Hartmut Brandt wrote: > On Thu, 28 Apr 2011, Roman Divacky wrote: > > RD>On 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>> RD>You seem to have messed with bsd make so I have a question for you :) > RD>> > RD>> Yeah, that was some time ago ... > RD>> > RD>> RD>When a job is about to be executed in JobStart() a pipe is created > with > RD>> RD>its ends connected to job->inPipe/job->outPipe. When the job is > actually > RD>> RD>created in JobExec() the ps.out is set to job->outPipe so that in > RD>> RD>JobDoOutput() we can read from that pipe and basically just parse the > output > RD>> RD>for shell->noPrint and leaving it out from the output. This is meant > (I think) > RD>> RD>for supressing the "filter" thing. Ie. that if we do some @command the > RD>> RD>restoration of setting of quiet mode is filtered out. > RD>> RD> > RD>> RD> > RD>> RD>In -B mode we do it differently, as we invoke one shell per command > we don't > RD>> RD>have to insert quiet/verbose commands and thus avoid all the > piping/parsing > RD>> RD>dance. > RD>> RD> > RD>> RD>So my question is - why don't we invoke one shell per command by > default > RD>> RD>and avoid the piping/parsing? Is this because of performance? I think > that > RD>> RD>the piping/parsing of the output can have worse impact than invoking > a shell > RD>> RD>for every command. Especially given that most targets consists of > just one > RD>> RD>command. > 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> > RD>I think you answered the question why we parse the target. But I asked why > RD>we 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. > RD>Anyway, so you think it would be ok to change it to one shell per command > and > RD>avoid 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. > RD>I am interested in this so that "make -j*" lets the command know that the > RD>output 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 2>&1 >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
On Apr 28, 2011, at 7:37 PM, Arnaud Lacombe wrote: > On Thu, Apr 28, 2011 at 11:52 AM, Hartmut Brandt > 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
Hi, On Thu, Apr 28, 2011 at 11:52 AM, Hartmut Brandt 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 Thu, 28 Apr 2011, Roman Divacky wrote: RD>On 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>> RD>You seem to have messed with bsd make so I have a question for you :) RD>> RD>> Yeah, that was some time ago ... RD>> RD>> RD>When a job is about to be executed in JobStart() a pipe is created with RD>> RD>its ends connected to job->inPipe/job->outPipe. When the job is actually RD>> RD>created in JobExec() the ps.out is set to job->outPipe so that in RD>> RD>JobDoOutput() we can read from that pipe and basically just parse the output RD>> RD>for shell->noPrint and leaving it out from the output. This is meant (I think) RD>> RD>for supressing the "filter" thing. Ie. that if we do some @command the RD>> RD>restoration of setting of quiet mode is filtered out. RD>> RD> RD>> RD> RD>> RD>In -B mode we do it differently, as we invoke one shell per command we don't RD>> RD>have to insert quiet/verbose commands and thus avoid all the piping/parsing RD>> RD>dance. RD>> RD> RD>> RD>So my question is - why don't we invoke one shell per command by default RD>> RD>and avoid the piping/parsing? Is this because of performance? I think that RD>> RD>the piping/parsing of the output can have worse impact than invoking a shell RD>> RD>for every command. Especially given that most targets consists of just one RD>> RD>command. 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> RD>I think you answered the question why we parse the target. But I asked why RD>we 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. RD>Anyway, so you think it would be ok to change it to one shell per command and RD>avoid 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. RD>I am interested in this so that "make -j*" lets the command know that the RD>output 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 2>&1 >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
On Thu, Apr 28, 2011 at 05:52:58PM +0200, Hartmut Brandt wrote: > Hi Roman, > > On Wed, 27 Apr 2011, Roman Divacky wrote: > > RD>You seem to have messed with bsd make so I have a question for you :) > > Yeah, that was some time ago ... > > RD>When a job is about to be executed in JobStart() a pipe is created with > RD>its ends connected to job->inPipe/job->outPipe. When the job is actually > RD>created in JobExec() the ps.out is set to job->outPipe so that in > RD>JobDoOutput() we can read from that pipe and basically just parse the > output > RD>for shell->noPrint and leaving it out from the output. This is meant (I > think) > RD>for supressing the "filter" thing. Ie. that if we do some @command the > RD>restoration of setting of quiet mode is filtered out. > RD> > RD> > RD>In -B mode we do it differently, as we invoke one shell per command we > don't > RD>have to insert quiet/verbose commands and thus avoid all the piping/parsing > RD>dance. > RD> > RD>So my question is - why don't we invoke one shell per command by default > RD>and avoid the piping/parsing? Is this because of performance? I think that > RD>the piping/parsing of the output can have worse impact than invoking a > shell > RD>for every command. Especially given that most targets consists of just one > RD>command. > > 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
Hi Roman, On Wed, 27 Apr 2011, Roman Divacky wrote: RD>You seem to have messed with bsd make so I have a question for you :) Yeah, that was some time ago ... RD>When a job is about to be executed in JobStart() a pipe is created with RD>its ends connected to job->inPipe/job->outPipe. When the job is actually RD>created in JobExec() the ps.out is set to job->outPipe so that in RD>JobDoOutput() we can read from that pipe and basically just parse the output RD>for shell->noPrint and leaving it out from the output. This is meant (I think) RD>for supressing the "filter" thing. Ie. that if we do some @command the RD>restoration of setting of quiet mode is filtered out. RD> RD> RD>In -B mode we do it differently, as we invoke one shell per command we don't RD>have to insert quiet/verbose commands and thus avoid all the piping/parsing RD>dance. RD> RD>So my question is - why don't we invoke one shell per command by default RD>and avoid the piping/parsing? Is this because of performance? I think that RD>the piping/parsing of the output can have worse impact than invoking a shell RD>for every command. Especially given that most targets consists of just one RD>command. 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"
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
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
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]"
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: > > > .ads.lo: > > [...] > > 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
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: .ads.lo: 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: 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
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
