Re: 'How makefiles are remade'

Ted Stern wrote: On 20 Apr 2004 at 23:03 PDT, [EMAIL PROTECTED] wrote: Is there any way to cause make to exit without error? Hi Jim, For this problem, I think this might work SHELL=/bin/ksh (or bash) target: dependency return 1 Same as /bin/false (returns non-zero for scripts) R

RE: Cygwin make thinks a statement can be neither true nor false....

%% "Dave Korn" <[EMAIL PROTECTED]> writes: dk> Hmm. So might there be call for a variant of dk> --warn-undefined-variables that only warns about those for which dk> $(origin ..) returns undefined? That way makefiles could supply dk> empty-but-overrideable definitions of CFLAGS etc, and e

RE: Cygwin make thinks a statement can be neither true nor false....

> -Original Message- > From: Paul Smith On Behalf Of Paul D. Smith > Sent: 20 April 2004 19:35 > To: Dave Korn > %% "Dave Korn" writes: > > dk> [ This is getting off topic for the cygwin list, > I'll leave it here for now but I'm happy to re

Re: [PATCH] pattern-specific variable expansion

> Yeah, I thought so too at the beginning. I had to read that bug report > about 10 times to understand what's going on there ;-(. My conclusion > is that things that are discussed in that bug report and my patch are > unrelated. OK, I'll check this change out. Thanks. -- -

Re: 'How makefiles are remade'

Paul D. Smith wrote: The reality is that GNU make is not designed to behave the way you want it to behave. It's designed to work like this: 1) All makefiles are read in (the main makefile, included makefiles, stuff in MAKEFILES, etc.) 2) Make examines every makefile that it read in and trie

Re: [PATCH] order-only prerequisite ends up in $

%% Jim <[EMAIL PROTECTED]> writes: j> Absolutely... j> all: junk.test j> $.test:%.c | thing j>touch $@ j> junk.c thing: j>touch $@ j> make... j> (touches thing and junk.c to create them) j> then after every touch of 'thing' junk.test is touched. This is a bug in make

Re: 'How makefiles are remade'

Noel Yap wrote: Can you state what you want to do in development process terms, rather than makefile implementation terms, please? Maybe there's another solution that doesn't involve extremely complicated makefiles (maybe it doesn't even involve make ;-). Well okay, I'll consider how much aft

Re: [PATCH] order-only prerequisite ends up in $

Paul D. Smith wrote: %% Jim <[EMAIL PROTECTED]> writes: j> Absolutely... j> all: junk.test j> $.test:%.c | thing j> touch $@ j> junk.c thing: j> touch $@ j> make... j> (touches thing and junk.c to create them) j> then after every touch of 'thing' junk.test is t

Re: 'How makefiles are remade'

%% Jim <[EMAIL PROTECTED]> writes: j> Paul D. Smith wrote: >> Yes it is, if you write it correctly. j> (sorry, this is such an attacking statement...) Sorry; I didn't mean it like that. I just meant you have to write it in a very specific way ("correctly") or it won't work. The reality

Re: 'How makefiles are remade'

Paul D. Smith wrote: Making it work the way you want (if I understand you correctly), where steps 2 and 3 are performed in a loop so that the re-exec happens immediately when each makefile is rebuilt instead of after all the makefiles are rebuilt, is simply not the way make is designed. Trying to

Re: 'How makefiles are remade'

Jim wrote: Some ideas I've toyed with - a make preprocessor... alternative makes - cook, hmm can't think of the others off the top of my head.. I've been saying this for several years now, but one day I'll learn cook :-) Make is good... there have been several things I've wanted that I couldn't

Re: [PATCH] order-only prerequisite ends up in $

Noel Yap wrote: Jim wrote: I'm not really sure if this falls in the same category, but the rule base is a pattern rule... it seems that something like %.o:%.c | $(intermdiate_path) intermediate_path is no longer order only, it is instead a valid rule, and that being a directory means it's oft

Re: [PATCH] order-only prerequisite ends up in $

Jim wrote: I'm not really sure if this falls in the same category, but the rule base is a pattern rule... it seems that something like %.o:%.c | $(intermdiate_path) intermediate_path is no longer order only, it is instead a valid rule, and that being a directory means it's often newer then the

Re: 'How makefiles are remade'

Can you state what you want to do in development process terms, rather than makefile implementation terms, please? Maybe there's another solution that doesn't involve extremely complicated makefiles (maybe it doesn't even involve make ;-). Thanks, Noel Jim wrote: If there was just a way to end m

Re: 'How makefiles are remade'

Jim wrote: Maybe you could chalk this up to a documentation bug, it says whenever ANY included makefile is read, it reloads, the above trace indicates that two rules to generate makefiles were performed before reloading... I still don't understand what the problem is; the documentation, accordin

Re: [PATCH] order-only prerequisite ends up in $

I'm not really sure if this falls in the same category, but the rule base is a pattern rule... it seems that something like %.o:%.c | $(intermdiate_path) intermediate_path is no longer order only, it is instead a valid rule, and that being a directory means it's often newer then the .o in certa

Re: 'How makefiles are remade'

If there was just a way to end make with the last executed make's status (including when that make ends with success... otherwise all other targets are processed again, but with an invalid state, since those files which were modified were not reloaded) that would be great, and or to force a rel

Re: 'How makefiles are remade'

Paul D. Smith wrote: Yes it is, if you write it correctly. (sorry, this is such an attacking statement...) The correct way being that a makefile includes one and only one other makefile? I mean sure, if the documentation didn't say if ANY change, then the make is restrated (one would assume th