Re: 'no rule' warning not precise enough language
PS> We've already had this conversation at least once Let's see, at this rate we'll have it again in 2017. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: 'no rule' warning not precise enough language
$ cat Makefile W=wget -Y off D=2013-05-02 %.kml:%.html %.xq; basex $*.xq < $< | ./postprocessor %.html:; $W http://eaip.caa.gov.tw/eaip/history/$D-AIRAC/html/eAIP/$@ $ make RC-ENR-3.3-en-TW.kml make: *** No rule to make target `RC-ENR-3.3-en-TW.kml'. Stop. $ touch RC-ENR-3.3-en-TW.xq $ make RC-ENR-3.3-en-TW.kml wget -Y ... ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
'no rule' warning not precise enough language
using %.kml:%.html %.xq; basex $*.xq < $< | ./postprocessor make q.kml will say 'no rule to make q.kml' until one creates a q.xq file So it should say something different than 'no rule' because there indeed is a rule. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
no way to make the first and other item without looking in the Makefile
Gentlemen, $ make makes the first item. $ make FARB makes the FARB item. But there is no way to make both, without looking in the file to find the name of the first item! $ make FARB BLZZ #if the first item is called BLZZ OK, no big deal never mind. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: add Order-only Prerequisites example
> "PG" == Philip Guenther writes: PG> Nope, wrong. If you want make to guarantee that, you must express it PG> as a dependency between C and B. OK thanks. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: add Order-only Prerequisites example
> "PS" == Paul Smith writes: >> A:B C;D >> A:|B C;D PS> No. C will never be run first, before B. If you enable parallel builds PS> then B and C might be run at the same time (but B will still be started PS> first, then C). I recall someone said that there was no guarantee of order even in the most vanilla (-non-option) of cases. OK, I sure hope it will get documented that A:B C;D implies that if B fails, C will never get run (or built etc.), and we never have to worry about C getting run first (unless we use some -option.) I.e., C will only get run after we know the results of B. PS> In the first example, first B and C will be rebuilt then A will be PS> rebuilt if either A doesn't exist, OR B or C are newer than A. PS> In the second example, first B and C will be rebuilt then A will be PS> rebuilt if A doesn't exist, period. Since B and C are related to A by PS> build order ONLY, they are built first BUT they don't play a role in PS> deciding if A should be rebuilt. All this I would never have dreamed of an I think examples should be added to pound it into the users' head. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
add Order-only Prerequisites example
Can you please add at least _one_ example to (info "(make) Prerequisite Types") also consider retitling it "Order-only Prerequisites" or adding a sub-section. Does it mean the only difference between A:B C;D A:|B C;D is that C might be run first in the former? ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: If the user accidentally uses ; instead of :
$ apt-cache policy make make: Installed: 3.81-8.2 Candidate: 3.81-8.2 Version table: 3.82-1 0 1 http://ftp.tw.debian.org/debian/ experimental/main i386 Packages *** 3.81-8.2 0 500 http://ftp.tw.debian.org/debian/ unstable/main i386 Packages 100 /var/lib/dpkg/status OK, I tired it with 3.82-1 and indeed it is fixed. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
If the user accidentally uses ; instead of :
If the user accidentally uses ; instead of : $ cat Makefile m;groups.html;w3m -cols=999 -dump $? g:g.xq; basex $? The erroneous line produces nary a warning, and we proceed to execute something else. $ make -n basex g.xq Yes maybe the first line means something arcane. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: .DELETE_ON_ERROR doc
OK I found it in my makefile. I.e., oops never mind. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
.DELETE_ON_ERROR doc
(info "(make) Errors") says Usually when a command fails, if it has changed the target file at all, the file is corrupted and cannot be used--or at least it is not completely updated. Yet the file's time stamp says that it is now up to date, so the next time `make' runs, it will not try to update that file. The situation is just the same as when the command is killed by a signal; *note Interrupts::. So generally the right thing to do is to delete the target file if the command fails after beginning to change the file. `make' will do this if `.DELETE_ON_ERROR' appears as a target. This is almost always what you want `make' to do, but it is not historical practice; so for compatibility, you must explicitly request it. I find I don't have to explicitly request it. Or maybe it is only talking about interrupts. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
foreach() needs additional simple example
On (info "(make) Foreach Function") why oh why can't you start with a an additional simple example? Please say $(foreach m, a b c, X$(m)Y) expands to XaY XbY XcY OK? Thanks. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: bug report acknowledgments should be the default!
PS> however, and so I wouldn't expect people to think that messages to PS> that list would become bug reports and automatically acknowledged, a PS> la Debian's BTS etc. Anyways from all the GNU man pages (but not exactly make's, true, but we just remember bug-make@gnu.org anyway and wouldn't check the man page), one thinks filing a bug against a package/program is as easy as sending it to bug-*@gnu.org. That some assign a number and autoreply, like bug-gnu-em...@gnu.org (which in fact now uses Debbugs software), and some don't, and some even... well, let's say reports are very likely to fall through the cracks and be wasted... is something I would hope you fellows would unify behind the scenes. Well OK, that those addresses have "bug" in them means someone will not let them fall through the cracks one hopes. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: bug report acknowledgments should be the default!
> "PS" == Paul Smith writes: PS> If you want a bug report to be filed and acknowledged, then you want: PS> https://savannah.gnu.org/bugs/?func=additem&group=make Thanks for answering! Well that's not the advertised way to submit bugs. You advertise bug-*@gnu.org. PS> The FSF does not use an email-based bug tracker, like Debian; we use PS> Savannah. OK, but Savannah should then be made to send acknowledgments by default. The power users could easily adjust some of their settings to turn them back off. Just telling you how it all looks from this end. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
bug report acknowledgments should be the default!
I noticed that when submitting bugs to bug-*@gnu.org, unlike other bug submission by mail systems, e.g., Deb bugs of Debian, the user receives no cheery auto reply acknowledging the bug was ever even received and didn't go into a black hole, or expecting the user to dig out what happened to his submission via poking around the website. Let's the advanced user disable notifications like they can in Debian. For the default state, please enable auto acknowledgments of bug mail received, like Debian does. Anybody reading this? Anybody get this? ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
say what will happen when one combines -n and -s
On (info "(make) Echoing") (info "(make) Options Summary") explicitly say what will happen when one combines -n and -s. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
mention how to get the other half of $*
(info "(make) Automatic Variables") says `$*' The stem with which an implicit rule matches OK, that is the stem. Now mention what can we use to get the other half. OK, the answer apparently is here. Please mention it. %.xcf %.jpeg:%.pdf; gs -sDEVICE=$(subst .,,$(suffix $@)) -sOutputFile=$@ -dNOPAUSE -dBATCH $? ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
allow backslashing comma and space
(info "(make) Syntax of Functions") Commas and unmatched parentheses or braces cannot appear in the text of an argument as written; leading spaces cannot appear in the text of the first argument as written. These characters can be put into the argument value by variable substitution. First define variables... Good heavens. Why not just let "\ " mean space and "\," mean comma or something? Or mention the reason for the "hoops" right there on the Info page. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: is the man page really 21 years old?
> "JN" == Jonathan Nieder writes: JN> The header line is somewhat arbitrary. If you have a good idea for JN> what it should contain (in the form of nroff markup), I wouldn't be JN> surprised if it gets used. That's the problem, you folks accept headers from just about anybody. No standards in sight. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: mention converses
> "PS" == Paul Smith writes: PS> On Mon, 2010-12-27 at 16:19 +0800, jida...@jidanni.org wrote: >> On (info "(make) Automatic Variables") you mention >> `$(@F)' is equivalent to `$(notdir $@)'. >> >> But on (info "(make) File Name Functions") you don't mention the >> converse! >> >> Nobody would have guessed there are shorter ways to write those things. PS> Only the automatic variables have special shorthand such as $(@F), etc. PS> $(notdir ...) works with any value, and so the documentation for that PS> function is generic and doesn't mention special cases that only work PS> with a limited number of variables. Do say 'for some things there are even shorter ways...' else "sure felt foolish the day I discovered there was a shorter way all along". ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Bug#608102: is the man page really 21 years old?
X-debbugs-Cc: bug-make@gnu.org Package: make Version: 3.81-8 Severity: wishlist Is the man page really GNU 22 August 1989 MAKE(1) 21 years old? Or even COPYRIGHT Copyright (C) 1992, 1993, 1996, 1999 Free Software Foundation, Inc. This file is part of GNU make. 11 years old? Cat looks much better, GNU coreutils 8.5 April 2010 CAT(1) P.S., the top is different too, MAKE(1) LOCAL USER COMMANDS MAKE(1) CAT(1) User Commands CAT(1) ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
mention converses
On (info "(make) Automatic Variables") you mention `$(@F)' is equivalent to `$(notdir $@)'. But on (info "(make) File Name Functions") you don't mention the converse! Nobody would have guessed there are shorter ways to write those things. Same for all the other items on those pages. $ make -v GNU Make 3.81 ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
no way to specify a target with a "=" in its name on the command line
You make(1) fellows may be really smart, but you forgot to give the user a way to specify a target with a "=" in its name on the command line. Nope, even in $ make -- dummy ./j=k The ./j=k is interpreted as a variable setting. Backslashes are no help either. P.S., I hope it is documented that a b c=d:;echo $@ set the variable "a b c" to "d:;echo $@". GNU Make 3.81 Copyright (C) 2006 That's the latest in Debian "sid". ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
mention if functions can be used near the colon
On (info "(make) Functions") mention if functions can be used Here:Or here As well as of course here If so, add some examples, as currently they are all := examples, and no : examples. Also too bad we can't operate on $@ even though we already ought to know it at this point: %.bla:$(subst ...,...,$@) P.S., in (info "(make) Concept Index") there is a listing for double colon, but none for single colon. Nor in (info "(make) Name Index"). P.S., trailing blanks exist in (info "(make) Pattern Intro") make 3.81-8 P.S., no fair asking me "what are you actually attempting to do?" as I was just poking around. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Bug#605639: deal better with different filesystem timestamp resolutions
P.S., regarding the documentation of `.LOW_RESOLUTION_TIME' Here with GNU Make 3.81, I think you should not blame the cp command, but instead say "when using a mixture of filesystem types, or in some other situations, one might want to specify some files were made with low resolution timestamps..." Indeed, for my situation all the files were low resolution (ext3), except this one on /tmp, where a .HIGH_RESOLUTION_TIME might have come in handy. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Bug#605639: deal better with different filesystem timestamp resolutions
> "EZ" == Eli Zaretskii writes: EZ> What's wrong with using the special target .LOW_RESOLUTION_TIME? One cannot find it with searches for "seconds" "comparison" etc. OK, thanks! Please add a cross reference to it on many of the places where (Info-search "modification") is mentioned. Thanks. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Bug#605639: deal better with different filesystem timestamp resolutions
>>>>> "PS" == Paul Smith writes: PS> Make already uses high-resolution timestamps for comparison PS> automatically on filesystems that support it, if that's what you PS> mean. That's the problem, when two different resolution filesystems are involved, make will always see these, $ ls -l /tmp/zaokeng.kmz ../../jidanni.org/location/zaokeng.kmz --full-time -rw-r--r-- 1 jidanni jidanni 3463 2010-12-02 07:05:06.0 +0800 ../../jidanni.org/location/zaokeng.kmz -rw-r--r-- 1 jidanni jidanni 3463 2010-12-02 07:05:06.298528658 +0800 /tmp/zaokeng.kmz as different times, when in fact they are the same... But of course sometimes for some people they aren't the same too I suppose... ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Bug#605639: deal better with different filesystem timestamp resolutions
X-Debbugs-cc: bug-coreut...@gnu.org, bug-make@gnu.org Package: coreutils Version: 8.5-1 man cp says: `-u' `--update' Do not copy a non-directory that has an existing destination with the same or newer modification time. If time stamps are being preserved, the comparison is to the source time stamp truncated to the resolutions of the destination file system and of the system calls used to update time stamps; this avoids duplicate work if several `cp -pu' commands are executed with the same source and destination. But it seems that isn't working too much/well, $ touch /tmp/f $ /bin/cp -avu /tmp/f . `/tmp/f' -> `./f' $ /bin/cp -avu /tmp/f . `/tmp/f' -> `./f' $ /bin/cp -avu /tmp/f . `/tmp/f' -> `./f' $ ls -l --full-time f /tmp/f -rw-r--r-- 1 jidanni jidanni 0 2010-12-02 08:25:47.682527260 +0800 /tmp/f -rw-r--r-- 1 jidanni jidanni 0 2010-12-02 08:25:47.0 +0800 f $ mount /dev/sda6 on /home type ext3 (rw) tmpfs on /tmp type tmpfs (rw) It might work great f -> /tmp/f, but not the other way around. By the way, make(1) lacks any of this time comparison resolution machinery at all! I'll CC them. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
discovered the need for a null rule
While trying out aliases, to make "make x.ccc" work, I discovered the need for a null rule: %.ccc:%.bbb; %.bbb:%.kml; some_command $? $@ which can also be written %.ccc:%.bbb #one TAB on next line: %.bbb:%.kml some_command $? $@ Of which, emacs will say Suspicious line 2. Save anyway? (y or n) OK. I learned a new thing today, use ";" or ";:" or "\t:" on that ccc line. Just an observation. $ apt-show-versions make make/unstable uptodate 3.81-8 ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Bug#561504: update make -n documentation on Debian
Ah, the fine print. And yes there are surely disclaimers that one must read the fine print. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Bug#569967: --touch --dry-run
> "MS" == Manoj Srivastava writes: MS> The docs already tell you that it is an error to use more than MS> one of the three options; and when you do so, you should expect MS> undefined behaviour. What you saw might not be the same with the next MS> upgrade, so it should definitely not be codified in the documentation. Let's just hope upstream makes errors raise errors. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Bug#569967: --touch --dry-run
X-debbugs-CC: bug-make@gnu.org Package: make Version: 3.81-7 Severity: wishlist On (info "(make) Instead of Execution") we see It is an error to use more than one of these three flags in the same invocation of `make'. Well, I got away with -nt. and the -n was ignored. So you should warn on the man page and info page, that -nt acts like -t. $ cat Makefile e: echo hello $ make -nt touch e $ make -nt make: `e' is up to date. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Bug#565791: the word 'Makefile' turns off -n safety cap
X-debbugs-cc: bug-make@gnu.org Package: make Version: 3.81-7 Nope, make -n is definitely busted. If it senses the word 'Makefile' here, if forgets that it is not supposed to execute anything, and even turns on execution for make -n b! $ cat Makefile h:b Makefile:b b: rm -f /boot/vmlinuz-2.6.32-trunk-686 $ ls Makefile h $ make -n rm -f /boot/vmlinuz-2.6.32-trunk-686 rm: cannot remove `/boot/vmlinuz-2.6.32-trunk-686': Permission denied make: *** [b] Error 1 $ make -n b rm -f /boot/vmlinuz-2.6.32-trunk-686 rm: cannot remove `/boot/vmlinuz-2.6.32-trunk-686': Permission denied make: *** [b] Error 1 Comment out Makefile and all is OK again. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Bug#561601: Explanations.gz dominated by trailing blanks
Package: make Version: 3.81-7 Severity: wishlist File: /usr/share/doc/make/Explanations.gz X-debbugs-cc: bug-make@gnu.org This file is composed of one third trailing blanks. $ zcat Explanations.gz |wc -c 9366 $ zcat Explanations.gz |perl -pwle 's/\s+$//'|wc -c $ expr 100 - \( \* 100 / 9366 \) 29 ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Bug#561504: update make -n documentation on Debian
Package: make Version: 3.81-7 Severity: wishlist X-debbugs-cc: bug-make@gnu.org Me again. Same problem as before with the documentation. `-n' `--just-print' `--dry-run' `--recon' "No-op". The activity is to print what commands would be used to make the targets up to date, but not actually execute them. $ make -n a mkdir -p /tmp/pots make -n guts > /tmp/pots/`date +%s` /bin/sh: /tmp/pots/1261073715: No such file or directory make: *** [a] Error 1 This proves that some things really do get executed... Which to me is just as dangerous as a Microsoft executable email to a Windows user... I will shoot my own foot executing things I wrote but didn't intend to execute, thinking make -n was as safe as sh -n. $ cat Makefile guts: export LC_ALL=zh_TW.UTF-8 &&\ ./mec|xargs --verbose --no-run-if-empty w3m -no-cookie -cols 111 -dump a: mkdir -p /tmp/pots $(MAKE) $(MFLAGS) guts > /tmp/pots/`date +%s` ls -og /tmp/pots Hope the documentation gets fixed on Debian at least. $ stat /usr/share/doc/make/changelog.gz|grep Mod Modify: 2006-04-11 06:03:46.0 +0800 Seems Debian is stuck with four year old make. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: .SECONDARY vs. .PRECIOUS doc of danger
PG> In contrast, the description of .SECONDARY only mentions targets and PG> not target patterns. Please add warnings about this, otherwise "we new car buyers looking for the benefits of .PRECIOUS without the pitfalls of interrupts" will "fall for it" every time. I mean "the car salesman" in the Info page boasts of the benefits of .SECONDARY, but one doesn't know the hidden disadvantages (no %!) unless one has a Ph.D. in fine print or something. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
.SECONDARY vs. .PRECIOUS doc of danger
You fellows have a lot of explaining to do. (On the Info page, not to me.) In (info "(make) Special Targets") `.PRECIOUS' ...Also, if the target is an intermediate file, it will not be deleted after it is no longer needed, as is normally done... In this latter respect it overlaps with the `.SECONDARY' special target. However we see that only genuine .PRECIOUS will preserve the intermediate file. .SECONDARY, on the other hand, will blow - it - away. $ ls Makefile u.kml $ cat Makefile .SECONDARY:%.kmz %.kmz:%.kml;touch $@ %.val:%.kmz; $ make u.val touch u.kmz rm u.kmz $ emacs Makefile $ cat Makefile .PRECIOUS:%.kmz %.kmz:%.kml;touch $@ %.val:%.kmz; $ make u.val touch u.kmz ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: make --guaranteed-real-dry-run
So was this ever resolved? Did anything get into the documentation? Thanks. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: make --guaranteed-real-dry-run
MD> "Don't actually run normal recipes; just print them." Well OK. A hint in the air that something is up the sleeve is better than nothing. P.S. here on Debian sid $ man make|egrep 19\|Manual|tr -s ' '|tac GNU 22 August 1989 MAKE(1) Copyright (C) 1992, 1993, 1996, 1999 Free Software Foundation, Inc. This file is part of GNU make. See the chapter `Problems and Bugs' in The GNU Make Manual. The GNU Make Manual $ make --version GNU Make 3.81 ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: make --guaranteed-real-dry-run
PG> The GNU make manpage starts with this: PG> WARNING OK, but not make --help. Anyway please change things like -n, --just-print, --dry-run, --recon Don't actually run any commands; just print them. To Don't actually run any commands usually; just print them. The exact wording I leave up to you. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: make --guaranteed-real-dry-run
What really bugs me is we do "man make", and see -n, --just-print, --dry-run, --recon Print the commands that would be executed, but do not execute them. But that is just plain not always true, and one has to read the fine print in other documents to find the whole story. So throughout the years we use make -n, until one day something blows up in our face. What I'm saying is that things like that at least need a asterisk and a footnote, else, well, how can you say with a clear conscience "we warned you"? Yes down on the bottom is says for the full story see the info pages, but that's not how warning labels are done. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
make --guaranteed-real-dry-run
In the documentation everywhere you mention -n, --just-print, --dry-run, --recon Print the commands that would be executed, but do not execute them. You should also say: Well, that is not exactly the truth, in some cases a even non-malicious programmer can construct a makefile that will still execute commands. In fact it is quite common and intentional... The same goes for -t... See (info "(make)MAKE Variable") (info "(make)Options/Recursion"). At least add one word that one still can get wet. Also please document how one can achieve a --guaranteed-real-dry-run. Furthermore, one notes in the make --dry-run output that there is no way to distinguish the lines that were really run from those that weren't. Only when one sees e.g., "/bin/sh: curl-config: command not found" does one notice something sneaky is happening. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: % vs. "No rule to make target"
PS> what does this information do for you? I don't know, all I am thinking is hooks (i.e., differing error messages that can be post processed by:) for a future hand holding system so one can "ask what went wrong?" And have super basic tutorial information given... (target implementation date 2050, implementor: some fellow like the one who wrote the Bash Advanced guide or Emacs Lisp big manual.) (Just make slightly differing messages if they can be made today without rearranging the program just for this.) > I guess what you're suggesting is something like: I don't know, it's all over my head anyway. OK, thanks. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: % vs. "No rule to make target"
Do differentiate error messages from different triggers, all in preparation for a perl-like See perldiag for explanations of all Perl's diagnostics. The "use diagnostics" pragma automatically turns Perl's normally terse warnings and errors into these longer forms. hand holding facility for make, ten+ years down the road. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: % vs. "No rule to make target"
PS> I don't understand the distinction you're making here between "no rule PS> at all" and "no best rule" (what's a "best rule"?), and just "no rule". Maybe whatever prints messages prefixed by make: *** No rule to make target is called from several different points in the code, and could give finer grained messages, all still on one line. Maybe there is a difference between "no rule at all" and "yes, a few rules, but no best one". Like, "no wires at all found" and "yes found some wires, but none that could complete the circut" and "several paths to complete the circut, but no best path, so giving up". Er, if still I'm getting nowhere, then you can drop this bug report. Sorry. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: % vs. "No rule to make target"
OK, OK, is perhaps this message, make: *** No rule to make target `z', needed by `a'. Stop. is actually triggered by several different conditions, and could instead be refashioned into several more exact messages, e.g., no rule at all, no best rule, etc. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
% vs. "No rule to make target"
All is well: $ cat Makefile all:z.bak %.bak:; $ make make: Nothing to be done for `all'. Until we add a %: $ cat Makefile all:z.bak %.bak:%; $ make make: *** No rule to make target `z.bak', needed by `all'. Stop. Suddenly it can't find the rule anymore. Or prints the wrong message. Indeed, instead of % use %.bak:some_file_that_exists; No problem. But %.bak:some_file_that_does_not_exist; then make says it can't find the rule to make target z.bak, when it should say it can't find the rule to make target some_file_that_does_not_exist, which it does when one uses z.bak:some_file_that_does_not_exist; Maybe the story lies on Info page "10.8 Implicit Rule Search Algorithm" and maybe -d showing "Avoiding implicit rule recursion." is a clue. Anyway, I'm not one of the 0.1% of the population to be able to comprehend all these things. GNU Make 3.81 ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
link to New-Fashioned Suffix Rules in Info
Info says 10.7 Old-Fashioned Suffix Rules === "Suffix rules" are the old-fashioned way of defining implicit rules for `make'. Suffix rules are obsolete because pattern rules are more general and clearer. OK, at this point give a linking footnote to where the new method lies. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
tell them how to break assignments long lines
Your Make Info document does not tell the user how to break his variable assignments without tears. So mention it explicitly right upon the relevant page. $ make this is long line 1 that I would li ke to break this is long line 2 that I would like to break $ cat makefile A=this is long line 1 that I would li\ ke to break B=this is long line 2 that I would li$(\ )ke to break g: @echo $A @echo $B ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: mention how to quote a comma in "call"
OK, but near >> reverse = $(2) $(1) do add a forward reference to SR>Commas and unmatched parentheses or braces cannot appear in the text because the latter section is so far away. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
mention how to quote a comma in "call"
Your
reverse = $(2) $(1)
example in the manual is great, however if one day your users happen
to want to quote a comma,
OK:;echo $(call reverse,a,b)
SORRY1:;echo $(call reverse,a\,b,c)
SORRY2:;echo $(call reverse,"a,b",c)
then they are S.O.L. unless you mention how.
One apparently needs to do
EE=a,b
OK2:;echo $(call reverse,$(EE),c)
Mention that it is the only(?) way.
Wait,
OK3:;s=,;echo $(call reverse,a$${s}b,c)
___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make
