non-execution ... environmental confusion ?

cat EOF Makefile noddy: time echo 'WTF?' EOF make noddy TIME=time make noddy Compare results. With TIME=time, I see (emitted to stderr, I find) the word time after the output from the command I wanted to time ... without it, I see the output from timing the echo (like I intended). If

make segmentation fault

I'm using GNU make from within GNU emacs using M-x compile. A (buggy) Makefile containing only: quote src=Makefile PACKAPPS = simple $(PACKAPPS:%=pack-index-dt-%): echo 'dt id=$(@:pack-index-dt-%:%)' \ 'a href=$(@:pack-index-dt-%:%)$(@:pack-index-dt-%:%)/a' \

Re: make segmentation fault

This bug is fixed in the latest version, GNU make 3.80. Please try that and let us know if it doesn't work. Finally got round to trying ... bad news: quote cd /home/eddy/work/toys/ /usr/local/bin/make boom-2002-Nov-13 Compilation segmentation fault at Thu Dec 19 12:50:17 /quote using quote

Make manual update

Hi GNU make maintainers, I began work on some additions and refinements to make.texi fourteen months ago but got distracted. The version I started from has @set EDITION 0.70 @set RCSID $Id: make.texi,v 1.45 2006/04/01 06:36:40 psmith Exp $ What's the most recent edition; and where can I find an

Re: Static multiple target rules

I've been struggling for some time now with how to write rules for commands that generate multiple targets A familiar and annoying problem: make really believes in commands that generate just one (relevant) file, and doesn't fit so well with ones that generate several. The next thing to try

Re: Static multiple target rules

Correcting myself: I missed out the $@ in y.tab.h y.tab.c y.output: yacc.ts tar xf $ -m $@ which ensures that each target is the only thing extracted when the rule to generate it is executed, Eddy. ___ Bug-make mailing list

Re: Static multiple target rules

The only downsides to this I see are: 1: The duplicate file storage. Probably not a big deal. 2: The extra processing time to archive and extract the files. Again, probably not a big deal. 3: The why'd they do that? questions coming from people unfamiliar with the technique. all valid

