[bug #63818] V=1 stopped working for Linux kernel module builds with make-4.4

URL: <https://savannah.gnu.org/bugs/?63818> Summary: V=1 stopped working for Linux kernel module builds with make-4.4 Group: make Submitter: mdorey Submitted: Sun 19 Feb 2023 11:59:36 AM PST Severity: 3 -

[bug #63417] .NOTINTERMEDIATE with no prerequisites is not working

Update of bug #63417 (project make): Status:None => Fixed Open/Closed:Open => Closed Fixed Release:None => SCM Triage Status:

[bug #63417] .NOTINTERMEDIATE with no prerequisites is not working

Follow-up Comment #2, bug #63417 (project make): Thanks, the patch worked for me. ___ Reply to this item at: ___ Message sent via Savannah

[bug #63417] .NOTINTERMEDIATE with no prerequisites is not working

Follow-up Comment #1, bug #63417 (project make): Thank you for your report. At makefile parse time make processes .NOTINTERMEDIATE and marks all files as notintermediate. The issue with this example, is that at that time make does not yet have a notion of x.b. x.b appears later at build time,

[bug #63417] .NOTINTERMEDIATE with no prerequisites is not working

URL: <https://savannah.gnu.org/bugs/?63417> Summary: .NOTINTERMEDIATE with no prerequisites is not working Project: make Submitter: masahiroy Submitted: Fri 25 Nov 2022 09:16:11 PM UTC Severity: 3 -

Re: Dependency tracking not working on macOS

On 2022-10-16 14:42, Christoph Grüninger wrote: Any idea what I am missing? I double-checked hat the used make has version 4.3.91. Yes, my idea is that either your bleeding-edge "make" is busted, or your environment variables are messed up. Either way it's not an Autoconf bug. What happens

Re: Dependency tracking not working on macOS

On 2022-10-09 15:43, Christoph Grüninger wrote: TMPDIR is also set, to an uncommon name (/var/folders/lr/5gw1xrv53h1b_9mjjvs2k1drgn/T/). Is that directory searchable, readable, writeable? Does its file system have enough free space? Any problems in that area could cause the symptoms

Re: Dependency tracking not working on macOS

On 2022-10-09 15:17, Paul Smith wrote: On Sun, 2022-10-09 at 16:39 -0400, Zack Weinberg wrote: can I suggest that this kind of problem would be easier to troubleshoot if make printed the name of the temporary file that it could not fopen? In the current Git version, it does do this: ...

[bug #62162] patsubst not working in prerequisites under .SECONDEXPANSION

Update of bug #62162 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Reply to this item at:

[bug #62162] patsubst not working in prerequisites under .SECONDEXPANSION

Follow-up Comment #5, bug #62162 (project make): Oh, I got it now, % expands as a stem of static pattern rule, and not being used by patsubst. The issue is resolved. Thanks, Mikhail ___ Reply to this item at:

[bug #62162] patsubst not working in prerequisites under .SECONDEXPANSION

Follow-up Comment #4, bug #62162 (project make): Thanks, _$$(percent)_ trick makes the job done. However what is happening is still obscure. For example, here _patsubst_ does everything correctly lib1_SRCS := main.c try.c test.c lib2_SRCS := lib.c api.c .SECONDEXPANSION: lib1 lib2:

[bug #62162] patsubst not working in prerequisites under .SECONDEXPANSION

Follow-up Comment #3, bug #62162 (project make): A typo, ofcourse should be $$(percent) percent:=% $(files) : %.ext : $$(patsubst r$$(percent),$$(percent),$$(lastword $$(subst .stem., ,$$*)))-prereq ___ Reply to this item at:

[bug #62162] patsubst not working in prerequisites under .SECONDEXPANSION

Follow-up Comment #2, bug #62162 (project make): You can store % in a variable percent:=% $(files) : %.ext : $$(patsubst r$(percent),$(percent),$$(lastword $$(subst .stem., ,$$*)))-prereq ___ Reply to this item at:

[bug #62162] patsubst not working in prerequisites under .SECONDEXPANSION

Follow-up Comment #1, bug #62162 (project make): The replacement of % by the stem happens before the secondary expansion is performed. ___ Reply to this item at:

[bug #62162] patsubst not working in prerequisites under .SECONDEXPANSION

URL: <https://savannah.gnu.org/bugs/?62162> Summary: patsubst not working in prerequisites under .SECONDEXPANSION Project: make Submitted by: None Submitted on: Thu 10 Mar 2022 10:06:34 AM UTC Severity: 3 -

Re: Paths above current/working directory don't work with suffix rules

Thanks for an answer. With your help I was able to come up with this piece: --PROG = ab LD = $(CC) SRCS = a.c b.c ../c-1up.c OBJS = $(SRCS:.c=.o) .c.o:        $(CC) $(CFLAGS) -c -o $@ $< .cpp.o:        $(CXX) $(CXXFLAGS) -c -o $@ $< all: $(PROG) $(PROG): $(OBJS) $(LD) -o $@ $(OBJS) $(LIBS) --Now,

Re: Paths above current/working directory don't work with suffix rules

On Mon, 2022-01-24 at 21:27 +0100, Adam Tuja wrote: > SRCS = a.c b.c ../c-1up.c > OBJS = $(SRCS:.c=.o) > > .c.o: > $(CC) $(CFLAGS) -c -o $@ $< > > $(PROG): $(OBJS) > > Now, when I understand it, it works. It's not the same thing as > objects are placed beside source files but step

Re: Paths above current/working directory don't work with suffix rules

On Mon, 2022-01-24 at 19:09 +0100, Adam Tuja wrote: > It doesn't matter how with many levels above current directory the > path has (../ ../../ ...), it's still the same. Suffix rules are very limited: this is why pattern rules were invented. As long as you're happy with creating the object file

Paths above current/working directory don't work with suffix rules

Hello,I had this problem trying to compile a source with relative paths above current/working directory level. I took me hours of frustration to make work and, it eventually didn't.Then, by a chance I realised that when I use a path within current working directory it more or less works.It doesn't

[bug #60919] Communicating -j to sub-make not working properly after make 4.1

Update of bug #60919 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #1: Your parent makefile

[bug #60919] Communicating -j to sub-make not working properly after make 4.1

Additional Item Attachment, bug #60919 (project make): File name: testcase.tar.gzSize:0 KB ___ Reply to this item at:

[bug #60919] Communicating -j to sub-make not working properly after make 4.1

URL: <https://savannah.gnu.org/bugs/?60919> Summary: Communicating -j to sub-make not working properly after make 4.1 Project: make Submitted by: bahaahamza Submitted on: Thu 15 Jul 2021 07:56:37 AM UTC Sever

[bug #57625] Shell builtins not working unless explicitly set SHELL to "sh"

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

[bug #57625] Shell builtins not working unless explicitly set SHELL to "sh"

URL: <https://savannah.gnu.org/bugs/?57625> Summary: Shell builtins not working unless explicitly set SHELL to "sh" Project: make Submitted by: None Submitted on: Sat 18 Jan 2020 12:48:39 PM UTC Seve

[bug #51309] Determination of a file list from a single folder without changing the working directory

Follow-up Comment #10, bug #51309 (project make): Would you like to compare run time characteristics a bit more with an approach similar to “$(shell find ~/Projekte/Bau/OCamlbuild -name '*.txt' -printf "%f ")”? ___ Reply to this item at:

Re: [bug #51309] Determination of a file list from a single folder without changing the working directory

> Are you able to provide any example proving how it matters under some more > or less rare circumstances? I guess not at the moment. > Or do you find the current software good enough I dared to point some change possibilities out recently. > and no changes needed? It depends on your views

Re: [bug #51309] Determination of a file list from a single folder without changing the working directory

On Sun, 2 Jul 2017 16:14:31 -0400 (EDT) Markus Elfring wrote: > It might matter more under other circumstances. Are you able to provide any example proving how it matters under some more or less rare circumstances? > (The current software can be fast enough to some

[bug #51309] Determination of a file list from a single folder without changing the working directory

Follow-up Comment #9, bug #51309 (project make): I suggested also a comparison of two algorithms . * A simple time measurement can also show test results for which you might not be looking for. * The usage of data structures like

[bug #51309] Determination of a file list from a single folder without changing the working directory

Follow-up Comment #8, bug #51309 (project make): If, for example, you can show an example of notdir adding significantly to the amount of time the make program takes. To test this I created a makefile like this: foo = ... all: ; : $(words $(foo)) where the "..." represents 6000 paths

[bug #51309] Determination of a file list from a single folder without changing the working directory

Follow-up Comment #7, bug #51309 (project make): > (a) you prefer to do it this way rather than the currently supported method of post-processing the wildcard results, … Yes. >(b) there's a significant performance benefit to avoiding the extra processing. I find that the difference can be

[bug #51309] Determination of a file list from a single folder without changing the working directory

Follow-up Comment #6, bug #51309 (project make): A theoretical argument is not what Paul meant by "actual results". Have you measured the time spent adding and removing the directory names in some realistic case? If not, then please do not advocate for making Make bigger..

[bug #51309] Determination of a file list from a single folder without changing the working directory

Follow-up Comment #5, bug #51309 (project make): I understand what you are suggesting. But I don't see any need to add new capabilities for this when the existing features of GNU make can already give these results. The only reasons for it that I can see would be (a) you prefer to do it this

[bug #51309] Determination of a file list from a single folder without changing the working directory

Follow-up Comment #4, bug #51309 (project make): I repeat my argument from 26. June: https://lists.gnu.org/archive/html/bug-make/2017-06/msg00198.html If the desired directory on which a file filter should be applied could be selected before, the file names would not contain references to this

[bug #51309] Determination of a file list from a single folder without changing the working directory

Follow-up Comment #3, bug #51309 (project make): There's no question that FOO := $(notdir $(wildcard Bau/*.txt)) is more efficient than: ~/Projekte> $(cd Bau && echo "echo $(ls *txt)") because the latter involves starting a whole new shell (two, technically) while the former is handled

[bug #51309] Determination of a file list from a single folder without changing the working directory

Follow-up Comment #2, bug #51309 (project make): I disagree with the run time characteristics of the mentioned functionality for my special use case. ~/Projekte> $(cd Bau && echo "echo $(ls *txt)") MOTD.txt Can a similar data processing operation be performed faster by advanced make

[bug #51309] Determination of a file list from a single folder without changing the working directory

Update of bug #51309 (project make): Status:None => Wont Fix Open/Closed:Open => Closed ___ Follow-up Comment #1: The current

Re: [bug #51309] Determination of a file list from a single folder without changing the working directory

> MY_FILES=$(notdir $(wildcard somedir/*.ext)) I agree that this algorithm can work. But it does not fit to my imaginations for efficient data processing. If the desired directory on which a file filter should be applied could be selected before, the file names would not contain references to

[bug #51309] Determination of a file list from a single folder without changing the working directory

URL: <http://savannah.gnu.org/bugs/?51309> Summary: Determination of a file list from a single folder without changing the working directory Project: make Submitted by: elfring Submitted on: Sun 25 Jun 2017 07:53:27 P

Re: ifeq and ifneq not working

)" # <-- prints subproj{A,B}/test.cpp if it exists -> this is working ifneq ("$(wildcard $(TESTSRC))","") @#file exists --> but even if the test src exists, this will never be reached CC=$(CC) CFLAGS='$(CFLAGS)' LDFLAGS='$(LDFLAGS)' $(MAKE) test -C $(TARGETDIR)

ifeq and ifneq not working

KE) all -C $@ $(TESTDIRS): $(eval TARGETDIR := $(@:test-%=%)) $(eval TESTSRC := $(TARGETDIR)test.cpp) @echo "$(wildcard $(TESTSRC))" # <-- prints subproj{A,B}/test.cpp if it exists -> this is working ifneq ("$(wildcard $(TESTSRC))","")

Re: Make recursion does not appear working in VMS

On 3/13/2014 8:14 AM, h.becker wrote: It looks like execve uses argv[0] to run make. With a VMS/DCL-style version of the Makefile and my mcr version of make it seems to work: I changed from the wrapper code to code that sets the makefile name, and temporarily set a local symbol as a foreign

Re: Make recursion does not appear working in VMS

On 3/16/2014 6:14 PM, John E. Malmberg wrote: On 3/13/2014 8:14 AM, h.becker wrote: It looks like execve uses argv[0] to run make. With a VMS/DCL-style version of the Makefile and my mcr version of make it seems to work: I changed from the wrapper code to code that sets the makefile name,

Re: Make recursion does not appear working in VMS

On 03/13/2014 05:29 AM, John E. Malmberg wrote: Further tests show that the parallelism is not fully working on VMS, or not working as a Unix program would expect. As far as I know, --jobs is not implemented for VMS, unfortunately I can't point to an obvious line in the sources. It seems

Re: Make recursion does not appear working in VMS

On 3/13/2014 4:19 AM, h.becker wrote: On 03/13/2014 05:29 AM, John E. Malmberg wrote: Further tests show that the parallelism is not fully working on VMS, or not working as a Unix program would expect. As far as I know, --jobs is not implemented for VMS, unfortunately I can't point

Re: Make recursion does not appear working in VMS

On 03/13/2014 01:17 PM, John E. Malmberg wrote: EAGLE del 1.inc;,2.inc; EAGLE EAGLE EAGLE make -f /lcl_root/make/tests/work/features/parallelism.mk_2 -j4 THREE.inc ONE.inc TWO.inc make: execve: make: no such file or directory /lcl_root/make/tests/work/features/parallelism.mk_2:2: recipe

Re: Make recursion does not appear working in VMS

. As near as I can figure out, it means that make is not doing its recursion to re-run the makefile on VMS. Further tests show that the parallelism is not fully working on VMS, or not working as a Unix program would expect. Of the 9 parallelism tests, 4 work, 4 fail, and one is not current valid

Re: Test harness on VMS working, 58 tests currently failing.

On 03/01/2014 09:50 PM, John E. Malmberg wrote: On 2/28/2014 8:07 PM, John E. Malmberg wrote: I have the test harness apparently working on VMS. I need to fix up the DCL command procedure that is needed set up a number of foreign commands needed by it before submitting a patch. For which

Re: Test harness on VMS working, 58 tests currently failing.

On 3/2/2014 6:11 AM, h.becker wrote: On 03/01/2014 09:50 PM, John E. Malmberg wrote: On 2/28/2014 8:07 PM, John E. Malmberg wrote: I have the test harness apparently working on VMS. I need to fix up the DCL command procedure that is needed set up a number of foreign commands needed

Re: Test harness on VMS working, 58 tests currently failing.

On 2/28/2014 8:07 PM, John E. Malmberg wrote: I have the test harness apparently working on VMS. I need to fix up the DCL command procedure that is needed set up a number of foreign commands needed by it before submitting a patch. If no one else is interested in immediately running the test

Test harness on VMS working, 58 tests currently failing.

I have the test harness apparently working on VMS. I need to fix up the DCL command procedure that is needed set up a number of foreign commands needed by it before submitting a patch. If no one else is interested in immediately running the test harness on VMS, I can wait on submitting

Re: .ONESEHLL not working as expected in 3.82

From: Paul Smith psm...@gnu.org Cc: bug-make@gnu.org Date: Sun, 28 Apr 2013 15:15:09 -0400 I think it pseudo-code it would look something like this: if (posix-shell) { ...strip out @-+ from LINE... } #ifdef WINDOWS32 if (need a batch file) { ...write

Re: .ONESEHLL not working as expected in 3.82

From: Paul Smith psm...@gnu.org Cc: bug-make@gnu.org Date: Sun, 28 Apr 2013 14:37:29 -0400 My plan was to write dlopen and dlsym, and add them to w32/compat/posixfcn.c. But I need to understand the semantics of global_dl in order to do that correctly. It's up to you how you think it

Re: Dynamic objects (was: .ONESEHLL not working as expected in 3.82)

From: Paul Smith psm...@gnu.org Cc: bug-make@gnu.org Date: Sat, 27 Apr 2013 16:58:54 -0400 On Sat, 2013-04-27 at 23:00 +0300, Eli Zaretskii wrote: That would be nice, indeed. OK, pushed. You should be able to simply write a new load_objects() function and drop it in. Or put it into a

Re: Dynamic objects (was: .ONESEHLL not working as expected in 3.82)

Sorry to keep adding in my 2c but I have also submitted a plugin implementation so I have a couple of ideas On 29 April 2013 17:33, Eli Zaretskii e...@gnu.org wrote: 2. The fact that the dynamic object's file extension (.so) is exposed to the Makefile is unfortunate, because it will hurt

Re: Dynamic objects (was: .ONESEHLL not working as expected in 3.82)

I must clarify - I think that make should provide plugins with an allocation mechanism. Not the other way around. the snprintf model for dealing with expansion is not so bad - I mean the problem is that nobody knows how big an expansion is going to be in the end, right? So how does make deal

Re: Dynamic objects (was: .ONESEHLL not working as expected in 3.82)

Date: Mon, 29 Apr 2013 18:19:09 +0100 From: Tim Murphy tnmur...@gmail.com Cc: Paul D. Smith psm...@gnu.org, bug-make@gnu.org bug-make@gnu.org 2. The fact that the dynamic object's file extension (.so) is exposed to the Makefile is unfortunate, because it will hurt portability of

Re: Dynamic objects (was: .ONESEHLL not working as expected in 3.82)

From: Paul Smith psm...@gnu.org Cc: bug-make@gnu.org Date: Mon, 29 Apr 2013 13:59:16 -0400 1. Doesn't the FSF frown upon capability to load _any_ dynamic objects? I think they like the GCC method whereby each extension is required to define a symbol with a certain name

Re: Dynamic objects (was: .ONESEHLL not working as expected in 3.82)

On 29 April 2013 20:12, Eli Zaretskii e...@gnu.org wrote: Date: Mon, 29 Apr 2013 18:19:09 +0100 From: Tim Murphy tnmur...@gmail.com Cc: Paul D. Smith psm...@gnu.org, bug-make@gnu.org bug-make@gnu.org 2. The fact that the dynamic object's file extension (.so) is exposed to the

Re: Dynamic objects (was: .ONESEHLL not working as expected in 3.82)

Date: Mon, 29 Apr 2013 20:40:46 +0100 From: Tim Murphy tnmur...@gmail.com Cc: Paul D. Smith psm...@gnu.org, bug-make@gnu.org bug-make@gnu.org How can one deal with them? The underlying OS is not easily detectable by Make. the same way one creates 1 makefile that can build the same

Re: Dynamic objects (was: .ONESEHLL not working as expected in 3.82)

Date: Mon, 29 Apr 2013 22:34:51 +0300 From: Eli Zaretskii e...@gnu.org Cc: bug-make@gnu.org Also we don't really have a precedent of a make-specific directory like that. Gawk puts them into ${prefix}/lib/gawk. Correction: ${prefix}/lib/gawk-extensions.

Re: .ONESEHLL not working as expected in 3.82

From: Paul Smith psm...@gnu.org Cc: bug-make@gnu.org Date: Sat, 27 Apr 2013 16:58:54 -0400 On Sat, 2013-04-27 at 23:00 +0300, Eli Zaretskii wrote: That would be nice, indeed. OK, pushed. Thanks! But I see you kept global_dl and the call to dlopen with the 1st argument NULL. What is

Re: .ONESEHLL not working as expected in 3.82

From: Paul Smith p...@mad-scientist.net Cc: make-...@gnu.org, bug-make@gnu.org Date: Sat, 27 Apr 2013 12:54:10 -0400 On Sat, 2013-04-27 at 19:17 +0300, Eli Zaretskii wrote: The .ONESHELL feature is now supported on MS-Windows, for the default Windows shell (cmd.exe) or compatible

Re: .ONESEHLL not working as expected in 3.82

On Sun, 2013-04-28 at 20:19 +0300, Eli Zaretskii wrote: From: Paul Smith psm...@gnu.org Cc: bug-make@gnu.org Date: Sat, 27 Apr 2013 16:58:54 -0400 On Sat, 2013-04-27 at 23:00 +0300, Eli Zaretskii wrote: That would be nice, indeed. OK, pushed. Thanks! But I see you kept

Re: .ONESEHLL not working as expected in 3.82

On Sun, 2013-04-28 at 21:14 +0300, Eli Zaretskii wrote: From: Paul Smith p...@mad-scientist.net Cc: make-...@gnu.org, bug-make@gnu.org Date: Sat, 27 Apr 2013 12:54:10 -0400 On Sat, 2013-04-27 at 19:17 +0300, Eli Zaretskii wrote: The .ONESHELL feature is now supported on MS-Windows,

Re: .ONESEHLL not working as expected in 3.82

From: Paul Smith psm...@gnu.org Cc: bug-make@gnu.org Date: Sun, 28 Apr 2013 14:37:29 -0400 On Sun, 2013-04-28 at 20:19 +0300, Eli Zaretskii wrote: From: Paul Smith psm...@gnu.org Cc: bug-make@gnu.org Date: Sat, 27 Apr 2013 16:58:54 -0400 On Sat, 2013-04-27 at 23:00 +0300, Eli

Re: .ONESEHLL not working as expected in 3.82

From: Paul Smith psm...@gnu.org Cc: bug-make@gnu.org Date: Sun, 28 Apr 2013 15:15:09 -0400 The goal of this code in the if-statement is to implement a special case allowing ONESHELL to be easier to add in the case where you DO have a standard shell. In that case, and ONLY in that case, we

Re: .ONESEHLL not working as expected in 3.82

On Sun, 2013-04-28 at 22:41 +0300, Eli Zaretskii wrote: I think the implementation you have is not quite right. I think the parsing of the @-+ stuff is common across all platforms if we have a shell, so you don't need the else /* non-posix shell */. I do need a separate code, because it

Re: .ONESEHLL not working as expected in 3.82

From: Paul Smith psm...@gnu.org Cc: bug-make@gnu.org Date: Sun, 28 Apr 2013 16:01:05 -0400 I guess I thought you were writing a batch file, then invoking the shell with the batch file name as the command to run. E.g., command.com batchfile vs. perl batchfile etc. I am naive but it seems

Re: .ONESEHLL not working as expected in 3.82

Date: Mon, 30 Aug 2010 17:09:51 +0100 From: Anjum Naseer a.nas...@resilientplc.com I have built the 3.82 version of GNU Make using the Microsoft Visual C++ compiler and it seems to work fine. However, I cannot get it to work correctly with the .ONESHELL option. I created a dummy makefile

Re: .ONESEHLL not working as expected in 3.82

From: Paul Smith p...@mad-scientist.net Cc: make-...@gnu.org, bug-make@gnu.org Date: Sat, 27 Apr 2013 12:54:10 -0400 Also, I wonder if you have a few minutes to go through the open Windows bugs in Savannah and make a comment or whatever to those which are still waiting (some are waiting

Re: .ONESEHLL not working as expected in 3.82

On Sat, 2013-04-27 at 20:55 +0300, Eli Zaretskii wrote: Note: there's one more major feature in current git repo that needs to be made available on Windows: dynamic loading of extensions. That is my highest priority for Make todo list. Yes. I wonder if there are features of gnulib which make

Re: .ONESEHLL not working as expected in 3.82

From: Paul Smith psm...@gnu.org Cc: make-...@gnu.org, bug-make@gnu.org Date: Sat, 27 Apr 2013 14:28:18 -0400 On Sat, 2013-04-27 at 20:55 +0300, Eli Zaretskii wrote: Note: there's one more major feature in current git repo that needs to be made available on Windows: dynamic loading of

Re: .ONESEHLL not working as expected in 3.82

I took with make-w32 list off. On Sat, 2013-04-27 at 22:18 +0300, Eli Zaretskii wrote: I added a similar facility to Gawk, but there a problem was much simpler, because Gawk itself was tracking the loaded extensions in platform-independent code. So my emulation of dlopen didn't need to

Re: .ONESEHLL not working as expected in 3.82

From: Paul Smith psm...@gnu.org Cc: bug-make@gnu.org Date: Sat, 27 Apr 2013 15:32:22 -0400 Well, we already maintain a list of modules that are loaded in the .LOADED variable. Although it's not written like that today, I have no problem changing the code to check that variable to see

Re: .ONESEHLL not working as expected in 3.82

On Sat, 2013-04-27 at 23:00 +0300, Eli Zaretskii wrote: That would be nice, indeed. OK, pushed. You should be able to simply write a new load_objects() function and drop it in. Or put it into a w32 file or whatever. ___ Bug-make mailing list

-n option not working under selected circumstances

Hi there, just stumbled on this while building openssl. Usually I run `make -n install' to see where things will eventually go. However, to my great surprise, I found that `make -n install' DID ACTUALLY INSTALL everything! After some work, it turns out that the problem can be reproduced (for

Re: -n option not working under selected circumstances

On Thu, 2010-01-21 at 18:17 +0100, gabriele balducci wrote: t1 : rm -f ./mom touch ./mom echo $(MAKE) All works as if the `-n' option is not honored when the variable $(MAKE) (and apparently only that) is referenced in a target's shell line: make -n t1 will create ./mom

Re: -n option not working under selected circumstances

[[ Please keep the mailing list on the CC line... ]] On Thu, 2010-01-21 at 18:56 +0100, gabriele balducci wrote: If I can take advantage of your patience: so, `make -n install' is not 100% safe? Well, actually, this is the first time I incurred in this problem in many years; yet... Whether

Re: -n option not working under selected circumstances

On Thu, 2010-01-21 at 18:56 +0100, gabriele balducci wrote: If I can take advantage of your patience: so, `make -n install' is not 100% safe? Well, actually, this is the first time I incurred in this problem in many years; yet... Whether it is safe or not depends on the whether that

Re: -n option not working under selected circumstances

oops, I might have botched something with the email, so I resend the last one: apologies for any noise. On Thu, 2010-01-21 at 18:56 +0100, gabriele balducci wrote: If I can take advantage of your patience: so, `make -n install' is not 100% safe? Well, actually, this is the first time I

Re: -n option not working under selected circumstances

On Thu, 2010-01-21 at 19:18 +0100, gabriele balducci wrote: Again: thanks a lot for your work and patience No problem. Cheers! ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make

conditionals not working for conditional variables in sub-make?

Please see the makefile attached. by running it it outputs: VAR=foo VAR2=bar VAR3=foo but I think VAR2 should be foo. Bug or do I misunderstand something? thanks, Istvan ifeq ($(VAR),foo) VAR2=foo else VAR2=bar endif VAR3=$(VAR) all: make var1 make var2 var1: VAR=foo

RE: conditionals not working for conditional variables in sub-make?

[mailto:bug-make-bounces+mdorey=bluearc@gnu.org] On Behalf Of Szekeres István Sent: Thursday, May 07, 2009 02:57 To: bug-make@gnu.org Subject: conditionals not working for conditional variables in sub-make? Please see the makefile attached. by running it it outputs: VAR=foo VAR2=bar VAR3=foo but I

Re: conditionals not working for conditional variables in sub-make?

Hi, 2009/5/7 Martin Dorey mdo...@bluearc.com: That's only a small fraction of what I see, with make-3.81.  This is what I see: [...] VAR=foo VAR2=bar VAR3=foo But here VAR2 should be foo As VAR=foo, the ifeq then-branch should set it to foo, but it goes into the else branch - which I

RE: conditionals not working for conditional variables in sub-make?

Dorey Cc: bug-make@gnu.org Subject: Re: conditionals not working for conditional variables in sub-make? Hi, 2009/5/7 Martin Dorey mdo...@bluearc.com: That's only a small fraction of what I see, with make-3.81.  This is what I see: [...] VAR=foo VAR2=bar VAR3=foo But here VAR2 should be foo

RE: conditionals not working for conditional variables in sub-make?

: conditionals not working for conditional variables in sub-make? 2009/5/7 Martin Dorey mdo...@bluearc.com: But here VAR2 should be foo! No, it shouldn't, for exactly the same reason that VAR2 isn't foo here: mart...@whitewater:~/tmp/bug-make-2009-05-07$ make var1 VAR=foo VAR2=bar VAR3=foo mart

RE: conditionals not working for conditional variables in sub-make?

, hence empty. -Original Message- From: Szekeres István [mailto:szeke...@iii.hu] Sent: Thursday, May 07, 2009 14:50 To: Martin Dorey Subject: Re: conditionals not working for conditional variables in sub-make? 2009/5/7 Martin Dorey mdo...@bluearc.com: VAR become foo when the var1 rule

Re: conditionals not working for conditional variables in sub-make?

2009/5/7 Martin Dorey mdo...@bluearc.com: But here VAR2 should be foo! No, it shouldn't, for exactly the same reason that VAR2 isn't foo here: mart...@whitewater:~/tmp/bug-make-2009-05-07$ make var1 VAR=foo VAR2=bar VAR3=foo mart...@whitewater:~/tmp/bug-make-2009-05-07$ Despite the number

$(and) and $(or) not working

I'm using the following: yapn:[EMAIL PROTECTED]:~/proj/aoeu make --version GNU Make 3.81beta4 Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

RE: $(and) and $(or) not working

On 16 May 2007 16:22, Noel Yap wrote: I'm using the following: yapn:[EMAIL PROTECTED]:~/proj/aoeu make --version GNU Make 3.81beta4 Note the beta tag. And the $(and) and $(or) functions always return empty. Has anyone else experienced this? Probably means they weren't yet

Re: $(and) and $(or) not working

On Wed, 2007-05-16 at 11:21 -0400, Noel Yap wrote: I'm using the following: yapn:[EMAIL PROTECTED]:~/proj/aoeu make --version GNU Make 3.81beta4 I've seen a number of messages stating that people are using 3.81beta4; why are people still using a beta version over a year after the final

[bug #15913] Target-specific immediate append operator not working as expected

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

[bug #15913] Target-specific immediate append operator not working as expected

Update of bug #15913 (project make): Assigned to:None = psmith ___ Follow-up Comment #1: Please see this reply I sent to the original message on the bug-make mailing list:

Target specific immediate append operator not working as expected

There is some weirdness going on with the append operator and target-specific contexts. The append operator should act immediately if the variable was originally assigned with an immediate assignment but this does not happen if the variable was globally assigned and the append is

escape \: not working properly

Hi, I cannot seem to escape : from the name name. Here is a test Makefile. 53 cat Makefile all: testDirColon testFileColon testDirColon: dir\:1/file1 echo Dir test passed: $? testFileColon: dir2/file1\:1 echo File test passed: $? 31 gmake gmake: *** No rule to make

Re: escape \: not working properly

%% Jason Sheu [EMAIL PROTECTED] writes: js I cannot seem to escape : from the name name. Here is a test js Makefile. Using colons in prerequisite names is not supported by make (same with spaces in names). There is an enhancement request on this in the Savannah bug database. --

Re: [bug #13952] Remaking included makefile fails under Linux RedHat 7.3 while working under Solaris 2.6

timestamp. Or, you could use 3 different files instead of updating the same file 3 times. tg This code was working on a (slower) Sparc Solaris 2.6, does it tg mean that GNU make will stop working on much faster machines tg because the filesystem resolution does not follow with higher tg

CURDIR not working properly on solaris

Hi It seems that the variable CURDIR does not work on solaris, making it impossible to use it as inside recursive makefiles (as it keeps the same value even if make is invoked with -C This is make-3.80 on solaris 8 , I have tried to recompile with various compilers: Sun 4.2 Sun 6U2

Re: CURDIR not working properly on solaris

to recompile with lj various compilers: lj Sun 4.2 lj Sun 6U2 lj Gcc 2.95 lj The make package available on sunfreeware also exhibits this lj behavior. Please always remember to include the version of GNU make you're using. Curdir can't really fail: it just gets set to the working directory

make not working

I have been running the LINUX 7.0 operating system for over a year now developing FORTRAN codes. I have been successfully using MAKE to complie and link FORTRAN routines. Suddenly in the last few days MAKE doesn't work anymore, I get the message "Nothing to be done for xxx.mak " , even though I

  1   2   >