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
$ 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
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
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.
___
> "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
> "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
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?
$ 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/st
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.
__
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
(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 no
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/list
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
> "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 em
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 sub
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
(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=$@
-
(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
> "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
> "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 wo
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
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
G
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 th
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:$(subs
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..."
> "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.
ed, 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.k
7;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 +
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 a
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
> "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
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
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
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 / 93
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 actua
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 I
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 wi
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
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,
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 leav
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 t
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-malicio
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
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
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
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.
___
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 mess
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
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
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/mail
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
51 matches
Mail list logo
