$(file) function bug or not?
I'm trying to understand if my use of the $(file..) function is correct or not. Based on tests/scripts/function/file, I cooked up this little file.mak: all: file_test cat file.out .PHONY: file_test file_test: rm file.out $(file file.out, Hello) $(file file.out, world) @echo 'abspath file.out: $(abspath file.out).' - Running 'make -f file.mak' gives: rm file.out abspath file.out: G:/MingW32/src/gnu/GNU-Make/file.out. cat file.out cat: file.out: No such file or directory file.mak:2: recipe for target 'all' failed gnumake: *** [all] Error 1 -- (I just used the $(abspath file.out) to verify the file.out gets created). But without the 'rm file.out', everything works fine: #rm file.out abspath file.out: G:/MingW32/src/gnu/GNU-Make/file.out. cat file.out Hello world Seems GNU-make (or something else) breaks causality here; the docs on the file function (sec. 8.6) has this passage: .. In all cases the file is created if it does not exist. What is going on here? It doesn't change anything if I do cat ./file.out'. So I don't think it's a shell issue. GNU Make 4.0.90 Built for Windows32 (MSVC) --gv ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: $(file) function bug or not?
Paul Smith psm...@gnu.org wrote: Then make invokes the shell with the results of the expansion, which are the rm and echo commands (and some empty strings which are ignored). So, the rm is running AFTER the file is created, and deleting it. Thanks. That makes sense when I think about it. --gv ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: $(file) function bug or not?
On Tue, Jan 28, 2014 at 7:31 AM, Gisle Vanem gva...@yahoo.no wrote: Paul Smith psm...@gnu.org wrote: Then make invokes the shell with the results of the expansion, which are the rm and echo commands (and some empty strings which are ignored). So, the rm is running AFTER the file is created, and deleting it. Thanks. That makes sense when I think about it. I think the headline here is that $(file) is analogous to $(shell) in that it's intended specifically for use _outside_ of recipes. If you find yourself using either one in a recipe it's probably a sign you're on the wrong track. David ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: $(file) function bug or not?
On Tue, 2014-01-28 at 09:52 -0800, David Boyce wrote: I think the headline here is that $(file) is analogous to $(shell) in that it's intended specifically for use _outside_ of recipes. If you find yourself using either one in a recipe it's probably a sign you're on the wrong track. I'm not sure I'd go that far. $(shell ...) really _is_ useless in a recipe because make will invoke a shell to run the recipe anyway, so why have it invoke two shells? It's just redundant. However, $(file ...) can be useful in a recipe especially on systems which have limited command line lengths (Windows for example)... in fact I'd say that this is one of the main reasons people wanted $(file ...). You can use it in a recipe to create an @-file, for example, for input to a program where just using $^ directly would be far too large for the command line. But there's no real point in deleting the file first with rm, since the operator will truncate it anyway. I guess there might be _some_ small reason to try to delete it with rm -rf if you suspect it might already exist as a directory. Now that I think about it, I just did come up with a valid reason to use $(shell ...) in a recipe! foo: $(shell rm -rf biz) $(file biz, hello there) :-p :-) ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: $(file) function bug or not?
On Tue, Jan 28, 2014 at 1:20 PM, Paul Smith psm...@gnu.org wrote: I'm not sure I'd go that far. $(shell ...) really _is_ useless in a recipe because make will invoke a shell to run the recipe anyway, so why have it invoke two shells? It's just redundant. However, $(file ...) can be useful in a recipe especially on systems which have limited command line lengths (Windows for example)... in fact I'd say that this is one of the main reasons people wanted $(file ...). I'll grant you your point about $(file ...); sorry for overstating. But (and here we go completely away from the original topic, sorry again) I think $(shell ...) in a recipe should be more firmly deprecated than you do here. It's not just redundant, it creates an order-of-evaluation error. See the third date in this example: % cat Makefile all: @echo The time is now $$(date) @echo The time is now $(shell date) sleep 4 @echo The time is now $(shell date) @echo The time is now $$(date) % make The time is now Tue Jan 28 13:31:08 EST 2014 The time is now Tue Jan 28 13:31:08 EST 2014 sleep 4 The time is now Tue Jan 28 13:31:08 EST 2014 The time is now Tue Jan 28 13:31:12 EST 2014 David ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: win32 compilation of make 4.0 source code
On Mon, Jan 27, 2014 at 11:05 PM, Mark Brown mkbrown_...@hotmail.com wrote: From: Paul Smith Sent: Monday, January 27, 2014 8:57 PM ... ifneq ($(filter else-if,$(.FEATURES)),else-if) $(error Version $(MAKE_VERSION) does not support else-if) endif Are you saying that this statement can be placed outside of a make target recipe command sequence, and would be executed before the target recipe command sequence ? The answer to your question can be found in the GNU make info pages. Or, you could just TRY IT AND GET THE ANSWER INSTANTLY. This is what the new make 4.0 manual says about -trace capability: = ‘--trace’ Show tracing information for make execution. Prints the entire recipe to be executed, even for recipes that are normally silent (due to .SILENT or ‘@’). Also prints the makefile name and line number where the recipe was defined, and information on why the target is being rebuilt. = Again, this is a re-paste of the desired output, which again you deleted in your reply: == $(CC) -c $(CFLAGS) $ -o $@ Make_filename Makefile_Line_Num auto_var_eval auto_var_eval /adir/bdir/cdir/Makefile554.mk 1177 make_debug.c make_debug.o === In GNU make 4.0 the --trace option was introduced. From the NEWS file: * New command line option: --trace enables tracing of targets. When enabled ... Does this trace capability display the full evaluated automatic variables ? Why not include a sample paste of its output. You've been unwilling to given any specific examples of your problems, makefile snippets, or output, and yet you question when other don't provide them? Since you obviously don't have the current version of make installed, why would anyone bother? Philip Guenther Your role is maintenance of the make project. It is not your role to solve other people's engineering problems. When a bug or omission is presented to you, you have at least 3 appropriate response options: 1) we do not think that is an issue that needs to be solved by make, 2) that issue needs to be solved in make, and it is, but in a different way from what may be apparent from the documentation or intuitive, Read the following link URL, chapter, section etc. 3) we do think that issue should solved by make, but it has yet to be implemented. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: win32 compilation of make 4.0 source code
On Tue, 28 Jan 2014, Mark Brown wrote: On Mon, Jan 27, 2014 at 11:05 PM, Mark Brown mkbrown_...@hotmail.com wrote: From: Paul Smith Sent: Monday, January 27, 2014 8:57 PM ... ifneq ($(filter else-if,$(.FEATURES)),else-if) $(error Version $(MAKE_VERSION) does not support else-if) endif Are you saying that this statement can be placed outside of a make target recipe command sequence, and would be executed before the target recipe command sequence ? The answer to your question can be found in the GNU make info pages. Or, you could just TRY IT AND GET THE ANSWER INSTANTLY. This is what the new make 4.0 manual says about -trace capability: So, you're _not_ going to just try the ifneq()...endif example that Paul provided? Gotcha. = ?--trace? Show tracing information for make execution. Prints the entire recipe to be executed, even for recipes that are normally silent (due to .SILENT or ?@?). Also prints the makefile name and line number where the recipe was defined, and information on why the target is being rebuilt. = Again, this is a re-paste of the desired output, which again you deleted in your reply: No, it doesn't provide output in that format. Your suggested output format can't be unambiguously parsed when the variables contain whitespace, which would make the output much less useful. ... Your role is maintenance of the make project. I'm sorry, but you appear to suffer misconceptions about the project and myself. I have *NO* official role in the project. I'm just someone that uses it and answers some questions on the list. It is not your role to solve other people's engineering problems. Huh. What gave you the role of deciding what other peoples' roles are? When a bug or omission is presented to you, you have at least 3 appropriate response options: 1) we do not think that is an issue that needs to be solved by make, 2) that issue needs to be solved in make, and it is, but in a different way from what may be apparent from the documentation or intuitive, Read the following link URL, chapter, section etc. 3) we do think that issue should solved by make, but it has yet to be implemented. HAHAHHAHAHAHHHAHAHAHAHA Do you have a contract with me or, for that matter, with the GNU make project which would let you specify that? Heck, do you get to specify that when you complain to Microsoft about bugs in their tools? (There are plenty of courteous people that ask questions on this list. I shouldn't stop giving my minimal help in answering their questions just because one person stomps in complaining that we must answer questions in the way he demands.) Philip ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