Re: [bug #29074] -include target fails to issue Error in 3.81

So there was a bug before 3.81, since they issued an Error in this case. And the bug was fixed in 3.81. Is that what you are saying? I think this misses the objection. include done = is looking for a file named done and fails since no file named done. -include done = is building a target

Re: [bug #29244] MSVC Compatibility broken with main.c Revision 1.237 (with Proposal for Fix)

the MSVC preprocessor doesn't support conditional compilation inside a macro expansion. I take it that's pseudocode FUNCTION_LIKE_MACRO(early, args, #ifdef SYMBOL symbol, #else token, #endif remaining);

Re: Static multiple target rules

y.tab.h y.tab.c y.output: yacc.ts I don't actually see that y.output serves any role in this; simply remove every reference to it and your example should be clearer. y.tab.o: y.tab.c y.tab.h I don't understand .INTERMEDIATE well enough to know why this chain fails to lead to y.tab.o's

Re: Shorter and less error-prone rule for automatic prerequisite generation in the GNU Make manual

It's also unnecessary - you don't need a rule for %.d at all. You can just generate the dependencies as a side-effect of compilation using -MMD or similar. Well, if a .d file gets deleted while its .o file exists, you do need to regenerate it - or regenerate the .o (which may cause wasteful

Re: Shorter and less error-prone rule for automatic prerequisite generation in the GNU Make manual

Delete a clean-depend rule on sight, I cannot agree. If I write a rule to make something, I also write a rule to get rid of it. It's just basic hygiene ... or rename it to the more accurate break-future-builds. If you have a sensible rule to generate .d files when needed, you haven't broken

Re: Shorter and less error-prone rule for automatic prerequisite generation in the GNU Make manual

If an update to new source code, that would compile just fine in a clean checkout, breaks the incremental build, the build system is errornuous. I would like to agree with you, but this constraint is, in general, incompatible with incremental building, which is too good a benefit to throw

Re: Shorter and less error-prone rule for automatic prerequisite generation in the GNU Make manual

The fix for that has been documented for years on Paul's webpage, and is most easily done now with gcc's -MP option. URL ? http://make.paulandlesley.org/autodep.html#norule Thanks. (That explains the problem and what needs to be put in the dependency files to solve it, and then gives an

Re: Creating a header file dependency.

Do you have any idea on how to achieve what I want? $(EXPORTED_HDRS): $(EXPORT_HDR_PATH)/%: ../include/% with the same command as you're using. Eddy. ___ Bug-make mailing list Bug-make@gnu.org

Re: [bug #27809] several win64 fixes

I'll think about it and check my ISO C 1989 standard (I can't remember whether it supports %p) when I get back to work on Tuesday. ANSI C '89 does specify the %p formatter (taking a void*). Finally, it seems that some of these changes are meant to avoid variable names conflicting with

Re: [bug #30340] dependency handling

You might read: http://make.mad-scientist.net/autodep.html Paul: do you have any plans to integrate your pages into the manual ? What's currently there falls some way short of best practice; I have a more sweeping set of changes than Florian's, that I've put on hold until I've got time to look

Re: GNU make 3.81.90 prerelease available

char *alloca (); Is this the right return type though? Wouldn't it be void*? I have no idea. You will see that I didn't touch that line in the patch, precisely because I don't know what is correct and for which platform(s). In GNU/Linux's gcc/glibc, it is indeed void*, but it's not in

Re: Setting RLIMIT_STACK

Probably there should be an effort to switch to heap for anything that might get large and reserve alloca() usage just for things we know for a fact will not get too large, but that hasn't been done. ... and anywhere you use a scanf variant, glibc is also using alloca(), without knowing any

Re: [bug #30505] Make doesn't update the entire dependency chain?

previous_var: echo $(VAR) previous_var .PHONY: previous_var I suggest you eliminate this .PHONY - previous_var is a real file on disk, so not a phony target. There might be a case for it to be declared .PHONY in an *else* clause, when PREVIOUS_VAR agrees with VAR. /source/test $ make

Re: [bug #30505] Make doesn't update the entire dependency chain?

The .PHONY forces make to update the file, even though it has no dependencies and would otherwise be considered up-to-date. Then you should force the target instead; this is an abuse of .PHONY. previous_var: FORCE echo $(VAR) previous_var FORCE: # no prerequisites # no rule will do

Re: [RFC]serialize the output of parallel make?

Make can redirect every parallelly issued shell's output to an temporary file,  and output the stored output serially, as if in a serial make. +1 for wanting this as a make feature. We a hack in some of our makefiles to implement essentially exactly the above. For reference, here's the

Re: [RFC]serialize the output of parallel make?

The shell wrapper buffers the recipe output and then grabs a semaphore before writing the output to it's stdout..  if another recipe has completed and is in the process of outputting to the stdout then it has to wait a few microseconds. The use of semaphore may impair performance. And

Re: [RFC]serialize the output of parallel make?

This seems like quite an extreme example. stdout is line buffered by default, on half-way decent systems - and even then, I'm not sure, it might be limited to when writing to a TTY. I use make -j 4 to build and test gcc, the situation above is very common. Then it means you're getting a lot

Re: Fwd: [RFC]serialize the output of parallel make?

If my guess is not wrong, the semaphore safeguard the consistency of output of one command, not the order of commands. well, with -j, commands are being run concurrently, so there *isn't* a strict ordering of commands to safeguard, although output shall be delivered in roughly the order of

Re: Fwd: [RFC]serialize the output of parallel make?

2x is too much. 1.5x has been the best in my experience, any more than that and you're losing too much CPU to scheduling overhead instead of real work. Any less and you're giving up too much in idle or I/O time. This depends a bit on whether you're using icecc or some similar distributed

Re: insufficient debug info from gnu-make

the output I see from make is after all macro substitutions have been made, which can make it virtually impossible to recognize as far as where it came from in the original source This, however, is an issue with how the make file is written. It sounds like its recipes for commands are of

Re: Override... but not really

I do a lot of cross-compilation, where the platform requires a set of CFLAGS to always be present, such as -march=xxx and -isysroot= ... Suggestion: Set CROSS = -march=xxx -isysroot=yyy where you're currently trying to hack CFLAGS and have makefiles that are actually going to use CFLAGS

Re: [bug #31002] make picks wrong pattern rule

Roland, I think you overstate the seriousness of the problem. ... and I think you are understating it. There are not many makefiles that both define multiple pattern rules and rely on their order for selection. Mine do. Not that I realized it until things didn't work as I expected, after

Re: The bugs in make v3.82

Using a directory as a normal prerequisite is almost never what you want. You have two choices. Three: wherever you currently declare a dependency on a directory, instead declare a dependency on a .exists file *in* that directory. Then have the rule for a .exists file create its directory and

Re: Intermittent parallel make rebuild failures

Every time the subject of cache comes up its because they are always wrong. well, this *is* a *bug* list - every time anything comes up here, it's because someone's found a bug in it ! The vast amount of the time that the cache works just fine and makes builds faster is (quite properly) not

Re: [bug #31614] allow spaces in target names

$ echo 'a b:; echo $@' | make -f - a b echo a b a b and what happens if you echo 'a b:; echo $@' | make -f - a ? If that doesn't echo a, then you've broken all rules with more than one target ... I expected your escaping to require echo 'a\\ b:; echo $@' | make -f - 'a b' or echo 'a

Re: [Patch #7327] Add the option -J / --auto-jobs to auto-decide a sane number of job slots

This patch adds the option -J / --auto-jobs, which uses the sysconf(_SC_NPROCESSORS_ONLN) function to decide the number of job slots to use. This sounds like a highly useful feature to me. I and my colleagues use diverse clumsy rules of thumb to decide what value to give to -j and -l; having

Re: Detecting parallel builds

I'm trying to find an easy way to detect inside of a makefile if we're running as a parallel make or not. See 5.7.3 Communicating Options to a Sub-`make' and, particularly, the MAKEFLAGS variable. Not sure of details, but I expect any -j option to appear in it. Eddy.

Re: makefile target all: not built automatically

Perhaps it could even be mentioned in this chapter that all is not a special target: There are quite a lot of other target names we could mention as not being special targets ! I think the thing you need to know, to understand what *is* documented, is that the first rule read, when parsing the

Re: Make 3.82: weird circular dependency and missing $ expansion

So, the circular dependency issue is because of this: %.eps: %.pdf %.eps %.pdf: %.dat Technically, not a circular dependency: in the directed graph of dependencies, there is no cycle. If we ignore the directedness of some edges, we get a cycle; but the edges *are* directed, and we must go

Re: makefile line number when errors

Not really sure why, but the - on the beggining of the -unknown-exe seems to cause the error to be (ignored). The command part of a make rule can optionally begin with various characters that modify how make runs the command or responds to the results of running it; a command-line starting with

Re: New Feature Submission for GNU Make

I like what I see ;-) I haven't looked at the code, but one warning: it's important to not assume that blah/../foo/ is equivalent to foo/ - blah might be a symlink. *Justification (trimpath)*: trimpath can be used to shorten the input strings to compilers/linkers, as well as improve

Re: New Feature Submission for GNU Make

Pretty weak. If a few more include paths were added to the project it would still break, regardless of your patch. When you have thousands of object files, shortening the name of each by several bytes when invoking ar can make room for really quite a lot more files before you run up against

Re: VPATH file rename is not detected by $

I got lost in your perl script, so may have missed something; but it *looks* as if what's happening is that your .d.cmd file records the prior path of what was $ on your previous run; so the .o file depends on that (as well as the newly renamed file that's $) and this is the problem, not the fact

Re: $(sort) - what is lexical order? (was RE: Follow-up)

GNU make uses the standard C runtime function qsort(3) to perform its sorting, with a comparison function of the standard C runtime function strcmp(). ... The builtin sort function DOES sort. It may not sort the way you would prefer, but it sorts in a standard, repeatable, well-defined way

Re: suggestion: new make function

I have limited sympathy for this type of situation, multifile compilation is against the general idea of make. On the other hand, running ar once per .o file cost time (at least) quadratic in the number of files, when I tried it. So multifile archiving is perfectly standard - and it's usually

Re: [rfc] Colorized output for GNU make?

The other thing I wonder about is the hardcoding of ASCII colorized strings and the start/stop character strings (\033[...). Are there other methods of colorizing? Yes. Indeed - most obviously, anyone running a build-'bot that reports its build logs via the web (it's a common solution for

Re: Cleanup of makefiles 'n stuff

The contents of these files don't seem so different to me that they couldn't be consolidated, perhaps with some command-line overrides or similar. Or, maybe some of them are just not needed; do we really have to be able to build with nmake and smake? How about moving them to a subdirectory,

Re: Cleanup of makefiles 'n stuff

In the presence of a version control system, even one as basic as CVS, deletion isn't fundamentally worse than leaving them to bit-rot out of [sight] - they can always be recovered from the version-control system Not for people who only get the release tarballs. Good point - didn't think of

Re: Content tracking mode for make

Somtimes, it is possible that a code generator replaces the existing files in the code base with the same content. It might be a good option to enable content checking before make rebuilds the replaced file (with the same content) again. Another approach: have the code generator run on a

Re: include should be relative to current Makefile

I think changing gmake's behavior to match cpp's will eliminate the need for a lot of hacky farting around to get non-recursive systems working smoothly. I can sympathise. The present behaviour effectively requires one to cd to (or pass a -C for) the directory of a make file in order to

Re: tasklist item still relevant?

... someone, not sure who, has worked out how to solve this problem within the existing capabilities of GNU make. ... it would still be best if GNU make had (optional) native support. ... or, at the very least, its documentation included a description of how to solve the problem, within the

Re: [bug #712] GNU make can't handle spaces in pathnames

I don't think make can be expected to handle spaces in filenames because by design it relies on many other tools and scripts that cannot handle them or handle them in very idiosyncratic ways. You're in for a lot of trouble regardless of what make itself supports. Most Unix scripters know this

Re: [bug #712] GNU make can't handle spaces in pathnames

I have always wondered why we did not pick another character than ascii 32 to represent space in file names. That would involve the disk driver - or all software that creates files - mapping the space the user typed to the chosen codepoint. There are then a whole load of other places software

Re: dynamic object searching (was: Re: Dynamic objects)

... or VMS shell (whatever that is) ... it was called DCL (Digital Command Language, I suspect) and the one feature I remember clearly is its help. If you typed help at the prompt, it was actually *helpful* in response. I have not seen that since. Eddy.

Re: Default output-sync setting (was: Re: [bug #33138] .PARLLELSYNC enhancement with patch)

Eli: cc fred.c -c -o fred.o cc bob.c -c -o bob.o error on line 20 -X error on line 30 - error on line 330 - makefile:342: recipe for target 'fred.o' failed makefile:350: recipe for target 'bob.o' failed You need to look in both anyway. That is true of the very specific

Re: Another issue with -O?

I think having this facility built into make is a win, especially as parallel builds become predominant. I would be even more happy about it if we can get it to the point where it can be enabled by default, and users don't even have to worry about it. I agree with Paul. This is something

Re: [bug #39028] [patch] fix and uniformize four error messages

How about using plain language and calling it a whole number instead of using jargon ? How about not catering to the lowest common denominator and devolving to baby-speech for fear that someone may be intimidated by a dictionary ? Saying what you mean in the plainest terms possible isn't

Re: [bug #33138] .PARLLELSYNC enhancement with patch

No, that wouldn't work. It's not the individual command (between simicolons) that's too long, the problem is that make can't invoke the shell itself because the command line + environment is too large. The only way to work around this limitation is to avoid invoking a single command that's

Re: [bug #40225] Deterministic output ordering

Then commit all the log files to git and use git show to find out which of them have changed since the last build. (I trust you can all work out the equivalent steps for *your* preferred SCM system.) This only has to happen on the server that builds from clean on a regular basis. Or just

Re: make-4.0 allows empty ARFLAGS to be passed to ar

It's the long one (subdir-dtc) where the problem exists. Obvious first step: configure quiet-command to actually show the command, or remove this wrapping from the command, so that you can see what the sub-make actually gets invoked with. We can guess, but it may help to be entirely clear !

Re: error reporting

Note that in Unix, vsnprintf() returns the TOTAL number of chars needed (add 1 for the null). This is not correct. The buffer size (that you pass in) is the total number of bytes available (and the most the function shall use, including the terminator); but the *return* is the strlen() that

Re: error reporting

I'm really not excited about the prospect of continuing to add new project files every year for each new version of Visual Studio. Isn't there any sort of backward-compatibility that allows the older files to work in newer Visual Studio releases? Don't hold your breath - it might be there,

Re: [bug #42270] Make needs to canonicalise paths

Plainly _AA_ and _$(abspath AA)_ are the same file, but make doesn't think so. Make seems just to use string matching (other relative paths to the same file are seen as different files (_subdir/../A.. for instance)). That is correct: make targets are strings. Distinct strings are treated as

Re: Dynamic adjustments of build dependencies for the number of available processors

On Mon, Jan 5, 2015 at 1:23 PM, Paul Smith psm...@gnu.org wrote: I wrote some blog posts about eval and other metaprogramming techniques in make that you might find interesting: to which Norbert Thiebaud nthieb...@gmail.com replied: For a real-life large scale use and abuse of these techniques

Re: Parallel make

Luckily, if you are building C or C++ code someone has already done all the necessary work for you. I recommend you investigate the distcc package: https://code.google.com/p/distcc/ Likewise the icecream project's icecc: https://en.opensuse.org/Icecream https://github.com/icecc/icecream I've

Re: Parallel make

We ran into similar things in Linux due to NFS, autofs, and NFS via apparmor not scaling well when 100 compilers are trying to search for header files through a long number of sourcedirs. I suppose this can be mitigated by using #include path/to/file.h in source, for paths relative to a small

Re: new flag to show executing shell command

I am a new beginner of gnu Make. in some cases, I fell that it will help if Make can print the executing shell command even suppressed, for example, to identify problem more easy. Since it seems that Make doesn't have this flag, I tried to change code. the code diff is in below and happy to

Re: Using hash instead of timestamps to check for changes.

After reading over your mail a couple of times, I realized that I hadn't thought things through very well. In fact, rather than saying hash instead of time, I should have said optional additional hash check when timestamp has changed. Even so, I'm unclear about why hash is the thing you want

Re: [bug #45275] 4.0+ core dumps with long .PHONY targets via variables

4. Running under gdb I was able to get a stack trace showing the eventual seg fault occurring in xcalloc(). The trace is below. This almost certainly means that, before this point, something over-ran the end of a memory buffer and trampled malloc's data structures. So the first line of enquiry

Re: [patch] Guile conditional

ifeq ($(shell if [ -f /my/file ] ; then echo 0; else echo 1; fi), 0) Why not: ifneq ($(wildcard /my/file),) which tests existence just as well. Of course, it does also match if /my/file is a directory or other non-file, but it's almost always sufficient, unless there's some actual

Re: [bug #46242] Race condition when input file is updated while compiling

> There's an inherent race condition in the way "make" handles timestamps. If > you save a newer version of a file while make is running and is just compiling > that input file, the change won't be picked up by subsequent runs of "make", > and you'll be left with an out-of-date binary. The

Re: Rebuilding archives

> My problem is that Fedora have choosen to ship a broken version of > "ar" that always sets the timestamp of all archive members to 1970-01-01 > unless one invokes it with the U flag. For the sake of anyone else curious about what that means, here's what man ar told me when I looked up the

Re: make -jN runs some rules more than once

>> a.gz b.gz: >> touch a >> gzip a >> touch b >> gzip b Paule explained (in detail) > multiple explicit targets are just a shorthand way of writing multiple rules, ... and if you actually want to do two things at the same time, you can do it, via a phony

Re: Make: Unexpected Behavior with Dependencies and include Statement

> I was thinking to build the objects but not the dependencies. We do a lot > of one-time only builds, where we don't need dependencies at all. In that case, leave out the include of any .d whose .o doesn't exist; you fatuously know you need to build the .o, so you don't need to know its

Re: reverse dependency order?

> It might be interesting to have a make flag that would reverse the order > in which dependencies are considered, ... or indeed randomise the order, so that repeated testing would routinely catch any un-noticed dependencies. Does anything actually specify that order of prerequisites in a rule

Re: [bug #50062] Variable needed to check that Makefile is run by GNU make?

> If you really need some features only supported by GNU Make, why not > rename this makefile to "GNUmakfile"? ... which, furthermore, ensures that - if the make-file is picked up by some other make that thinks it knows what to do with a GNU make-file - the reader is primed with the knowledge

Re: [bug #50062] Variable needed to check that Makefile is run by GNU make?

> When one wants to check that it is really GNU make that is run for a > given Makefile The only valid use case I can think of for this is where some particular feature of GNU make is needed. Generally, it is better to test *that feature* rather than the version of make in use. If another

Re: Bug/Typo in make man Page

Pooya Taherkhani wrote: >> To prepare to use make, you must write a file called the makefile >> that describes the relationships among files in your program, and the >> states the commands for updating each file. > I think "..., and the states the commands for ..." should be "..., and > states

Re: exported vs command line variables

On Fri, 2016-09-23 at 13:24 +, Edward Welbourne wrote: >> This does seem like an unsound choice, for the reasons David gave, Paul Smith replied: > Perhaps but as discussed, it's been that way in GNU make (and other > versions of make) forever and is required by the POSIX standard.

Re: exported vs command line variables

David Boyce observed: > I was unpleasantly surprised to learn while following this discussion > that "Except by explicit request, make exports a variable only if it > is either defined in the environment initially _or set on the command > line_". ... and I was surprised to find (by experiment

Re: [bug #49681] Make fails to glob lib/*.{o,a}

anonymous reported: > This is a regression from GNU make 4.0. The make target > > clean: > rm lib/*.{o,a} > > fails to remove files lib/foo.o, lib/bar.o, and lib/libfoobar.a because > lib/*.{o,a} does not glob lib/*.o and lib/*.a, as is its intention. This is a rule, which make hands

Re: [PATCH] Improve “missing separator” error when reading spaces

Michael Stapelberg's patch: diff --git a/read.c b/read.c index b870aa8..3c67e55 100644 --- a/read.c +++ b/read.c @@ -1122,6 +1122,8 @@ eval (struct ebuffer *ebuf, int set_default) one of the most common bugs found in makefiles... */ if (cmd_prefix == '\t' && strneq

Re: [bug #50823] MAKEFILE_LIST contains wrong file name if file name contains dollar character

> To reproduce: > > $ echo -e 'all:\n\techo $(value MAKEFILE_LIST)' > /tmp/foo\$bar.mk > $ ./make -f '/tmp/foo$bar.mk' > echo /tmp/fooar.mk > /tmp/fooar.mk > > I think this is inconsistent and contradicts the documentation, which states > "MAKEFILE_LIST Contains the name of each makefile that is

Re: errors in "make"

wu (7 March 2017 08:55): > the software reports the following errors: > > ... relocation ... against `.rodata' can not be used when making a shared > object; recompile with -fPIC I recommend you do as it says; change your CFLAGS or CXXFLAGS to use -fPIC (replacing -fpic,

Re: [bug #50790] Some kind of memory corruption in error messages with gcc-6.3.0 -flto=4

Jan Ziak (12 April 2017 20:07) > Is this a make-4.2.1 bug, or a gcc-6.3.0 bug? The line numbers in the garbled > error messages, in this case 79 and 84, are correct. Given its sensitivity to the specific flags passed to gcc, it's natural to suppose it's a gcc bug. You can test by running gcc

Re: [bug #51434] Document that variables are treated differently in prerequisite lists and recipes

> VARS=a.c b.c > > p: $(VARS) > echo i am using $(VARS) to build > echo $(VARS) > p > > VARS=x.c y.c > > Here $(VARS) in the prerequisite list is expanded when make reads that > line of the file (to "a.c b.c") but the $(VARS) in the recipe on the > next line is expanded to its value

Re: [bug #51495] Notice when a rule changed, so target needs rebuilding

Henrik Carlqvist (18 July 2017 15:46) > The quick and easy way to accomplish this today is of course to also > add the Makefile to the prerequisites of targets. If you don't want > every target to be rebuilt when only one rule has changed it is also > possible to split the Makefile up into several

Re: A Severe Problem with Make

Iman Moosaie (19 July 2017 19:19) > I use Ubuntu Linux on my system. I have downloaded and tried to > install the make-4.2.1 package but when I execute the 'make' command > (after the package is configured) I encounter a problem and I don't > know how to resolve. can you help me? > > I have put

Re: [bug #51311] Checking search retries for implicit make rules

Mike Gran (25 June 2017 22:54) > The '%' (the stem) in a pattern rule doesn't, if I recall correctly, > match a null string. It needs to match at least a single character, > so building MOTD.log won't work. At the risk of stating the obvious, note that there is a trivial work-around for this -

Re: Target-specific variable in subdirectory problem

Benjamin Cama (2 August 2017 12:19) > I may be doing something wrong, but the following Makefile gives me > strange results: the target-specific variable does not apply when used > for a target in a subdirectory. > >test-%: FOO = BAR >test-%: >echo $(FOO) > > E.g.:

Re: [bug #51269] Reusing data from targets for prerequisites

Markus Elfring (20 June 2017 11:43) > I got another software development concern for such an use case. > > * Can it eventually happen that dependencies will not be resolved if > target names do not contain the percent character? I can't remember, but a simple experiment should answer that ! >

Re: [bug #51269] Reusing data from targets for prerequisites

Markus Elfring (19 June 2017 19:34): > The documentation contains the following information: > “… > It’s very important that you recognize the limited scope in which automatic > variable values are available: they only have values within the recipe. > …” > > How are the chances to adjust this

Re: GNU Make 4.1 carrying on after -f missingfile.mak

Jonny Grant (24 May 2017 12:27) > In that successful case, would the "No such file or directory" message > not be visible? My guess is that it would be displayed, by the initial run of make; but then make would re-invoke itself and do its job. As long as the rule to make the missing make-file

Re: GNU Make 4.1 carrying on after -f missingfile.mak

Jonny Grant (24 May 2017 09:40) > $ make -f missingfile.mak > make: missingfile.mak: No such file or directory > make: *** No rule to make target 'missingfile.mak'. Stop. > > Shouldn't Make exit after the missing file? > > Make appears to be carrying on, and then treating the makefile as a target.

Re: Q: On Windows why not ignore CRLF?

Paul Smith (31 May 2017 19:48:57 -0400) >> > #if !defined(WINDOWS32) && !defined(__MSDOS__) && !defined(__EMX__) >> > /* Check to see if the line was really ended with CRLF; if so >> > ignore >> >the CR. */ >> > if ((p - start) > 1 && p[-2] == '\r') >> > {

Re: Are prerequisites made in deterministic order when parallelism is disabled?

Brett Stahlman (13 June 2017 17:33) > I don't see anything in the Make docs that guarantees prerequisites > will be processed in left to right order. Opinions on the web seems to > be split into 2 camps: > > 1. Make always builds dependencies in left to right order, but a >well-designed

Re: mention if a=b make = make a=b

Dan Jacobson (20 November 2017 23:50) > (info "(make) Environment") should mention how equivalent > $ a=b make #and > $ make a=b > are to each other. > See also http://debbugs.gnu.org/29270 They're not quite equivalent, although an example like the one you give may be a good one for the

Re: Pattern matching for static pattern rules

Alex Dehnert (22 May 2018 00:03) > I was running into some behavior that surprised me when using static > pattern rules with files in a subdirectory. [snip] > With (implicit) pattern rules, "When the target pattern does not contain a > slash (and it usually does not), directory names in the file

Re: Linux kernel 2.6.26, make 4.1, menuconfig: no rule

Brenton Chapin (7 June 2018 18:30) wrote > Tried to configure Linux kernel 2.6.26 on Lubuntu 18.04 with make 4.1 and gcc > 7.3. > "make menuconfig" gives "No rule to make target menuconfig". > > With make 3.8 (Lubuntu 12.10), menuconfig works. > With kernel 2.6.32 and make 4.1, menuconfig works.

Re: Add .ALL_WARNINGS_FATAL special target

Dan Jacobson (29 December 2017 03:41) [snip] > Therefore please add a new > '.ALL_WARNINGS_FATAL' > or something (that we error prone careless > programmers can use, just like we put > use warnings FATAL => q(all); > in all perl files we write today,) > or make it the default, and instead add a >

Re: use of math.h / libmath discouraged?

On Wed, 2018-07-25 at 14:25 -0600, Brian Vandenberg wrote: >> # note: the space before the word TEXT is helpful for readability but causes >> a problem >> $(info $(call F1, TEXT)) Paul Smith (28 July 2018 14:48) replied: > To me this seems like a bug. In GNU make generally the rule is >

Re: [bug #54529] [Makefile:5: foobar] Segmentation fault

On Aug 21 2018, Mark Galeck wrote: >> Then why does the error say "make: ***" ? Andreas Schwab (21 August 2018 09:42) replied: > Because it's the messenger. Indeed. It remains that the message is apt to confuse a user. If the message included (at least the name of) the command that failed,

Re: posix_spawn() instead of fork()?

Barath Aron (13 March 2018 21:47) > I'd like to build projects on a system that lacks fork() and vfork() > support, but has posix_spawn(). Would you implement an alternate version > using posix_spawn() to spawn child processes? You might get lucky, but the maintainer probably has many other

  1   2   >