$(and) and $(or) not working
I'm using the following: yapn:[EMAIL PROTECTED]:~/proj/aoeu make --version GNU Make 3.81beta4 Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. This program built for i486-pc-linux-gnu And the $(and) and $(or) functions always return empty. Has anyone else experienced this? Thanks, Noel ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: need access to Makefile path
Boris Kolpackov wrote: Noel Yap [EMAIL PROTECTED] writes: Try: $ cat bar.make include foo.make $(warning $(dir $(word $(words $(MAKEFILE_LIST)),$(MAKEFILE_LIST You gotta be kidding me! p := $(dir $(word $(words $(MAKEFILE_LIST)),$(MAKEFILE_LIST))) include foo.make $(warning $p) Like I said, explicitly doing this in the makefiles that need is becomes quite messy. Moreover, I haven't done any timings, but I'd hazard a guess that this is much slower than setting __FILE__ for each included makefile. I never said MAKEFILE_LIST is unusable; I said it's very lacking and that MAKEFILE_STACK would be better if it existed. Noel ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: need access to Makefile path
BTW, I also said that such a variable can be overwritten by the included makefile. I think it has a pretty high probability of being overwritten and the probability increases the more makefiles are included. For example, adding to the example below: # foo.make p := $(dir $(word $(words $(MAKEFILE_LIST)),$(MAKEFILE_LIST))) include another.make $(warning $p) # another.make p := $(dir $(word $(words $(MAKEFILE_LIST)),$(MAKEFILE_LIST))) include one-more.make $(warning $p) How are you going to guarantee that the names of the variables are unique? Do you still think that MAKEFILE_LIST is a scalable, viable solution? Noel Boris Kolpackov wrote: Noel Yap [EMAIL PROTECTED] writes: Try: $ cat bar.make include foo.make $(warning $(dir $(word $(words $(MAKEFILE_LIST)),$(MAKEFILE_LIST You gotta be kidding me! p := $(dir $(word $(words $(MAKEFILE_LIST)),$(MAKEFILE_LIST))) include foo.make $(warning $p) ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: need access to Makefile path
Unless MAKEFILE_LIST is used before any other includes, using the trick below doesn't work. I think it's also quite messy to have to create explicitly a variable to hold this information in each makefile that needs it. Moreover, there's no guarantee that someone won't overwrite the variable in which this information is stored. I think MAKEFILE_LIST is very lacking. A MAKEFILE_STACK would be much better. In my build system, I wrote an include-makefile macro that'll define __FILE__ and keep a MAKEFILE_STACK such that an included makefile always knew where it was in relation to its includer (assuming relative paths are used). Doing this allows for position-independent makefiles, which, in turn allows for modular, non-recursive makefiles. For example, the following module makefile may exist: # c++/GNUcommon.mk $(call include-makefile,$(call dirname,$(__FILE__))/GNUactions.mk) $(call include-makefile,$(call dirname,$(__FILE__))/GNUrules.mk) and the client may include it in whichever way they wish: # GNUmakefile $(call include-makefile,/path/to/makefiles/1.0/c++/GNUcommon.mk) Noel Boris Kolpackov wrote: Dave Yost [EMAIL PROTECTED] writes: Consider a Makefile that starts thus: include ../../../Makefile-master It would be nice if this included Makefile-master knew where it was, $(dir $(word $(words $(MAKEFILE_LIST)),$(MAKEFILE_LIST))) -boris ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: need access to Makefile path
Although it's reminiscent of DOS, I like your use of '%' in private variable names. There's a lot of meat in this. It'll take some time for me to chew on it and digest. One thing I can say right now is, if you had an include-makefile function, the below would become: $(call include-makefile,foo.make) # frame-enter and frame-leave are implicit Thanks, Noel Boris Kolpackov wrote: Noel Yap [EMAIL PROTECTED] writes: How are you going to guarantee that the names of the variables are unique? You could use variable framing ;-) What's variable framing? You can say $(call frame-enter) include foo.make $(call frame-leave) and any changes to variables inside the frame will not affect anything outside the frame. See http://kolpackov.net/projects/build/ if you are interested in details. -boris ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: need access to Makefile path
Boris Kolpackov wrote: One thing I can say right now is, if you had an include-makefile function, the below would become: $(call include-makefile,foo.make) # frame-enter and frame-leave are implicit Well, when you include a makefile you would probably want it's variable definitions too so I am not so sure you would want to frame inclusion. In build there is a function $(call import) that creates a frame and then includes a makefile. I see. Thanks, Noel ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: need access to Makefile path
Boris Kolpackov wrote: Noel Yap [EMAIL PROTECTED] writes: How are you going to guarantee that the names of the variables are unique? You could use variable framing ;-) What's variable framing? Do you still think that MAKEFILE_LIST is a scalable, viable solution? It is good enough to bootstrap and build on top. I'll agree here :-) I do this myself before my include-makefile macro is defined. Noel ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: need access to Makefile path
Try: $ cat bar.make include foo.make $(warning $(dir $(word $(words $(MAKEFILE_LIST)),$(MAKEFILE_LIST Noel Boris Kolpackov wrote: Noel Yap [EMAIL PROTECTED] writes: Unless MAKEFILE_LIST is used before any other includes, using the trick below doesn't work. $ cat makefile include foo.make include $(CURDIR)/bar.make $ cat foo.make $ cat bar.make $(warning $(dir $(word $(words $(MAKEFILE_LIST)),$(MAKEFILE_LIST $ /usr/bin/make --version GNU Make 3.80 $ /usr/bin/make /tmp/bar.make:1: /tmp/ make: *** No targets. Stop. Seems to work pretty well, huh? -boris ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: [RFC] .NOT_DEFAULT: target
Boris Kolpackov wrote: Alternatively, if you have a makefile which is always included at the top (say your bootstrap.make file) you can put the all target in that file as the first thing: Now you are forcing user to use the same name for default target which is not always acceptable (well, at least not in my case). I do exactly this. Unless the user wants to use the default target name (default in my case) for their own purposes, I see no problem with this. They can always do something like: default: my-own-default in their makefiles. If you /really/ want to make this open, you can use a macro (again, so long as they don't use the same macro). Mm. I don't know about this. It seems like it's the wrong way around... if what you want to have is the default target, why have people declare everything that _cannot_ be the default? Why not just declare what _IS_ the default? A few thoughts: - .NOT_DEFAULT is meant for the build system developers, not people ;-). Now GNU make has powerful enough inclusions/scripting mechanisms that make generic build systems possible. There are however features that are still makefile-is-one-big-file-minded. Default target is first target is one of them. - Default target is the choice of a user makefile not the build system. So default target is most likely going to be specified in a user makefile. Putting it in other words, targets declared by the build system should not be default. That's why we may want a mechanism to express that. I feel the best mechanism to express that would be for the client makefile to say what it wants the default target to be. Yes, one can consider this to be messy. IMHO, I don't like the first target is the default target rule, but it's something we have to live with. Given this, it's up to the build system developers to specify what the default target is as part of their contract to the users. MTC, Noel ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
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 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 reload... ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
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, according to the above, indicates that whenever any makefile is /read/ (ie included, not built), it reloads. Noel ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
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 make it behave this way is extremely tricky, as shown by my example. IMHO, it's also a gross hack that'll slow down make processing considerably; for each target built, make would have to check if the target was included -- that can potentially be lots of checks. Noel ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
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 touched. This is a bug in make 3.80; it's been fixed already. Ahh, that explains why it works for me; I must've ran into this early on and had the patch installed. Noel ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: 'How makefiles are remade'
I've done what the documentation describes many, many times. It's always worked for me.
Which make are you using? Are you sure it's GNU make?
http://make.paulandlesley.org/autodep.html provides more examples on how to rebuild included makefiles.
HTH,
Noel
Jim wrote:
http://www.gnu.org/software/make/manual/html_mono/make.html#SEC20
After all makefiles have been checked, if any have actually been
changed, make starts with a clean slate and reads all the makefiles over
again. (It will also attempt to update each of them over again, but
normally this will not change them again, since they are already up to
date.)
This doesn't work. I actually have to call Make myself to restart it,
but then I MUST kill make also by using /bin/false. This then error
results all makes and is really a very unclean way of making make exit.
Two things...
1 it would be nice if there was a $(REMAKE) or something which could
forcably invoke - remove all makefiles, and reload them, or a $(EXIT)
which would cause make to end its execution.
2 The following makefile doesn't really work right the 'y'
makefile is built using 'x's which were read at include time, even if
'x' itself is updated...
The attached source 'echoto' program just gathers command line
parameters and echos them into a file. If a -c option is used it writes
a tab character... I needed this cause I couldn't figure out how to do...
@echo 'tab@echo tabhey we made it y' x
the second tab in there kept going away...
The normal steps this Makefile executes...
Might have to handbuild echoto...
fakeall:
build echoto if it doesn't already exist.
include x
x:Makefile (and a couple extra files to touch)
if makefile has changed, rebuild x...
content of x:
include y
y: x Makefile (extra)
echo fakeall: y
echo \t echo hey we made it: TICKS
TICKS is a value read by the main makefile, and is built written
verbatim expanded into X, which causes an update to TICKS= to rebuild Y
with the appropriate value.
include ticks
ticks: Makefile (extra touchable flies)
echo TICKS=(roman numerate next tick) ticks
echo Current Tick: $(TICK)
So, if makefile or one of the extra files (bob, dillon for the two I
chose) is changed, ticks is incremented, it's new value is output into
ticks, and the current value is printed.
The first pass, include for ticks and x fail to get included (they do
not exist), ticks is created, and a new value for TICKS is created. (It
is not reloaded at this point) then X is created with the current blank
value for TICKS, which in turn creates y with the current rules for x.
(touch Makefile)
ticks is updated (prints the prior value, writes the current), x is
updated, using the prior value of TICKS (again, not the newly computed
value), then Y is updated using the prior rules for x, not the newly
output ones. [ TICKS=II, x echos we made it: I y, y still has 'we
made it: blank'
(touch Makefile)
ticks is updated, x is updated using the originally loaded ticks, and y
is created using the originally loaded x, not the one which gets updated
after ticks is updated...
This is a log of the state of the system after the second touch is done.
M:\tmp\makemakemake
Prior Ticks : II(echos prior value)
hey we made it:I(is created from x, and reflects that value)
M:\tmp\makemaketype ticks
TICKS=III(TICKS really was updated to III, since prior was II that's
okay)
M:\tmp\makemaketype x
include y
y: x bob
@echo fakeall: y
@./echoto -c y @echo hey we made it:II (this is prior TICKS,
not curent TICKS which is defined in the ticks file)
M:\tmp\makemaketype y
fakeall:
@echo hey we made it:I (this is the prior prior TICKS from two
touches ago)
#include stdio.h
int main( int argc, char **argv )
{
int n;
int iscmd = 0;
char cmd[8192];
if( argc 2 )
{
printf( usage: echoto [-x] output command line.\n );
printf( usage:c : prefix with a tab character..\n );
return 1;
}
n = 1;
while( argv[n][0] == '-' )
{
int c = 1;
while( argv[n] argv[n][c] ) switch( argv[n][c] )
{
case 'c':
case 'C':
iscmd = 1;
c++;
break;
default:
printf( Unknown option: %c\n, argv[n][c] );
c++;
break;
}
n++;
}
{
int ofs = 0;
FILE *out = fopen( argv[n], at+ );
if( !out )
out =fopen( argv[n], wt );
if( !out )
{
printf( echoto: Failed to open %s for output\n, argv[n] );
return 1;
}
if( iscmd )
Re: Cygwin make thinks a statement can be neither true nor false....
Paul D. Smith wrote: %% Dave Korn [EMAIL PROTECTED] writes: The problem is that in many makefiles you tend to get a lot of false positives. For example, many makefiles leave certain variables to be set by the user, like CPPFLAGS or CFLAGS. If you do that in your makefiles, and the user has no reason to set them, then you'll get lots o' warnings. You can work around this with various GNU make-specific fanciness, but most developers don't bother. The largest problem I've seen is when using $(call) on a macro that's not defined (either because the makefile that defines the macro hasn't been included, or there's a typo at the call site). A separate option that would either warn or error upon trying to call undefined macros would be great. What do you think? Noel ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: 'How makefiles are remade'
It would help if you can post a /minimal/ makefile that demonstrates the problem.
Noel
Jim wrote:
Noel Yap wrote:
I've done what the documentation describes many, many times. It's
always worked for me.
Which make are you using? Are you sure it's GNU make?
3.80 positive it is gnu make.
http://make.paulandlesley.org/autodep.html provides more examples on
how to rebuild included makefiles.
HTH,
Noel
Jim wrote:
http://www.gnu.org/software/make/manual/html_mono/make.html#SEC20
After all makefiles have been checked, if any have actually been
changed, make starts with a clean slate and reads all the makefiles
over again. (It will also attempt to update each of them over again,
but normally this will not change them again, since they are already
up to date.)
This doesn't work. I actually have to call Make myself to restart
it, but then I MUST kill make also by using /bin/false. This then
error results all makes and is really a very unclean way of making
make exit.
Two things...
1 it would be nice if there was a $(REMAKE) or something which
could forcably invoke - remove all makefiles, and reload them, or a
$(EXIT) which would cause make to end its execution.
2 The following makefile doesn't really work right the 'y'
makefile is built using 'x's which were read at include time, even if
'x' itself is updated...
The attached source 'echoto' program just gathers command line
parameters and echos them into a file. If a -c option is used it
writes a tab character... I needed this cause I couldn't figure out
how to do...
@echo 'tab@echo tabhey we made it y' x
the second tab in there kept going away...
The normal steps this Makefile executes...
Might have to handbuild echoto...
fakeall:
build echoto if it doesn't already exist.
include x
x:Makefile (and a couple extra files to touch)
if makefile has changed, rebuild x...
content of x:
include y
y: x Makefile (extra)
echo fakeall: y
echo \t echo hey we made it: TICKS
TICKS is a value read by the main makefile, and is built
written verbatim expanded into X, which causes an update to TICKS= to
rebuild Y with the appropriate value.
include ticks
ticks: Makefile (extra touchable flies)
echo TICKS=(roman numerate next tick) ticks
echo Current Tick: $(TICK)
So, if makefile or one of the extra files (bob, dillon for the two I
chose) is changed, ticks is incremented, it's new value is output
into ticks, and the current value is printed.
The first pass, include for ticks and x fail to get included (they do
not exist), ticks is created, and a new value for TICKS is created.
(It is not reloaded at this point) then X is created with the current
blank value for TICKS, which in turn creates y with the current rules
for x.
(touch Makefile)
ticks is updated (prints the prior value, writes the current), x is
updated, using the prior value of TICKS (again, not the newly
computed value), then Y is updated using the prior rules for x, not
the newly output ones. [ TICKS=II, x echos we made it: I y, y
still has 'we made it: blank'
(touch Makefile)
ticks is updated, x is updated using the originally loaded ticks, and
y is created using the originally loaded x, not the one which gets
updated after ticks is updated...
This is a log of the state of the system after the second touch is done.
M:\tmp\makemakemake
Prior Ticks : II(echos prior value)
hey we made it:I(is created from x, and reflects that value)
M:\tmp\makemaketype ticks
TICKS=III(TICKS really was updated to III, since prior was II
that's okay)
M:\tmp\makemaketype x
include y
y: x bob
@echo fakeall: y
@./echoto -c y @echo hey we made it:II (this is prior TICKS,
not curent TICKS which is defined in the ticks file)
M:\tmp\makemaketype y
fakeall:
@echo hey we made it:I (this is the prior prior TICKS from
two touches ago)
#include stdio.h
int main( int argc, char **argv )
{
int n;
int iscmd = 0;
char cmd[8192];
if( argc 2 )
{
printf( usage: echoto [-x] output command line.\n );
printf( usage:c : prefix with a tab character..\n );
return 1;
}
n = 1;
while( argv[n][0] == '-' )
{
int c = 1;
while( argv[n] argv[n][c] ) switch( argv[n][c] )
{
case 'c':
case 'C':
iscmd = 1;
c++;
break;
default:
printf( Unknown option: %c\n, argv[n][c] );
c++;
break;
}
n++;
}
{
int ofs = 0;
FILE *out = fopen( argv[n], at+ );
if( !out )
out =fopen( argv[n], wt );
if( !out )
{
printf( echoto: Failed to open %s for output\n, argv[n] );
return 1;
}
if( iscmd )
fprintf( out, \t );
for( n++; n argc; n
Re: 'How makefiles are remade'
This makefile works: .PHONY: all all: ; include ticks ticks: @touch $(@) Try adding to it little by little until it stops working. Noel Jim wrote: Noel Yap wrote: It would help if you can post a /minimal/ makefile that demonstrates the problem. right here - there is no fewer statements that can be done to make a makefile which creates a makefile which creates a makefile (and no that's not redunant). It was a attached - here it is done verbatim. I suppose I can strip off the remake - since if make actually worked, it would be unessecary .PHONY: all all: ; include ticks ticks: Makefile bob dillon @echo TICKS=$(patsubst %ILI,%L,$(patsubst %IX,%IL,$(patsubst %IXI,%X,$(patsubst %VIV,%IX,$(patsubst %IVI,%V,$(patsubst %,%IV,$(TICKS)I))ticks @echo Prior Ticks : $(TICKS) include x bob dillon: @echo . $@; x:Makefile bob dillon @echo include y x @echo y: $@ $? x @echoto -c x @echo fakeall: \y @echoto -c x @./echoto -c y @echo hey we made it:$(TICKS) Makefile: ; ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: 'How makefiles are remade'
Jim wrote: Noel Yap wrote: This makefile works: .PHONY: all all: ; include ticks ticks: @touch $(@) How do you know? Sure the rule is done, it doesn't mean that ticks is reloaded Since we have this sort of thing in our makefiles, I'm pretty sure it gets reloaded. The above can easily be modified to show this. Noel ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: 'How makefiles are remade'
Jim wrote: Hmm not sure how eval equates to include... Since the actual end in mind is a Makefile.cache, which is the literal expanded targets, rules nessecary to genearte the product defined by the makefile... This must be dependant on all makefiles which may have changed... the final result is a huge tree of includable .cache files which have the rules needed for all dependants (libraries in other branches, etc ) I'm not sure, but the following may help: # sets __FILE__ macro to file to be included, then includes the file. # allows included file to know where it is in relation to includer. # caching of included makefile is allowed if $(2)!contents is defined as the contents of the makefile. # $(1) is the include method, either include or -include # $(2) is the file to be included # $(3) is the includer define _include-makefile __FILE__ := $(2) ifndef $(2)!contents # using an order rule suppresses the error when $(1) is include ifeq ($(wildcard $(dir $(2))),) $(shell mkdir -p $(dir $(2))) endif $(1) $(2) else $$(eval $$($(2)!contents)) endif __FILE__ := $(3) endef # optionally include makefile passing in its name as __FILE__ # allows included file to know where it is in relation to includer. # caching of included makefile is allowed if $(2)!contents is defined as the contents of the makefile. # $(1) is the file to be included -include-makefile = $(foreach \ m, \ $(1), \ $(eval $(call _include-makefile,-include,$(m),$(__FILE__ # include makefile passing in its name as __FILE__ # allows included file to know where it is in relation to includer. # caching of included makefile is allowed if $(2)!contents is defined as the contents of the makefile. # $(1) is the file to be included include-makefile = $(foreach \ m, \ $(1), \ $(eval $(call _include-makefile,include,$(m),$(__FILE__ If the file's corresponding !contents macro is defined, it the macro just eval's it. Usually, the !contents macro is defined within the file itself. HTH, Noel ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: 'How makefiles are remade'
Jim wrote: Noel Yap wrote: okay so I extended it some... and this fails. .PHONY:all all: junk; @echo $(TICKS) include ticks2 ticks2: @echo TICKS=a number ticks2 include make2 make2: @echo junk: make2 @echo echo $(TICKS) make2 if ticks2 were really reloaded then make2 would not have a blank value for $(TICKS) OK, I think I'm starting to understand what you want to do. Have you tried doing the include make2 inside tick2? Noel ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: 'How makefiles are remade'
Jim wrote: Well that's an ugly thing :) The amount of hairy code in a system stays constant :-) Although the definition may be ugly, it's usage is pretty simple: $(call include-makefile,my-makefile) $(1) $(2) within the macro will include a makefile on the fly eh? but sometime after all the already included files are validated for rules, no? I'm not sure what you're asking. Can you elaborate, please? And I think that won't help with reload... Actually, correct me if I'm wrong. It sounds like you want to count the number of times the makefiles include another makefile. If so, that logic can be stuck into the _include-makefile macro. Noel ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: [PATCH] order-only prerequisite ends up in $
Once this patch is installed, does gmake -npqr | grep '%r:' output the proper thing? If so, I suspect this patch will fix much of the odd behaviour I've seen with regards to implicit rules and order rules.
Thanks,
Noel
Boris Kolpackov wrote:
Good day,
The following makefile prints baz foo baz instead of foo foo baz.
%r: | baz
@echo $ $^ $|
bar: foo
foo:;@:
baz:;@:
In command.c in function set_file_variables $ is initialized with the
first prerequisite. While in most cases this would be a normal prerequisite
in case of an implicit rules it could be an order-only one. Patch is
attached.
hth,
-boris
Index: commands.c
===
RCS file: /cvsroot/make/make/commands.c,v
retrieving revision 1.55
diff -u -r1.55 commands.c
--- commands.c 24 Feb 2004 13:50:20 - 1.55
+++ commands.c 19 Apr 2004 20:55:21 -
@@ -42,6 +42,7 @@
set_file_variables (struct file *file)
{
char *at, *percent, *star, *less;
+ struct dep *d;
#ifndef NO_ARCHIVES
/* If the target is an archive member `lib(member)',
@@ -105,8 +106,17 @@
}
star = file-stem;
- /* $ is the first dependency. */
- less = file-deps != 0 ? dep_name (file-deps) : ;
+ /* $ is the first not order-only dependency. */
+ less = ;
+
+ for (d = file-deps; d != 0; d = d-next)
+if (!d-ignore_mtime)
+ {
+less = dep_name (d);
+break;
+ }
+
+
if (file-cmds == default_file-cmds)
/* This file got its commands from .DEFAULT.
@@ -134,7 +144,6 @@
char *caret_value;
char *qp;
char *bp;
-struct dep *d;
unsigned int len;
/* Compute first the value for $+, which is supposed to contain
___
Bug-make mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-make
___
Bug-make mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-make
Re: [PATCH] pattern-specific variable expansion
Hmmm, I ran into something similar in which:
a := A
bar:
@echo $a
a := B
would output B.
Does this patch fix this as well?
Thanks,
Noel
Boris Kolpackov wrote:
Good day,
The following makefile prints 'B' instead of 'A'.
a := A
%bar : arg := $a
%bar : ; @echo $(arg)
a := B
foobar:
Patch is attached for those who find this behavior surprising.
Also note that this patch does not address the following cases:
%bar : a := a
%bar : $a_b := a_b # doesn't work, equivalent to _b := a_b
%bar : a := a
%bar : a_b := $a_b # doesn't work, equivalent to a_b := _b
comments are welcome,
-boris
Index: read.c
===
RCS file: /cvsroot/make/make/read.c,v
retrieving revision 1.131
diff -u -r1.131 read.c
--- read.c 22 Mar 2004 15:11:49 - 1.131
+++ read.c 9 Apr 2004 18:47:48 -
@@ -1686,9 +1686,19 @@
p = create_pattern_var (name, percent);
p-variable.fileinfo = *flocp;
v = parse_variable_definition (p-variable, defn);
- v-value = xstrdup (v-value);
+
if (!v)
error (flocp, _(Malformed pattern-specific variable definition));
+
+ if (v-flavor == f_simple)
+{
+ v-value = allocated_variable_expand (v-value);
+}
+ else
+{
+ v-value = xstrdup (v-value);
+}
+
fname = p-target;
}
else
___
Bug-make mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-make
___
Bug-make mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-make
Re: [PATCH] pattern-specific variable expansion
Paul D. Smith wrote: %% Noel Yap [EMAIL PROTECTED] writes: ny Hmmm, I ran into something similar in which: ny a := A ny bar: ny@echo $a ny a := B ny would output B. Of course. As expected. Command scripts are not expanded until they are about to be invoked by make, which is well after all the makefiles are read in. By that time the value of the variable a IS B. Yes, of course. This makes sense. Thanks, Noel ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: [PATCH] order-only prerequisite ends up in $
Paul D. Smith wrote: %% Boris Kolpackov [EMAIL PROTECTED] writes: bk If you expect it to print bk %r: | baz bk then look in read.c line 537. The dumping code simply does not bk distinguish between normal and order-only prerequisites. ITYM rule.c. I have a fix for this already but maybe I haven't checked it in yet. Is this just a display bug? Or does this affect actual processing? Thanks, Noel ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: creation of a directory
Paul D. Smith wrote: GNU make strips trailing slashes, so that foo/ and foo are considered the same prerequisite. Is there any reason, other than backwards compatibility, to keep this particular feature? I find it a bit annoying although the workaround is feasible. Thanks, Noel -- NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited. ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: creation of a directory
Boris Kolpackov wrote: Hi Noel, Since there is a workaround, simplifying GNU make in this respect isn't worth it. Speaking of workaround, having the following implicit rule %/. : @mkdir $* you cannot just write foo : bar/ instead you will have to write foo : bar/. which is quite ugly and unnatural. It is one story to write something ugly in implicit rule (once) and the other to ask users of your implicit rule to write something ugly (many times). I agree. It's even uglier when you're dealing with macros: $(FOO): $(dir $(FOO)). Noel -- NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited. ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: creation of a directory
Noel Yap wrote: It's even uglier when you're dealing with macros: $(FOO): $(dir $(FOO)). Correction, this should be: $(FOO): | $(dir $(FOO)). Noel -- NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited. ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: 3.81 ... any dates for release
Will this release include the distributed make feature? If not, when do you think this will be incorporated? Thanks, Noel Paul D. Smith wrote: %% Dr. Jörn von Holten [EMAIL PROTECTED] writes: jvh I'm currently using 3.81rc1 (taken from CVS) and I'm quite jvh satisfied. Astonishing that there are still major distributors jvh that deliver 3.79.1 as default version. Can you give an idea, jvh when 3.81 can be expected? A customer of mine is hesitating a jvh bit to use a non-public version of make (3.81rc1) - as I jvh suggested. Now that Savannah has been (mostly) reconstituted I'm starting to work on a 3.81 release in earnest. Assuming there are no more outages on Savannah I would hope that something official would be out in the next 4-6 weeks or so. But, nothing is certain... -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: Enhancement request regarding make variable names
Dale R. Worley wrote: [This enhancement request is for Gnu make 3.79.1.] It would be a useful thing if Make variable names were forbidden to contain slash (`/'), as well as `:', `#', and `='. The reason I make this request is that I was rebuilding a Linux kernel in a directory named (more or less) `/auto/LABEL=Backup/linux-2.4.20-24.8.test4'. The Linux kernel makefile expands out the full path of the files it is working with, rather than using relative names, so at one point, it generated a Makefile rule looking something like this: I currently use a macro __FILE__ that contains the filename of an included makefile (including the path). I then use this to create namespace-scoped variables (eg $(__FILE__).foo := bar). If votes mattered, I would vote Nay on this request. Are you able to quote these special characters such that they would be interpreted the way you'd like? Noel -- NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited. ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: Lucent nmake feature support
Paul D. Smith wrote: accurate: for example GNU make has had support for distributed builds for a long time (at least on UNIX platforms), but it requires linking in a 3rd party library (free, but not provided with GNU make). I didn't know about this. Can you provide a URL? Thanks, Noel ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: multiple wildcards in a static pattern rule
I'm not sure about your syntax. I think you might mean: $(ROOT)etc/dir1/%: % cp $ $@ chmod 644 $@ and so on. Anyway the way I'd go about this would be: $(foreach d,etc/dir1 etc/dir2 etc/dirN,$(eval $(ROOT)$(d)/%: % ; cp $ $@ chmod 644 $@)) I haven't tested it, but it should at least be close to what I think you want. HTH, Noel Ram Bhamidipaty wrote: I have a series of rules like this in my Makefile: $(ROOT)etc/dir1/%: $(ROOT)etc/dir1/%: % cp $ $@ chmod 644 $@ $(ROOT)etc/dir2/%: $(ROOT)etc/dir2/%: % cp $ $@ chmod 644 $@ ... $(ROOT)etc/dirN/%: $(ROOT)etc/dirN/%: % cp $ $@ chmod 644 $@ Is there a way to write all of these static pattern rules with one rule? When I did a google search on this I saw that there was a patch submitted for that back in 1997, but there is no documentation in the make manuals that suggests that this feature has been incorporated into gnu make. Thanks for any info? -Ram ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make -- NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited. ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: MAKECMDGOALS
According to the NEWS file that comes with the source, MAKECMDGOALS was added in 3.76. HTH, Noel Andy Xiao wrote: I am executing gmake (verion 3.74) with a target: gmake xxx, I am expecting the MAKECMDGOALS containing xxx. At 05:20 PM 10/30/2003 -0500, Noel Yap wrote: Are you executing gmake with a target (eg gmake all) or relying on the first rule hit behaviour (eg gmake)? If the former, what does gmake -npqr all 21 | grep MAKECMDGOALS give? If the latter, I think MAKECMDGOALS is supposed to be empty. HTH, Noel Andy Xiao wrote: Is MAKECMDGOALS working? How come it always turns out to be empty. - ___ Help-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/help-make -- NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited. -- NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited. ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: MAKECMDGOALS
Are you executing gmake with a target (eg gmake all) or relying on the first rule hit behaviour (eg gmake)? If the former, what does gmake -npqr all 21 | grep MAKECMDGOALS give? If the latter, I think MAKECMDGOALS is supposed to be empty. HTH, Noel Andy Xiao wrote: Is MAKECMDGOALS working? How come it always turns out to be empty. - ___ Help-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/help-make -- NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited. ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: Missing feature gnumake?
I'm too lazy to do all this work in order to help you ;-) Can you provide a minimal makefile and description directly in your email, please? Thanks, Noel Jean Kusters wrote: Hello, Could you untar, unzip the attachment and read my README file which describes a problem which I can not solve with my actual knowledge of gnumake. I would strongly appreciate any further advice or comment. Thanks, Jean Kusters ([EMAIL PROTECTED]) Name: makereport.tar.gz makereport.tar.gzType: Unix Tape Archive (application/x-tar) Encoding: base64 ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make -- NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited. ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: [FEATURE Request] Please add an option to list all dependenciesofa target (recursively)
[EMAIL PROTECTED] wrote: On Wed, 27 Aug 2003 07:37:46 -0400, Noel Yap [EMAIL PROTECTED] said: I would like a way to list all dependencies and subdependencies of a given target to avoid the recursive shell function hackism I currently have to do when using make -pnq. IMHO, don't use recursive make: http://www.tip.net.au/~millerp/rmch/recu-make-cons-harm.html. I get a file not found error at thet URI, but the recursion is not the major point here. Indeed, the recursion here may not even refer to using make recursively -- the point here is to discover all the targets that would be looked at when I run make. So, if the target of interest is install, which depends on build, which depends on my-program-name, which depends on main.o, which depends on main.c, which depends on /usr/include/stdio.h; I want to have all these dependencies listeed -- and I am justusing a simple Makefile. Sorry for not checking the URL. If you're still interested in the paper, googling for recursive make harmful turns up many links. If I'm misunderstanding the problem, can you provide more details, please? All right. Suppose I want to create a wrapper around make that would call make automatically when one of the files that a make target depends on changes. How do I discover what those files are? I don't understand, make already does this. Why not just call make? Obviously, make knows, since when it is actually run it goes through, and tests files/targets to see if they need rebuilding. What is requested is a mode in which each target is assumed to be in need of rebuilding, but, instead of taking any action, all that is done is to print the target's name on stdout. I hope this is clearer. Yes, much clearer. Have you tried make -n? HTH, Noel ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: [FEATURE Request] Please add an option to list all dependenciesofa target (recursively)
Manoj Srivastava wrote: Hi, [Please retain the CC to [EMAIL PROTECTED] so that the Debian Bug Tracking system can record your input] This was a feature request from a Debian user. I would like a way to list all dependencies and subdependencies of a given target to avoid the recursive shell function hackism I currently have to do when using make -pnq. IMHO, don't use recursive make: http://www.tip.net.au/~millerp/rmch/recu-make-cons-harm.html. If I'm misunderstanding the problem, can you provide more details, please? Thanks, Noel manoj -- On the Internet, no one knows you're using Windows NT Submitted by Ramiro Estrugo, [EMAIL PROTECTED] Manoj Srivastava [EMAIL PROTECTED]http://www.golden-gryphon.com/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: [FEATURE Request] Please add an option to list all dependenciesofa target (recursively)
Manoj Srivastava wrote: What if I have a build machine, where several dozen projects of my software house are kept. I want a database of reverse dependencies, where every file that is changed gives a listing of targets and hence programs that would be affected. So, whenever someone wants to change a core file, the data base provides information of the products and executables that would be affected by the change. This sounds like a manifest. I can think of other situations where a listing of all possible prerequisite for a target could be useful. (Changing copyright for an included header file: how many projects does it impact? This shouldn't matter since it should be up to the maintainer of the project to change which version of the library it's using. If we found a security hole in a structure or function: how many projects would be impacted? All these are what if scenarios). In any case, is this really necessary? Should every feature requester have to rigorously defend the need for a well defined, distinct feature? No, and yes. This is open source. You're welcome to make the changes yourself without asking for approval or justifying it. OTOH, every added feature leads to more complex software. More complex software leads to security holes and other problems. This is not information that is readily available, and it should be relatively easy for make to disseminate this information. I agree. I'm not sure I agree that make should provide this information. In most cases, it won't be 100%. For example, what if the OS version changes? What if the compiler version changes? What I've done in the past is to have each project to supply a makefile that lists its dependencies on other projects. Each project would include the published dependency makefile of its dependencies. It's recursive. A rule would then be invoked that would spit out the dependencies. Currently, I'm sort of redoing this work since I'm at a new job. The dependency information will include project version information as well and check to ensure that several different versions of one project aren't being used within a project. For example, a depedency makefile might have something like: # dependencies of proj0 PKG += proj1/1.0 PKG += proj2/2.0 # dependencies of proj3 include proj0/0.0/dependencies.mk PKG += proj4/4.0 This example is extremely stripped down and doesn't include version checking, bootstrapping, and logic to decide whether to use a development copy or a production copy, but you should be able to get the idea. Each version of each project will also publish the list of files it contains and at what version. Yes, that is one process. But make -npr produces lots of verbiage, and it is not easy to parse the output -- though this is the hack one must resort to, for the moment, lacking this feature set in make. This is true unless you follow the above example. *Shrug*. I know how free software works. This is why this is labelled a feature request, not a feature demand. However, some authors of free software, myself included, do like to solicit feature requests from users. I understand that there is no obligation on your part to listen to user request for improved functionality of the program in question. Then it should also be understood that some will ask for rationale and justification behind the feature request. This report shall remain in the Debian Bug Tracking system, in the hopes that someone at a future date who has the time and motivation can implement this feature. If this is the final decision of the custodians of GNU Make, I would appreciate being told so, so that I can label the report properly (i.e, upstream, wontfix) in the Debian BTS. I can't speak for the maintainers of make (sorry if I inferred that I was). OTOH, I hope thinking of the problem differently will solve the real problem at hand, that is, tracking all dependencies of projects. Noel ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
gmake-3.80 bug?
I'm not sure if this has been reported by anyone, but the following makefile: define _append ifeq ($(filter $(1),$(AOEU)),) AOEU += $(1) endif endef append = $(eval $(call _append,$(1))) ifndef aoeu aoeu := 1 $(call append,aoeu) endif .PHONY: aoeu aoeu: @echo $(AOEU) produces: yapn:[EMAIL PROTECTED]:~/proj/aoeu gmake aoeu GNUmakefile:11: *** missing `endif'. Stop. but take out the ifndef: define _append ifeq ($(filter $(1),$(AOEU)),) AOEU += $(1) endif endef append = $(eval $(call _append,$(1))) aoeu := 1 $(call append,aoeu) .PHONY: aoeu aoeu: @echo $(AOEU) and it works fine: yapn:[EMAIL PROTECTED]:~/proj/aoeu gmake aoeu aoeu Any ideas? Thanks, Noel -- NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited. ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
