Re: [bug #61594] suggest new $(hash ...) function

rsbec...@nexbridge.com writes: > Sadly, the import restrictions do not distinguish between message > digests and cryptography [...] You seem to be quite knowledgeable on the matter so can you provide one concrete example of where one jurisdiction restricts export to another of, say, an SHA-1 imp

Re: GNU make 3.99.92 release candidate is available

y-intensive processing (entering files into caches, creating all the dependency structures, pattern matching, etc). It could be some bad CPU cache interaction. That was my first thought since everything on this machine is faster, CPU, disks, memory. Boris -- Boris Kolpackov, Code Synthesish

Re: GNU make 3.99.92 release candidate is available

Boris -- Boris Kolpackov, Code Synthesishttp://codesynthesis.com/~boris/blog Compiler-based ORM system for C++ http://codesynthesis.com/products/odb ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make

Re: GNU make release candidate 3.99.90 available

their case make runs on the user machine, not on the build server (where any regressions will be quickly detected and reported). Boris -- Boris Kolpackov, Code Synthesishttp://codesynthesis.com/~boris/blog Compiler-based ORM system for C++ http://codesynthesis.com/products/odb _

Re: GNU make release candidate 3.99.90 available

ole thing if publicly available (see signature), it unfortunately won't build on Windows. Boris -- Boris Kolpackov, Code Synthesishttp://codesynthesis.com/~boris/blog Compiler-based ORM system for C++ http://codesynthesis.com/products/odb __

Re: GNU make release candidate 3.99.90 available

e.g., Debian experimental). This will give you essentially free testing with a wide range of packages. Thanks, Boris -- Boris Kolpackov, Code Synthesishttp://codesynthesis.com/~boris/blog Compiler-based ORM system for C++ http://codes

