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 implementation?
Re: GNU make 3.99.92 release candidate is available
Hi Paul, Paul D. Smith psm...@gnu.org writes: I'm not sure I fully understood the situation. This comment makes it sound like same version of make (same code) is 50% slower on the new system. Is that what you meant? Yes, the same make binary is 50% faster on 2-generations old Xeon compared to the current one. On the old system 3.99 is quite a bit faster than 3.82 (don't remember the actual numbers, i think it was about 30-40%). On the new box this difference is completely wiped-out; both versions take about the same amount of time. Obviously there's not much we can do ourselves, if it's not a differnce in the make code. You'll have to do some testing. Use perf, or compile with gprof support, or similar, and try to figure out where the slowdown is happening. I will try to find some time. If it's truly that the same make binary takes 50% longer on one system than the other, especially on do-nothing builds, I would suggest checking out the filesystem and disk differences. I don't think disks matter (and the new box has SSDs) since everything is presumably cached by the kernel. The filesystems are different (ext3 vs ext4), though, again, assuming the directory entries are cached, there shouldn't be any differences. The only really variable thing in a do-nothing make build is the amount of time it takes to stat all the files. Well, make also has to do a lot of memory-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 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
Hi Paul, Paul D. Smith psm...@gnu.org writes: There's still a serious regression in the code due to the change in pattern rule searching added in 3.82. In some (not that unusual) circumstance GNU make will chew _enormous_ amounts of memory, compared to what it used to use in 3.81 and below. This is because in the current algorithm, every single time we do an implicit rule search and compute possible target and dependency names they are all added to the string cache, even if they are deemed to be useless and not needed because that implicit rule is not chosen. In cases where there are lots of futile implicit rule searches the string cache gets bloated with these useless strings. Seeing that you haven't fixed it for 4.0, I assume there is no obvious or easy solution ;-). I care a lot less about memory than about speed and I believe it is the same for most other users these days. So maybe we should try to tune the hash (i.e., the number of buckets) so that lookup doesn't suffer too much? Also I've not seen Debian experimental pick up release candidates like this in the past; is that something they do? I wrote to the maintainer. Let's see what he says. Personally I think getting into something like Gentoo may be more beneficial since their package management tool is running make quite a bit. Yes, though I would imagine they would be a lot more reluctant to do this since in 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 ___ 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
Hi Paul, I've built the RC and used it in a couple of common scenarios on our build system. So far I haven't seen any regressions. I've also tested the up-to-date check time compared to 3.81 and the new version is significantly faster (5.63s vs 8.15s). That's very welcome. I would like to use the RC in more every day development, however, I am currently travelling and don't do much of that. So it would be great if you could give a couple of months for everyone to have a chance to test the new release thoroughly. It will also allow the distributions to pick it up (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://codesynthesis.com/products/odb ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[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, BTW, is easy to fix in a backwards-compatible way). To be fair, the glibc build system is pretty complex, perhaps the most complex of any widely-used package. If I remember correctly, the previous release of GNU make also broke its build (or was it GCC). On the other hand, we need to be able to evolve GNU make so that it supports more complex build systems. This particular feature is meant to allow assembling pattern rules from multiple makefiles that don't necessarily know anything about each other. Prior to this release such assembly was pretty much impossible. I won't be surprised if at some point in the future glibc developers will make use of this feature. ___ Reply to this item at: http://savannah.gnu.org/bugs/?31002 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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 that a more specialized rule should be preferred over a more general one. For example: %.o: %.c; $(CC) -o $@ $ %-pic.o: %.c; $(CC) -fPIC -o $@ $ Here we want make to select the second rule when building foo-pic.o and the first rule when building foo.o. Similar thing happens in your case: make looks for a rule to build rtld-memset.so and chooses a rule specific to building the 'rtld' kind of targets rather than any kind. The way to resolve this would be to add two more rules before the existing 'rtld-%' ones: rtld-%.os: rtld-%.S @echo $@: rtld-%os: rtld-%.S: $ rtld-%.os: rtld-%.c @echo $@: rtld-%os: rtld-%.c: $ With this change I get rtld-memset.os: rtld-%os: rtld-%.c: rtld-memset.c with 3.82 and the old behavior with 3.81. ___ Reply to this item at: http://savannah.gnu.org/bugs/?31002 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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 regex-based patterns (which, BTW, are requested regularly by users). What you are proposing is a convenient syntax to define a set of old-style pattern rules. The more general pattern rules will be able to handle your case but not vice-versa. ___ Reply to this item at: http://savannah.gnu.org/bugs/?30370 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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 ___ Follow-up Comment #1: This has already been fixed for the upcoming 3.82 release. ___ Reply to this item at: http://savannah.gnu.org/bugs/?28748 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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:None = CVS ___ Follow-up Comment #2: Fix is in CVS. ___ Reply to this item at: http://savannah.gnu.org/bugs/?25780 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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 ___ Reply to this item at: http://savannah.gnu.org/bugs/?15110 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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: http://savannah.gnu.org/bugs/?15110 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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:None = CVS ___ Follow-up Comment #1: Fix is in CVS. ___ Reply to this item at: http://savannah.gnu.org/bugs/?12686 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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:None = CVS ___ Follow-up Comment #7: Fix is in CVS. ___ Reply to this item at: http://savannah.gnu.org/bugs/?17740 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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 Microsoft nmake, then you probably know that nmake and GNU make have very different and incompatible makefile syntax. Making GNU make automatically trying to process nmake makefiles doesn't sound like a good idea since it will fail for most non-trivial ones. ___ Reply to this item at: http://savannah.gnu.org/bugs/?27545 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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=${TEST}
___
Reply to this item at:
http://savannah.gnu.org/bugs/?27047
___
Message sent via/by Savannah
http://savannah.gnu.org/
___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make
[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 prerequisite of some target, it ought to exist? What if this target is not used in this compilation episode? A makefile can contain different sets of rules that are used to build different things at the request of the user. Why mentioning the file as a prerequisite in one set of rules should affect the other set? I agree that the correct way would be to actually try to build the file (or make sure that it can be built) be it via an implicit rule, DEFAULT, etc. Not sure how easy it will be to implement something like this, though. In other words, before deciding on an implicit rule, we need to make sure all the prerequisites that came from this rule either exist or can actually be built. Should I open a separate bug report for this? ___ Reply to this item at: http://savannah.gnu.org/bugs/?17752 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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 : proj1.c ___ Reply to this item at: http://savannah.gnu.org/bugs/?24622 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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. # .SUFFIXES: ifeq ($(filter -r,$(MAKEFLAGS)),) MAKEFLAGS += -r endif There was a thread on one of the GNU make mailing lists about this interesting behavior some time ago. As for adding -R, I think it is quite obvious why it does not work: make sets built-in variables before it starts reading makefiles. Boris ___ Reply to this item at: http://savannah.gnu.org/bugs/?20501 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
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 -include handling. Boris ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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: http://savannah.gnu.org/bugs/?18963 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: [3.81] Possible parallelizing bug in combination with multiple-target pattern rules
Hi Christoph, Christoph Schulz [EMAIL PROTECTED] writes: I think I've found a bug in GNU make. When a pattern rule with multiple targets exists, and make determines that it needs that rule to built one matching target, it uses this rule even if the other targets implicitly built by this rule don't have their dependencies built yet. Hm, it seems make needs to also consider dependencies from the also_make chain when evaluating a rule. I don't see it being done right now. Can you please file a bug report at http://savannah.gnu.org/bugs/?func=additemgroup=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 http://lists.gnu.org/mailman/listinfo/bug-make
[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: http://savannah.gnu.org/bugs/?18139 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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. Automatically assuming that if something worked in 3.80 and doesn't work in 3.81 then it must be a bug in 3.81 is not quite correct--ideally it should be pointed in the GNU make manual or POSIX standard why certain behavior is expected. ___ Reply to this item at: http://savannah.gnu.org/bugs/?18139 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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: http://savannah.gnu.org/bugs/?17740 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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 effectively becomes a target since you can now 'make' it. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=16958 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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 this in your makefile .PHONY: all then there is no problem building all. Both 3.80 and 3.81 print make: Nothing to be done for `all'. I am not saying that we shouldn't fix this regression. I am saying that I believe the code I added is correct and the problem is elsewhere (most likely in the code that decides whether to use commands from .DEFAULT or not). ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=16958 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
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 realpath in SUS and I don't see anything that implies this. My understanding that all components of the path must exist. It's not immediately clear to me what all but the last component of pathname means; presumably it means that the directory containing the last filename in pathname must exist, but that the filename itself does not have to exist. Yes, that seems to be the meaning. But on platforms where there's no realpath, we currently use abspath that doesn't care whether that directory exists. Since Joe Random Hacker might not know whether her Make was built with or without realpath (and the docs don't even tell that realpath falls back on abspath), we should try to emulate realpath as close as we can, I think. I also thought about writing an emulation for realpath by using readlink. Unless I'm missing something, that shouldn't be too hard. Here is the documentation for realpath and abspath from GNU make manual: `$(realpath NAMES...)' For each file name in NAMES return the canonical absolute name. A canonical name does not contain any `.' or `..' components, nor any repeated path separators (`/') or symlinks. In case of a failure the empty string is returned. Consult the `realpath(3)' documentation for a list of possible failure causes. `$(abspath NAMES...)' For each file name in NAMES return an absolute name that does not contain any `.' or `..' components, nor any repeated path separators (`/'). Note that, in contrast to `realpath' function, `abspath' does not resolve symlinks and does not require the file names to refer to an existing file or directory. Use the `wildcard' function to test for existence. I guess for platforms without realpath, we can emulate it as func_wildcard (func_abspath (...)) rather than just func_abspath (...). hth, -boris ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
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 still fails? -boris ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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 ___ Follow-up Comment #3: The fix is in CVS. I tested it on some build systems that don't use second expansion. Time for CVS was about 25% higher compared to 3.80 (with -r both showed the same time). With the fix the times are the same for both versions, with and without -r. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=16140 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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 dependencies require it. I think we should call set_file_variables only after we see the first dependency that requires second expansion. Paul, is it ok with you if I fix this for 3.81? ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=16140 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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 not handle .SECONDARY: without prereqs. This was fixed for 3.81. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=16145 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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 ___ Follow-up Comment #4: Fix is in CVS. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=16053 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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 end of the week. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=16053 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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 should do it for 3.81. There will be quite a bit of changes. ___ Additional Item Attachment: File name: makefile Size:0 KB http://savannah.gnu.org/bugs/download.php?item_id=16053item_file_id=3502 ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=16053 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=16051 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=15919 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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: http://savannah.gnu.org/bugs/?func=detailitemitem_id=15919 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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: test.3 .PRECIOUS: test.3 If I comment .INTERMEDIATE out, the behavior goes away. ___ Additional Item Attachment: File name: makefile Size:0 KB http://savannah.gnu.org/bugs/download.php?item_id=15919item_file_id=3449 ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=15919 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
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 bk rule, make does not hang. What would the equivalent normal rule be? Perhaps I can use that as a workaround in my original makefile. That would be test.3: | test.2 ... I think a better workaround would be to remove test.2 from .SECONDARY. -boris signature.asc Description: Digital signature ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
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 hang. 2. If I change %.3 : | %.2 to %.3 : %.2, make does not hang. 3. If I replace the %.3 : | %.2 rule with the equivalent normal rule, make does not hang. 4. Adding .SECONDEXPANSION: does not change anything. I did some inspecting in the implicit rules area and it seems that everything is working properly there, i.e., in the instantiation of the %.3 : | %.2 rule, test.2 has the intermediate, secondary and ignore_mtime flags set, as expected. -boris ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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 around line 692: hash_map (files, set_intermediate); ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=15584 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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: http://savannah.gnu.org/bugs/?func=detailitemitem_id=15584 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
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 the make repository. The fix will appear in subsequent betas and the release. hth, -boris ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
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 prerequisites of a given target; I don't think it's odd to assume that it does not imply anything about any other relationship between those same files, as targets or prerequisites. Look at it this way: envision the DAG. I would say that .WAIT is a block on one of the edges between two nodes in the DAG. If that same node can be accessed through other edges, then that's fine: the .WAIT block doesn't apply to those. Make sense? Or still no? Yes it does. It's not clear to me whether it's good or bad, though. I don't see how result depends on how we got here type of logic is of any usefulness especially in the context of make (read build reproducibility). That's why I also think that inheritance of pattern/target-specific variables, the way it is implemented now, is of limited use. In this particular case, consider the following makefile: all: foo fox foo: bar .WAIT baz fox: baz Isn't it according to your logic that execution of command scripts for both 'bar' and 'baz' can start simultaneously? One is via all-foo-bar chain and the other is via all-fox-baz. thanks, -boris signature.asc Description: Digital signature ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
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 my implementation only supports POSIX (aka UNIX) paths. I've written a patch to handle drive letters. If anybody has a better solution, please let me know. I am of a strong opinion that such patches should be kept outside of the main tree. However I know that Paul disagrees with this position. So I guess it would be his call. hth, -boris ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
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)) to get -Wl,-y,a_ -Wl,-y,b_ -Wl,-y,c_ -Wl,-y,d_ -Wl,-y,e_ Somehow I need to comment the comma so that it is not interpreted as a MAKE function argument separator. Use an indirection: comma :=, FOO := $(patsubst %,-Wl$(comma)-y$(comma)%_,$(FOO)) -boris ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
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 $^ $@ clean: rm -f a b Here is a typical command sequence when run in a loop you provided: cat x b# timestamp(b) = 1 cat b a# timestamp(a) = 2 echo x x # timestamp(x) = 2 cat x b# timestamp(b) = 2 Here is what happens: the first line updates file `b' with timestamp = 1. On line 2 timestamp(a) becomes 2 (assuming timestamp(a) 1 before line 2). Now the third line updates `x' which also happened to have its timestamp = 2. Now `x' is older than `b' so `b' is updated on line 4 with timestamp = 2. In other words three last lines executed fast enough to end up with the same timestamp. Now even though `b' changed, its timestamp is no older than `a'. So GNU make decides there is no need to remake `a'. The code in GNU make that decides whether to print Prerequisite `c' is newer than target `a' assumes that the two consecutive modifications to two different files will result in two different timestamps. However it is not always the case: sometimes they end up having equal timestamps. So I would say there is a bug in that logic. To find out all this I had to instrument make a bit. Below is the output that illustrates the situation I described above: GNU Make 3.81beta3 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 i686-pc-linux-gnu Reading makefiles... Reading makefile `makefile'... Updating makefiles Considering target file `makefile'. : tgt makefile mtime: 1194845150682021891 Looking for an implicit rule for `makefile'. No implicit rule found for `makefile'. : tgt makefile; must_make: 0 Finished prerequisites of target file `makefile'. No need to remake target `makefile'. Updating goal targets Considering target file `a'. : tgt a mtime: 1194847602034606083 Considering target file `b'. : tgt b mtime: 1194847600960864259 Considering target file `x'. : tgt x mtime: 1194847602034606083 Looking for an implicit rule for `x'. No implicit rule found for `x'. : tgt x; must_make: 0 Finished prerequisites of target file `x'. No need to remake target `x'. : check_dep x; this-mtime: 1194847600960864259; new-mtime: 1194847602034606083 : dep x; maybe_make: 1 : dep x changed: 0; old-mtime: 1194847602034606083; new-mtime: 1194847602034606083 : tgt b; must_make: 1 Finished prerequisites of target file `b'. Prerequisite `x' is newer than target `b'. Must remake target `b'. cat x b Putting child 0x08071518 (b) PID 335 on the chain. Live child 0x08071518 (b) PID 335 Reaping winning child 0x08071518 PID 335 Removing child 0x08071518 PID 335 from chain. Successfully remade target file `b'. : check_dep b; this-mtime: 1194847602034606083; new-mtime: 1194847602034606083 : dep b; maybe_make: 0 : dep b changed: 1; old-mtime: 1194847600960864259; new-mtime: 1194847602034606083 : tgt a; must_make: 0 Finished prerequisites of target file `a'. Prerequisite `b' is newer than target `a'. No need to remake target `a'. -boris ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
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 wants say a space be interpreted as space they just escape it, e.g.: my\ file\ full\ of\ spaces: dollar\$ign ... Make preprocessor will translate those into special chars when makefile is read and translate them back when such strings are passed outside. There is a huge amount of work to get this to happen, though, and the interface for the encoding needs to be thought out. Also it would be nice to think about how this feature is going to play with guile (i.e., could there will be an overlap). -boris ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
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 README.cvs? ___ Bug-make mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-make
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 linker to be re-invoked once each, despite the fact that the this is an order-only dependency. I tested your example with GNU make 3.80 and it works as expected. Are you by any chance trying it on NFS? ___ Bug-make mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-make
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/file.c 2004-09-17 13:38:46.0 -0500
@@ -455,8 +455,9 @@
for (d = f-deps; d != 0; d = d-next)
for (f2 = d-file; f2 != 0; f2 = f2-prev)
{
- /* Mark this file as phony and nonexistent. */
+ /* Mark this file as phony nonexistent target. */
f2-phony = 1;
+ f2-is_target = 1;
f2-last_mtime = NONEXISTENT_MTIME;
f2-mtime_before_update = NONEXISTENT_MTIME;
}
diff -u -b -B --minimal make-cvs-orig/implicit.c make-cvs-patched/implicit.c
--- make-cvs-orig/implicit.c2004-01-07 21:17:08.0 -0600
+++ make-cvs-patched/implicit.c 2004-09-17 13:41:17.0 -0500
@@ -342,6 +342,8 @@
deps_found = 0;
for (dep = rule-deps; dep != 0; dep = dep-next)
{
+ struct file *f = 0;
+
/* If the dependency name has a %, substitute the stem. */
p = strchr (dep_name (dep), '%');
if (p != 0)
@@ -396,7 +398,7 @@
directory (the one gotten by prepending FILENAME's directory),
so it might actually exist. */
- if (lookup_file (p) != 0
+ if (((f = lookup_file (p)) != 0 f-is_target)
|| ((!dep-changed || check_lastslash) file_exists_p (p)))
{
found_files_im[deps_found] = dep-ignore_mtime;
.PHONY: all
all: case.1 case.2 case.3
a: void
# 1 - existing file
#
%.1: void
@false
%.1: makefile
@true
# 2 - phony
#
%.2: void
@false
%.2: 2.phony
@true
.PHONY: 2.phony
# 3 - implicit-phony
#
%.3: void
@false
%.3: 3.implicit-phony
@true
3.implicit-phony:
signature.asc
Description: Digital signature
___
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 $ make foo.erg make: *** No rule to make target `foo.erg'. Stop. $ make foo.erw make: *** No rule to make target `../baz', needed by `foo.erw'. Stop. $ make foo.res make: *** No rule to make target `../baz', needed by `foo.res'. Stop. The first error message is incorrect and should look like the other two: make: *** No rule to make target `../bar', needed by `foo.erg'. Stop. Actually the second error message is incorrect and should look like the first ;-). In fact it is a side effect of a bug which is more serious than just incorrect diagnostic. Consider the following makefile test.foo: %.foo : baz echo done %.foo : bar echo done fox: baz Also assume that there is a file `baz' in current directory. When you run make on this makefile (3.80 or current cvs) you get make: *** No rule to make target `baz', needed by `test.foo'. Stop. This is wrong since the second pattern rule, if tried, would succeed. The bug is in implicit.c line 399. I have a patch which will appear in make-bk6 patch-set. I can also submit a patch against make-cvs if there is any interest. -boris ___ Bug-make mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-make
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 situations it is manifested in. Also you cannot for sure say how many such situations there are since not everybody is using make the way you do. For what it's worth I am suffering from this bug too. the performance penalty that would be incurred to re-invoke make after each makefile was recreated could be quite large. What would be nice is to have another flavor of include that would be rebuilt sequentially without re-executing make. I.e., every time make encounters such include directive it tries to rebuild the makefile and then reads it in. This way has a number of benefits: - bug mentioned by the original poster goes away - more deterministic: if some of the code after (missing) included makefile depends on some code from it (for example a function) then things will break. - more efficient since there is no make re-execution (hurts really badly in non-recursive makefiles where cost of re-parsing dependency graph can be quite significant). What do you think? -boris ___ Bug-make mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-make
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 intended for out-of-date makefile to trigger failure when it could be rebuilt and succeed. It is like if a C compiler would still report errors that you've just fixed refusing to compile your code. The design is perhaps not the one you would choose or would prefer, but that does not make it a bug. This way we can call any bug in concept a design feature. bk What would be nice is to have another flavor of include that would bk be rebuilt sequentially without re-executing make. I.e., every bk time make encounters such include directive it tries to rebuild bk the makefile and then reads it in. This is also quite confusing. At no time during the current make processing does it jump out from the middle of the parser phase and into the rule execution phase. I never said it would be easy ;-). Not only that but the behavior would be quite surprising to people who are familiar with make, since no rules or variables that were defined after the include directive could be used during the rebuild of the included makefile. I think it is no more surprising that to find make code failing because included makefile that can be built is missing. Also I am not proposing changing current schema - I think it can be quite useful sometimes. I am suggesting addition of another include directive flavor that would be well documented along with all implications (like the ones you just mentioned). But I guess it will stay just a proposal like many others before it... -boris signature.asc Description: Digital signature ___ Bug-make mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-make
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 makefile in its target names. That's how make works. Rules are expended as they are read. Is there a better approach? Your example doesn't give any idea what you are trying to achieve so it's hard to say. Maybe if you describe actual problem we may be able to help. -boris ___ Bug-make mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-make
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? Wouldn't it be better to rather solve the general problem? I've been toying with one of the possible solutions and have some results if you are interested... -boris ___ Bug-make mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-make
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 the following /tmp/makefile: OUT=/tmp/out .PHONY: all all: $(OUT)/bin/foo $(OUT)/obj/%.o: %.c mkdir -p $(@D) gcc -o $@ -c $ $(OUT)/bin/%: $(OUT)/obj/%.o mkdir -p $(@D) gcc -o $@ $ (A side note: when you are submitting your example and it has to use absolute paths, make sure they all start from /tmp for a lot of people (including myself) will be lazy to go and create /usr/local/maketest just to try your example.) foo.c is in /tmp, make is run from /tmp. This makefile exhibits two different behaviors depending on whether /tmp/out exists or not. If /tmp/out exists (/tmp/out/bin and /tmp/out/obj do not exist) then everything works file. When /tmp/out does not exist make fails. I have to idea about the logic behind this. If you don't mind using non-main-line make you can get my -bk patchset where this bug (IMO, anyway) is fixed: http://kolpackov.net/projects/make/bk/ Also there is a generally better way to handle directory creation which is described here (works in main-line make): http://kolpackov.net/pipermail/notes/2004-January/01.html hth, -boris ___ Bug-make mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-make
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 := FOO
/a/b%: bar := BAR
$(warning $(/a/b:foo)) # prints FOO
$(warning $(/a/b/c:bar)) # prints BAR
This would be somewhat equivalent to
namespace a
{
foo := FOO
namespace b
{
bar := BAR
}
}
Remember that these queries will be evaluated at makefile
read-in time, not runtime, so much of the information is potentially not
even available yet.
Not only that, but make can't even _know_ what the full set of
target-specific variables are for a given target until that target is
actually ready to be invoked... the scope of target-specific variables
could depend on the target-prerequisite path make used to get to this
target and decide to build it.
Right. That brings us to this question: what is target-specific variable
inheritance useful for? Any non-academic examples? I, for instance, am
using it to propagate -fPIC flag to object compilation:
%.o: %.c
gcc $(pic_flag) -o $@ -c $
%.so: pic_flag := -fPIC
libfoo.so: foo.o bar.o
There are two big problems with this approach:
* If I say `make foo.o' the object will be compiled without -fPIC and
if later I say just `make' the shared library will be broken.
* It doesn't scale to the case when I want to build both shared
library and archive:
libfoo.a: foo.o bar.o
all: libfoo.so libfoo.a
IMO, the target-specific variable inheritance feature is in conflict
with make's assumption that the way object file is built does not
depend on which target-prerequisite path triggered it; when make needs
the same prerequisite for some other target it will just reuse it without
re-building it or checking whether it was built with the same resulting
set of target-specific variable values.
What do you think?
-boris
signature.asc
Description: Digital signature
___
Bug-make mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/bug-make
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) # query target-specific variable /foo/bar: vpath %.so /usr/lib64 # target-specific vpath ifdef /foo/bar: foo # target-specific variable in ifdef ebdif What to you think ? ;-) -boris signature.asc Description: Digital signature ___ Bug-make mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-make
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 sections are expanded immediately, and the commands used to construct the target are always deferred. Given the above information from info make I agree with Boris on this. Both 'a' and 'arg' should be considered IMMEDIATE according to the snippet included. I am glad you agree with me ;-). To be precise, however, I must say that the snippet you cited does not apply here since it is talking about rule definition while I was talking about target specific variable definition. I don't think there is a part in the manual that specifies at what point target-specific variables get expanded so it is in some sense an implementation-defined behavior which, I must say, gets very tricky when it comes to target-specific variable inheritance, +=, etc. I think immediate evaluation is less surprising, though. -boris signature.asc Description: Digital signature ___ Bug-make mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-make
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/listinfo/bug-make
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 @@
break;
}
+ /* If this file is a prerequisite of the .NOT_DEFAULT
+ target, don't let it be the default goal file. */
+
+ if (!reject)
+{
+ struct file *f = lookup_file (.NOT_DEFAULT);
+
+ for (; !reject f != 0; f = f-prev)
+for (d = f-deps; d != 0; d = d-next)
+ if (streq (name, dep_name (d)))
+{
+ reject = 1;
+ break;
+}
+}
+
if (!reject)
default_goal_file = f;
}
signature.asc
Description: Digital signature
___
Bug-make mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-make
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 ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
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 Description: Digital signature ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
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-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. -boris signature.asc Description: Digital signature ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
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.asc Description: Digital signature ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
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 $ /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 signature.asc Description: Digital signature ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
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 the frame will not affect anything outside the frame. See http://kolpackov.net/projects/build/ if you are interested in details. -boris signature.asc Description: Digital signature ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
[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 default target hijacking by auxiliary targets. For example I have the following pattern: 1. User `makefile' includes `bootstrap.make' to bootstrap build system. 2. `bootstrap.make' includes configuration makefiles that are generated automatically. Rules for those configuration files hijack default target. # file: bootstrap.make out_root := initialize-output-root $(out_root)/configuration: configure $@ include $(out_root)/configuration # file: makefile include bootstrap.make $(out_root)/driver: driver.c A workaround for this problem would be to split `bootstrap.make': # file: makefile include bootstrap-part1.make # secure default target $(out_root)/driver: include bootstrap-part2.make $(out_root)/driver: driver.c However, this is not always possible and even when possible results in bloated user makefiles. This problem can be solved by specifying that particular target cannot be default: # file: bootstrap.make out_root := initialize-output-root .NOT_DEFAULT: $(out_root)/configuration $(out_root)/configuration: configure $@ include $(out_root)/configuration comments? -boris signature.asc Description: Digital signature ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
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 consider that target to be the default. So, in your example you could change your makefile to: # file: makefile all: include boostrap.make all: $(out_root)/driver $(out_root)/driver: driver.c There are two issues with this approach - Now make prints nothing to be done for all instead of driver is up to date which is bad (well, if you care). - User makefiles are bloated with those unnecessary all's. 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). 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. To summarize: the default target is defined by a user makefile and there is already a mechanism for doing that. Included makefiles need to say that targets are not default and this mechanism is lacking. I agree that it could be considered more logical to have explicit declaration for default targets: .DEFAULT: $(out_dir)/driver I think it is roughly equivalent to .NOT_DEFAULT: except it would lead to a bit more verbose user makefiles (.NOT_DEFAULT: would be used in a *few* system files while .DEFAULT: will be used in *each* user makefile). And it wouldn't be backward compatible, of course ;-). thanks, -boris signature.asc Description: Digital signature ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
[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 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;
#ifndefNO_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
signature.asc
Description: Digital signature
___
Bug-make mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-make
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 work bar:; @echo $(a_) In contrast the patch fixes the following case: a := A %bar : a_ := $a %bar :; @echo $(a_) a := B foobar: Which prints (without patch) B. hth, -boris signature.asc Description: Digital signature ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
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? With my (patched) make it prints %r: baz If you expect it to print %r: | baz then look in read.c line 537. The dumping code simply does not distinguish between normal and order-only prerequisites. hth, -boris signature.asc Description: Digital signature ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
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 already discussed this before on the list. Changing this behavior leads to undesirable behavior in other situations. I think it was related to += in a target-specific variable not having the expected semantics. I think there's even a bug about this in Savannah already. 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. To prove it I even ran makefile fragment from your comment and it prints the right thing. IIRC, there is no one behavior in this situation that works as expected in every case. Well, for that bug report - perhaps. My case is a bit different. It all boils down to the point where pattern-specific variable expansion happens. For example b := B %bar : a := $b #1 b := A foobar: #2 Without the patch real assignment happens at point 2 (it's really funny to put $(warning) in rhs of pattern-specific variable assignment; learn a lot of new things about make ;-)). While this could have it's own reasons (I don't know of any, do you ?) this makes it impossible to associate any value at pattern definition. Proposed patch changes this behavior (for simple variables only) to expand at point 1. While this change is not backward compatible it allows both behaviors: b := B %bar : a := $b $$b b := A foobar: Now $a will be A B. I'm assuming all the regression tests still pass with your patch applied? I can't remember whether I added a test for this situation or not. Yes, all tests pass. thanks, -boris signature.asc Description: Digital signature ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
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; in command scripts the backslash/newline is not resolved during command read-in like it is for make constructs. Internally the script is stored with the backslash/newlines intact, just as it was read in. Well, this makes sense and I think it should be left this way. One reason for this is so that when make prints the rule it's about to create the rule looks the way it looks in the makefile, rather than a big glob of code on a single line. If make removed the backslash newline from the define at make read-in time, then the output printed by make for that would lose all of its formatting. Ok. Also, I think it would change the meaning in some cases, because the backslash/newline expansion would be done _TWICE_, once when the define was parsed and then again when the command script was parsed. I agree that it is probably a very obscure define that would be impacted by this... about the only way I can think that it might have an impact is if someone had two backslashes at the end of a line: define weird echo foo\\ echo bar endef I think that's exactly how it should be. Single backslash-newline should be stripped, double-backslash-newline should be change to single backslash-newline (escaping). This will allow one to write commands in define like this define @echo one\\ @echo two endef While defines like this one will behave without any surprises: define $(call foo,\ bar) endef On the other subject, comments: I really think that this _would_ cause problems, and I don't think they're academic. Consider this define: define subst echo $ | sed 's/#foo#/$(FOO)/' $@ endef I think such cases should be handled through escaping, e.g. define subst echo $ | sed 's/\#foo\#/$(FOO)/' $@ endef To summarize, it seems to me that the way make handles defines now can lead to some subtle bugs that are really hard to find. On the other hand I don't think there is a way to fix this without shedding some backward-compatibility blood. -boris signature.asc Description: Digital signature ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
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 assigns bk the value verbatim Correct. It's not clear to me how you expect this to behave. By the time make starts to expand variables it has already resolved all the backslash/newline pairs: it has to do this first or nothing works properly. This is true except that make doesn't do it inside define. Are you saying that it should perform _ANOTHER_ round of backslash/newline resolution at some point during the parsing or expansion of variables? No, I think it should handle newline-backslash sequence the same way everywhere, including inside define. How will this impact backward compatibility? I think it won't. I doubt anybody actually employes this behavior of make wrt newline-backslash processing. I think the same applies to comments inside define. All this seems pretty obvious to me unless I miss something big (and in this case I bet you would gladly point it out ;-)). thanks, -boris signature.asc Description: Digital signature ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
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 example of fixing what is not broken. Isn't it make's job to compare timestamps? nothing personal, -boris ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
[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'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
signature.asc
Description: Digital signature
___
Bug-make mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-make
Re: -include
Good day, Just want to follow up with another bug from the same area. Consider the following makefile: -include bar hello: @echo hello bar : foo cp foo bar Make fails even though the manual says that it will not: If you want `make' to simply ignore a makefile which does not exist and cannot be remade, with no error message, use the `-include' directive instead of `include'... -boris signature.asc Description: Digital signature ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
-include
Good day, I found a somewhat surprising behavior of -include. Consider the following makefile: bar: foo := baz -include bar hello: @echo hello I would expect it to print 'hello'. Instead make complains that it cannot build 'bar'. Here is what happens. The first line of this makefile results in the file 'bar' being inserted into the table of files. A flag 'dontcare' is not set. Later, when make reads a second line, 'bar' is already in the table so the 'dontcare' flag is left unset. When make tries to rebuild 'bar', 'dontcare' is 0 and make complains that it cannot build 'bar'. I also don't think that simply over-setting 'dontcare' is the right thing to do. Consider, for example, the following file (which shows another surprising feature, btw): -include bar bar: foo := baz hello: @echo hello foo : bar When I say 'make foo' nothing happens even though there is no rule to build 'bar'. So it seems to me that 'dontcare' flag is not an attribute of a file but rather of a situation when the file is being built (i.e., when make tries to remake 'bar' for -include it should have 'dontcare' set to 1, but when it tries to build it as a prerequisite for 'foo' it should have 'dontcare' set to 0. thanks, -boris signature.asc Description: Digital signature ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: creation of a directory
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). -boris signature.asc Description: Digital signature ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
[bugs #7310] comments are not ignored in $(call) /$(eval)
URL: http://savannah.gnu.org/bugs/?func=detailitemitem_id=7310 Project: make Submitted by: Boris Kolpackov On: Sun 01/18/04 at 05:36 Severity: 5 - Average Item Group: Bug Resolution: None Assigned to: None Status: Open Component Version: CVS Platform Version: Any Fixed Release: None Summary: comments are not ignored in $(call) /$(eval) Original Submission: $ cat comment define foo #$(warning $(1)) endef define bar $(eval $(call foo,baz)) endef $(call bar) $ make -f comment comment:8: baz make: *** No targets. Stop. For detailed info, follow this link: http://savannah.gnu.org/bugs/?func=detailitemitem_id=7310 ___ Message sent via/by Savannah http://savannah.gnu.org/ - End forwarded message - signature.asc Description: Digital signature ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