[bug #31002] make picks wrong pattern rule

Follow-up Comment #6, bug #31002 (project make): Roland, I think you overstate the seriousness of the problem. There are not many makefiles that both define multiple pattern rules and rely on their order for selection. 3.82 has been out for a few months now and glibc is the first such case (which

[bug #31002] make picks wrong pattern rule

Follow-up Comment #4, bug #31002 (project make): In this case GNU make 3.82 does exactly what it claims it will do. Unfortunately the expected (from glibc's perspective) behavior falls into that 0.01% of cases where the more qualified rule is not what needs to be selected. The assumption here is

[bug #30370] add a shorthand syntax for foreach-eval-call

Follow-up Comment #5, bug #30370 (project make): I agree with Paul. The discussion on stackoverflow is talking about a more general mechanism, namely having pattern rules with multiple stems. I think if we were to consider such an extension, then it is better to go all the way and add support for

[bug #28748] "matches" array is improperly sized in implicit.c:pattern_search()

Update of bug #28748 (project make): Status:None => Fixed Open/Closed:Open => Closed Fixed Release:None => CVS

[bug #25780] .SECONDEXPANSION: of $$+ harmed by set_file_variables() side effect

Update of bug #25780 (project make): Status:None => Fixed Assigned to:None => bosk Open/Closed:Open => Closed Fixed Release:

[bug #17740] make fails without any message

Update of bug #17740 (project make): Status:None => Fixed Assigned to:None => bosk Open/Closed:Open => Closed Fixed Release:

[bug #12686] make quietly dies instead of issuing an error

Update of bug #12686 (project make): Status:None => Fixed Open/Closed:Open => Closed Component Version: CVS => 3.81 Fixed Release:

[bug #15110] Confusing failure message for generate dependencies with 3.81beta3

Update of bug #15110 (project make): Status:None => Fixed ___ Reply to this item at: ___ Messa

[bug #15110] Confusing failure message for generate dependencies with 3.81beta3

Follow-up Comment #7, bug #15110 (project make): Fix is in CVS. ___ Reply to this item at: ___ Message sent via/by Savannah http://savannah.gnu.org/

[bug #15110] Confusing failure message for generate dependencies with 3.81beta3

Update of bug #15110 (project make): Open/Closed:Open => Closed Component Version:None => 3.81 Fixed Release:None => CVS ___

[bug #27545] Patch to add Makefile.mak to default file names searched

Update of bug #27545 (project make): Severity: 3 - Normal => 1 - Wish Item Group:None => Enhancement ___ Follow-up Comment #1: If you refer to Micro

[bug #17752] target fails depending on order of prereqs

Follow-up Comment #6, bug #17752 (project make): I tend to agree, my change caused quite a few regressions according to the GNU make documentation. However, I also don't think the original 3.80 behavior is correct. That "ought to exist" is a misnomer. Who said that just because a file is made a p

[bug #27047] Difficulties defining prerequisites for pattern targets.

Follow-up Comment #3, bug #27047 (project make): You can get the desired behavior using the second expansion feature (note $$): .SECONDEXPANSION: all:test1001.out foo: @echo making foo test1%.out: TEST=foo test%.out: $${TEST} @echo making test$*.out with TEST=${T

[bug #25140] Pattern-specific variable assignment behaves differently compared to normal variables

URL: Summary: Pattern-specific variable assignment behaves differently compared to normal variables Project: make Submitted by: bosk Submitted on: Sun 21 Dec 2008 10:20:54 AM GMT Seve

[bug #24622] $$(eval) creating new targets causes segmentation fault

Follow-up Comment #2, bug #24622 (project make): IMO, adding new targets during the second expansion is conceptually wrong. Granted make shouldn't segfault, in this case we should just report an error, the same kind that make emits when seeing something like this: proj1.exe : proj1.o proj1.o : p

[bug #20501] "MAKEFLAGS += -rR" doesn't turn off default suffix rules, variables

Follow-up Comment #6, bug #20501 (project make): Actually adding -r to MAKEFLAGS does work. It just that -p still prints the rules as if they were there. I use the following makefile fragment in our build system to get rid of all built-in (suffix and pattern) rules: # Remove all built-in rules.

Re: Auto deps problem with newest make

Hi Tadeusz, Tadeusz J Liszka <[EMAIL PROTECTED]> writes: > but when makefile contains > -include $(dep_files) > > makefile 3.81 simply exits I am pretty sure this is bug #15110: https://savannah.gnu.org/bugs/?15110 Previous make versions reported this error because they had a number of bugs in

[bug #18963] -include suppressing errors for too long?

Follow-up Comment #5, bug #18963 (project make): The last comment is about bug# 15110. Not sure if it is related to the original report. ___ Reply to this item at: _

Re: [3.81] Possible parallelizing bug in combination with multiple-target pattern rules

m&group=make and include all the details and the test case. Thanks! -boris -- Boris Kolpackov Code Synthesis Tools CC http://www.codesynthesis.com Open-Source, Cross-Platform C++ XML Data Binding ___ Bug-make mailing list Bug-make@gnu.org

[bug #18139] make chooses wrong pattern rule

Follow-up Comment #9, bug #18139 (project make): I just checked and this code is in 3.80. I could not find any motivation of doing things this way in the comments. ___ Reply to this item at: __

[bug #18139] make chooses wrong pattern rule

Follow-up Comment #6, bug #18139 (project make): When GNU make is trying to match a target to an implicit rule it does it in two passes (implicit.c:432): first without intermediate prerequisites and then with them. If %.o results in an interemdiate then, on the first pass, the first rule will be

[bug #18139] make chooses wrong pattern rule

Follow-up Comment #4, bug #18139 (project make): I haven't checked the archive but from the rules above it seem that this is the valid behavior if %.o in the first rule would trigger build of an intermediate target. Also note that there were tons of bugs fixed in 3.81 compared to 3.80. Automatic

[bug #17740] make fails without any message

Follow-up Comment #5, bug #17740 (project make): I am pretty sure this is related to (or even the same as) bug #15110. ___ Reply to this item at: ___ M

[bug #16958] Marking .PHONY dependencies as targets is a regression against 3.80

Follow-up Comment #4, bug #16958 (project make): AFAICR, the change fixed some problems in pattern rules. As Paul suggested, you can revert the change and run the regression tests; I am sure some of them will fail. Also note that the change is conceptually correct - a file declared .PHONY effecti

[bug #16958] Marking .PHONY dependencies as targets is a regression against 3.80

Follow-up Comment #1, bug #16958 (project make): Prerequisites of the .PHONY special target are marked as targets because they are effectively targets. For example, if you have an empty Makefile and say $ make all you get: make: *** No rule to make target `all'. Stop. If, however, you have t

Re: Bug in builtin function abspath (again)

Eli Zaretskii <[EMAIL PROTECTED]> writes: > > > The realpath function will resolve both absolute and relative paths > > > and return the absolute pathname corresponding to pathname. All but > > > the last component of pathname must exist when realpath is called. I just checked the page for realpa

[bug #16531] Substitution reference and secondary expansion

Follow-up Comment #1, bug #16531 (project make): GNU make gets confused by the % in your patsubst call. You will need to add an indirection: .PHONY: foo.bar .SECONDEXPANSION: p := % foo: $$(patsubst $p,$p.bar,$$@); @echo $^ ___ Reply to

Re: make 3.81 test failure

Paul, [EMAIL PROTECTED] (Paul Jarc) writes: > + work/variables/INCLUDE_DIRS.mk:3: .INCLUDE_DIRS is empty This is probably because you built make with install prefix (--prefix) being a non-existent directory. Can you reconfigure make with something like --prefix /usr/local and see if this test st

[bug #16140] make 3.81rc2: performance decrease when searching builtin implicit rules compared to 3.80

Update of bug #16140 (project make): Status:None => Fixed Open/Closed:Open => Closed Fixed Release:None => CVS

[bug #16145] .SECONDARY: prevents non-existent dependency from forcing rebuild

Follow-up Comment #1, bug #16145 (project make): I believe this is intended behavior as described in GNU make manual. See bug #15584 (starting from comment #6) for more information. In your case *all* targets are SECONDARY. The reason it worked differently in 3.80 is because this version does no

[bug #16140] make 3.81rc2: performance decrease when searching builtin implicit rules compared to 3.80

Update of bug #16140 (project make): Assigned to:None => bosk ___ Follow-up Comment #1: I took a quick look and it appears that we call set_file_variables even if none of the dependencie

[bug #16053] second stem overwrites the first per-prerequisite stem

Update of bug #16053 (project make): Status:None => Fixed Open/Closed:Open => Closed Fixed Release:None => CVS

[bug #16053] second stem overwrites the first per-prerequisite stem

Update of bug #16053 (project make): Assigned to:None => bosk ___ Follow-up Comment #3: I would rather fix it properly right away than to come back to it. Will try to fix it before the e

[bug #16053] second stem overwrites the first per-prerequisite stem

Follow-up Comment #1, bug #16053 (project make): Attaching a minimized test case. It prints "all.foo.one all.foo.two" while should print "all.one all.foo.two". I also checked the code and it seems that keeping stem in prerequisites is the best way to solve this. I am not sure, however, if we sho

[bug #16051] Non-existent prerequisites are not included in $?

Follow-up Comment #1, bug #16051 (project make): Wouldn't it be better to (temporarily) add a special target that triggers the correct behavior? It seems kind of backward to deprive people of a bug fix just because some influential project has a buggy build system. _

[bug #15919] Make-3.81 rc1 hangs with -j 2 but not with -j 1

Follow-up Comment #4, bug #15919 (project make): I tried to minimize the makefile but couldn't get any rules out without removing buggy behavior. I could get .SECONDARY out of the way, however. The first line in the makefile: .SECONDARY: test.1 test.2 test.3 Can be replaced with .INTERMEDIATE:

[bug #15919] Make-3.81 rc1 hangs with -j 2 but not with -j 1

Follow-up Comment #3, bug #15919 (project make): After some more testing, it appears that removing test.3 from .SECONDARY prevents make from hanging, not test.2. ___ Reply to this item at:

[bug #15919] Make-3.81 rc1 hangs with -j 2 but not with -j 1

Follow-up Comment #1, bug #15919 (project make): > This one looks like it's going to be a big PITA to fix. Do you have any thoughts on why it hangs when we use the implicit rule and does not when we use a normal one. After instantiation of the implicit rule, the two cases should be equivalent.

Re: Make-3.81 rc1 hangs with -j 2 (multiplatform)

David, J. David Bryan <[EMAIL PROTECTED]> writes: > On 27 Feb 2006 at 13:09, Paul D. Smith wrote: > > > %% Boris Kolpackov <[EMAIL PROTECTED]> writes: > > > > bk> 3. If I replace the "%.3 : | %.2" rule with the equivalent normal >

Re: Make-3.81 rc1 hangs with -j 2 (multiplatform)

"J. David Bryan" <[EMAIL PROTECTED]> writes: > I originally reported a make-3.81rc1 hang against the Windows port here: > > http://lists.gnu.org/archive/html/make-w32/2006-02/msg00058.html I did some digging and here is what I uncovered: 1. If I remove test.2 from .SECONDARY, make does not ha

[bug #15584] 3.81 does way too much work in some pathalogical situations.

Update of bug #15584 (project make): Assigned to:bosk => None ___ Reply to this item at: ___

[bug #15584] 3.81.b4 much slower than 3.80 in some situations

Follow-up Comment #12, bug #15584 (project make): It appears that 3.80 has a bug in handling of .SECONDARY. It does not actually mark individual targets as intermedite. As a result, check_dep doesn't treat any target in this makefile as intermediate. In CVS the following code was added in file.c

[bug #15584] 3.81.b4 much slower than 3.80 in some situations

Follow-up Comment #10, bug #15584 (project make): So I did some mode digging and it appears that make just does what it's supposed to do. If you look into this makefile carefully you will see the pattern rule that looks like this %.hi: %.o which pretty much makes every single .o file depend (dire

Re: 3.81beta3 build error on HP-UX 10.20

Peter, Peter Fales <[EMAIL PROTECTED]> writes: > So far, so good. However, signame.c contains: > > #if !defined(HAVE_DECL_SYS_SIGLIST) > > Since HAVE_DECL_SYS_SIGLIST is defined (but with value 0), the code > is skipped even though it's needed on this platform. This already have been fixed in

Re: [bug #13976] Regression in :: deps handling between V3.76 and V3.80

Paul, Paul D. Smith <[EMAIL PROTECTED]> writes: > I disagree, actually. It's a settled feature of make that the DAG is > not a simple tree: that there can be more than one pathway to a given > target in the DAG. > > The placement of the .WAIT prerequisite implies a relationship between > two pre

Re: [bug #13976] Regression in :: deps handling between V3.76 and V3.80

Paul, Sorry, it took me a while to reply. My comments are below. Paul D. Smith <[EMAIL PROTECTED]> writes: > The rules I mentioned in this list apply only between the two > prerequisites listed, in that pathway. If the "waited for" prerequisite > appears on any other path where it is not waited

Re: [bug #13976] Regression in :: deps handling between V3.76 and V3.80

"Paul D. Smith" <[EMAIL PROTECTED]> writes: > rm> I'll admit that the processing of :: targets is a gray area, and > rm> the .WAIT approach is the clearest solution. > > Well, clear_ER_ anyway. There was a discussion on the idea of .WAIT some time ago on the help-make mailing list (Subject: "

Re: Bug in builtin function abspath

Andreas, Andreas Buening <[EMAIL PROTECTED]> writes: > The builtin function abspath does not consider drive letters. > Therefore, I think it will break not only on OS/2 but also on DOS > or Win* systems. And I suspect it won't work on VMS, too. I think you are correct. I implemented abspath and

Re: How to add comma to a list?

Ted Stern <[EMAIL PROTECTED]> writes: > Hi all, Your post belongs to help-make, not bug-make. > > What is the proper way to insert commas into each word of a GNU Make > variable? > > I want to change FOO something like this: > > FOO := a b c d e > FOO := $(patsubst %,-Wl,-y,%_,$(FOO))

Re: functions/realpath test failure on AIX

Albert Chin <[EMAIL PROTECTED]> writes: > On AIX 4.3.3, 5.1, and 5.2, $(realpath .///) appends "/": > $ cat /tmp/a > .PHONY: all > all: > @echo $(CURDIR) > @echo $(realpath .///) > $ ./make -f /tmp/a > /opt/build/make-3.81beta3/tests > /opt/build/make-3.81beta3/tests/ Does

Re: make handling of prerequisites that interlock?

Boris Kolpackov <[EMAIL PROTECTED]> writes: > cat x >b# timestamp(b) = 1 > cat b >a# timestamp(a) = 2 > echo x >x # timestamp(x) = 2 > cat x >b# timestamp(b) = 2 > > > The code in GNU make that decides whether to print "Prerequisite `c&#

Re: make handling of prerequisites that interlock?

Ben Pfaff <[EMAIL PROTECTED]> writes: > Prerequisite `c' is newer than target `a'. < 1 > Prerequisite `b' is newer than target `a'. < 2 > No need to remake target `a'. < 3 I simplified your makefile a bit: a: b cat $^ >$@ b: x cat $^

Re: whitespaces in filenames [was: bug in $(wildcard) on Windows?]

"Paul D. Smith" <[EMAIL PROTECTED]> writes: > * A new method for encoding strings would need to be found. Maybe > something like $[...] where "..." would be encoded. This part is > tricky and needs to be considered carefully. Is this really necessary? Can't we just say that if someone

Re: eval function within 'ifeq... else... endif' causes error

François Duranleau <[EMAIL PROTECTED]> writes: > And then, running make with the above produces: > > % make > Makefile:20: *** missing `endif'. Stop. This works as expected with make from cvs. -boris ___ Bug-make mailing list Bug-make@gnu.org http:

Re: Can't build from cvs sources

Robert Mecklenburg <[EMAIL PROTECTED]> writes: > "Well, bust my buttons!" After creating an empty build.sh.in > autoreconf succeeded in building a configure script. Even running the > ./configure script seemed to "work". But then, running make failed: Did you say `make update' as prescribed in

Re: Order-only dependencies don't work

"Daniel Olivier" <[EMAIL PROTECTED]> writes: > It builds fine the first time, but for some reason. If I attempt to make a > second time, because the obj_dir directory (dependency) is newer than the > (target) obj1.o, the rule is re-run, causing the "compiler" (touch in this > simplified case) and

Re: incorrect error message

Paul D. Smith <[EMAIL PROTECTED]> writes: > This sounds familiar to me: pls. send it. Thx. Patch and test makefile are attached. -boris diff -u -b -B --minimal make-cvs-orig/file.c make-cvs-patched/file.c --- make-cvs-orig/file.c2004-05-16 19:19:57.0 -0500 +++ make-cvs-patched/

Re: incorrect error message

Boris Kolpackov <[EMAIL PROTECTED]> writes: > Also assume that there is a file `baz' in current directory. That should be `bar', of course. ___ Bug-make mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-make

Re: incorrect error message

Bruno Haible <[EMAIL PROTECTED]> writes: > To reproduce: In an otherwise empty directory, create this Makefile: > > > %.erg : ../bar > echo done > > %.erw : ../baz > echo done > > foo.res : ../baz > echo done > =

Re: fatal errors for missing include files.

Paul D. Smith <[EMAIL PROTECTED]> writes: > If it is a bug then what you say is true, but I have never termed it a > bug. It was a design decision taken between two alternative > implementations, and the code is operating the way it was designed and > intended to work. I don't believe you ever

Re: fatal errors for missing include files.

"Paul D. Smith" <[EMAIL PROTECTED]> writes: > id> Ok, but I am surprised you don't you see any problem (bug) with > id> the current way? > > Not really. The times where it makes any difference are very few, I don't think the presence of the bug is in any way affected by the number of situat

Re: target variable expansion with included make files

"Brad Kemp" <[EMAIL PROTECTED]> writes: > What I am trying to do is to build a project out of many sub projects. > As each sub project is updated, I want the final target pathname to reflect > the new revision level without having to change the main makefile. > This allows me to build multiple ver

Re: target variable expansion with included make files

"Brad Kemp" <[EMAIL PROTECTED]> writes: > The main makefile includes two small makefiles. > Each make file defines variables used in the targets of the other makefile. > The target names are immediatly expanded which causes the first makefile > not to use the variables defined in the second makefi

Re: implicit rule invocation issue

"Hakenson, Gary C." <[EMAIL PROTECTED]> writes: > Do you have any suggestions as to how this may be accomplished? When you say VPATH = /d you are in some sense asking make to add directory /d to the make's current directory. When you say %.d : %.c ... you are in some sense asking

Re: better symlink handling

"Paul D. Smith" <[EMAIL PROTECTED]> writes: > There are a number of suggestions already available in the bugs and > patches sections of GNU make's Savannah project. Something will appear > in the next version of GNU make. Isn't it just an instance of a general problem of custom out-dateness? Wou

Re: Problem with absolute path

Paul D. Smith <[EMAIL PROTECTED]> writes: > Anyway, the idea was certainly performance: if a directory doesn't exist > and there are no rules in your makefile to create it (that is, there are > no targets that allow make to create that directory), then in make's > model it can never exist, so re

Re: Problem with absolute path

Juergen Schmidt <[EMAIL PROTECTED]> writes: > has anybody an idea on this or can help me? I am not sure this will actually help you but here it goes. GNU make makes some strange guesses (see make.c around line 99) when it comes to files in directories that do not exist. Consider for example th

Re: target-specific 'define'd variables (3.80)?

Paul D. Smith <[EMAIL PROTECTED]> writes: > It's not really clear to me when it's that useful to query, at a > _GLOBAL_ scope like this, what target-specific variables are set for a > given target. This will allow (theoretically) hierarchical namespaces, e.g., .PHONY: /a% /a/b% /a%: foo := F

Re: target-specific 'define'd variables (3.80)?

Paul D. Smith <[EMAIL PROTECTED]> writes: > I don't see any reason technically that it couldn't be done. That's what I thought too. Also it would be nice to extend the concept of target/pattern-specificity to other parts of make, e.g.: /foo/bar: foo := hello foo := $(/foo/bar: foo) #

Re: target-specific 'define'd variables (3.80)?

"Paul D. Smith" <[EMAIL PROTECTED]> writes: > %% Will Partain <[EMAIL PROTECTED]> writes: > > wp> Hi; I don't know if the little Makefile below *ought* to > wp> work or not; it seems it should. > > No. define/endef is not supported directly in kernel-specific > variables. The entire defini

Re: bugs fixed in -bk4

Sam Ravnborg <[EMAIL PROTECTED]> writes: > >From info make: > > > Rule Definition > --- > >A rule is always expanded the same way, regardless of the form: > > IMMEDIATE : IMMEDIATE ; DEFERRED > DEFERRED > >That is, the target and prerequisite se

bugs fixed in -bk4

Hi Paul, I have one patch in my -bk patch-set which, IMO, has no reason of not being in the main trunk. It implements dontcare flag inheritance which, combined with your recent changes to the dontcare machinery, fixes both bugs described here http://mail.gnu.org/archive/html/bug-make/2004-02/m

Re: Bug in make...

santhosh km <[EMAIL PROTECTED]> writes: > x: > ccsimpc -o HELLO_WORLD helloWorld.o ^^ ___ Bug-make mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/

Re: failing "make install" because missing lib

Julien Michielsen <[EMAIL PROTECTED]> writes: > Trying to compile and install gphoto, I can't succeed to run "make" > as it cannot find libslang.so.1 (which lives in /usr/lib) . I ran > configure with libdir=/usr/lib, but still make ends with > "cannot find -lslang". At one point I got "make" run

Re: [PATCH] .NOT_DEFAULT: target

Paul D. Smith <[EMAIL PROTECTED]> writes: > Mm. I don't know about this. BTW, the changes are just a few lines and in one place! ;-) -boris --- make-cvs-orig/read.c2004-05-16 19:19:57.0 -0500 +++ cvs-bk4/read.c 2004-05-19 14:59:18.0 -0500 @@ -2140,6 +2140,22 @@

Re: need access to Makefile path

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

Re: need access to Makefile path

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

Re: need access to Makefile path

Noel Yap <[EMAIL PROTECTED]> writes: > How are you going to guarantee that the names of the variables are unique? You could use variable framing ;-) > Do you still think that MAKEFILE_LIST is a scalable, viable solution? It is good enough to bootstrap and build on top. -boris signature.a

Re: need access to Makefile path

Noel Yap <[EMAIL PROTECTED]> writes: > Although it's reminiscent of DOS, I like your use of '%' in private > variable names. They are called "system variables". > One thing I can say right now is, if you had an include-makefile function, > the below would become: > > $(call include-ma

Re: need access to Makefile path

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) signature.asc Descr

Re: need access to Makefile path

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 ___

Re: [RFC] .NOT_DEFAULT: target

Paul D. Smith <[EMAIL PROTECTED]> writes: > The way I typically solve this is that I always define the target I want > to be the default first, with no prerequisites etc. Simply putting > something like: > > all: > > by itself at the top of the first makefile is enough to force make to > c

[RFC] .NOT_DEFAULT: target

Good day, I came to the point where I cannot work around "default target hijacking" problem. So I am planning to do something about it in my -bk patch-set. I also hope this feature will end up in the main stream thus this RFC. When makefile inclusion is used there is a recurring problem of defau

Re: Is this a bug in GNU make 3.80?

DervishD <[EMAIL PROTECTED]> writes: > Just one more point: is there any way to force the -R or -r flags > then? Not that it is essential, but... I am not sure about 3.80 but in 3.81beta1 I believe saying .SUFFIXES: MAKEFLAGS += -r is 'logically' equivalent to saying 'make -r'. If you want

Re: define strangeness

I see you are running make time-slice ;-) Paul D. Smith <[EMAIL PROTECTED]> writes: > bk> No, I think it should handle newline-backslash sequence the same > bk> way everywhere, including inside "define". > > Hm. But, make already doesn't handle backslash/newline the same way > everywhere;

Re: [PATCH] pattern-specific variable expansion

Paul D. Smith <[EMAIL PROTECTED]> writes: > bk> In contrast the patch fixes the following case: > > bk> a := A > > bk> %bar : a_ := $a > > bk> %bar :; @echo $(a_) > > bk> a := B > > bk> foobar: > > bk> Which prints (without patch) B. > > I want to point out that I think we

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

Noel Yap <[EMAIL PROTECTED]> writes: > 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. Well, it depends what is "proper thing"? Wi

Re: [PATCH] pattern-specific variable expansion

Noel Yap <[EMAIL PROTECTED]> writes: > Hmmm, I ran into something similar in which: > > a := A > > bar: > @echo $a > > a := B > > > would output B. This is correct behavior as per manual. If you want it to print A then write something like bar: a_ := $a # not sure a := $a will

[PATCH] order-only prerequisite ends up in $

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 ca

Re: define strangeness

Paul D. Smith <[EMAIL PROTECTED]> writes: > bk> Consider this makefile: > > bk> foobar := world > > bk> define name > bk> \ > bk> foobar > bk> endef > > bk> .PHONY: hello > bk> hello: ; @echo hello $(value $(name)) > > bk> It prints just "hello". I would guess it is because

define strangeness

Good day, Well, Paul will probably tell me that it is not a bug (as he did with comments in define) but I will report it anyway. Consider this makefile: foobar := world define name \ foobar endef .PHONY: hello hello: ; @echo hello $(value $(name)) It prints just "hello". I would guess it is b

Re: wish: multiple target patterns in a static pattern rule

Ted Stern <[EMAIL PROTECTED]> writes: > You can reduce potential compilation cascades even further by > ensuring that your *.gob processor compares previously existing > output files against the new output and retains the original > timestamp if no changes have been made. This is a good examp

[PATCH] pattern-specific variable expansion

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

double-colon logic for normal rules

Good day, In remake.c (cvs version) in function update_file there is a fragment of code which presumably is intended for double-colon rules only (line 324-332): /* Process the remaining rules in the double colon chain so they're marked considered. Start their prerequisites, too. */ fo

  1   2   >