In make 3.80, the code to emit warnings about undefined variables
(with --warn-undefined-variables) has moved from expand.c (I think)
to variable.h - but variable.h has not been added to po/POTFILES.in.
This means that those warnings do not get properly internationalized.
--
Henning Makholm
for a semicolon in the expanded line" comment).
Instead make thinks that the ";" is supposed to be the pattern part of
a static pattern rule, and produces the above error message.
--
Henning Makholm "Slip den panserraket og læg
the dependency list. Back when expansion wasn't supposed to have side
effects this must have been a sound optimization.
--
Henning Makholm"De kan rejse hid og did i verden nok så flot
Og er helt fortrolig med alverdens militær"
___
isn't being kept up-to-date. (If somebody cares enough about
manpages to do the work, they'll probably contribute a patch for
make.1).
--
Henning Makholm"Nej, hvor er vi altså heldige! Længe
(not a GNU make d
be better documented. I
needed it, and did not find it when I searched for "version" in the
manual's index or followed crossreferences from node "Values".
A patch that does this is attached.
--
Henning Makholm
hat it works, but contains minor bugs that happen to kill our
# particular use of it.
else
# Here I am sure that we're on something older than 3.84.
end
--
Henning Makholm "Nemo enim fere saltat sobrius, nisi forte insanit."
___
Bug-make mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-make
make the single-makefile paradigm work
with it:
<http://www.gnu.org/manual/automake-1.6.1/html_node/automake_23.html>
--
Henning Makholm"Nej, hvor er vi altså heldige! Længe
(not a GNU make developer)l
EFILE_LIST
but that is hardly an elegant solution.
--
Henning Makholm"Okay, okay, life's a beach."
___
Bug-make mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-make
Scripsit "Paul D. Smith" <[EMAIL PROTECTED]>
> %% Henning Makholm <[EMAIL PROTECTED]> writes:
> hm> Here is why I need it: I use a compiler, `mosmlc', that reads a
> hm> `*.sml' source file and write a `*.uo' file with object code and a
&
mands
have made all the targets up-to-date.
Such a principle may be too arcane and adhockish to admit of
understandable documentation, however.
--
Henning Makholm"What a hideous colour khaki is."
___
Bug-make mailin
atch that adds an
explicit syntax for non-pattern many-targets-at-once rules have a
chance of being considered?
--
Henning Makholm "Jeg har tydeligt gjort opmærksom på, at man ved at
følge den vej kun bliver gennemsnitligt ca. 48 år gammel,
og at m
rule, because someone, somewhere, is sure to
have a Makefile that depend on getting the rule punctuation from
variables - and they would have a right to expect it to work, because
all other make implementation I know works that way.
[Disclaimer: I am not a GNU make developer, much less the main
te to the configure scripts. But in such
an environment even the vanilla autoconf tests will have trouble.
--
Henning Makholm "First chapter, the plot advances,
second chapter, Ayla makes a discovery that
sig
t scripts are gone. Not that I complain,
just mentioning it as a data point for Soren (Søren?).
--
Henning Makholm "You propose to avoid dying? I will be
interested to hear the method you plan for this endeavour."
_
use the exact form of the
> >dependency that's used in the dependency list, it's easy to simply
> >reproduce that form, replacing the % by $*
> Sorry, I do not understand what you mean.
It wasn't right anyway. I remembered the semantics of $* when the fil
8, 99, 2000
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.
Report bugs to <[EMAIL PROTECTED]>.
pc-043:~/foo$
--
Henning Makholm&qu
gh real directories without encountering any symbolic links.
> Absolutely anything else is open to misinterpretation.
Assuming anything for $< (and similar variables) but that they unfold
to SOME name that references the file in question, is open to
misinterpretation and leads to unportable ma
nable
for $< to unfold to the *canonical* name of the file in question, I
think.
If one absolutely wants the command to use the exact form of the
dependency that's used in the dependency list, it's easy to simply
reproduce that form, replacing the % by $*
--
He
file 'Makefile_rm' again.
Why? If you want to learn how to use cvs properly, contact a cvs
support forum. This is a mailing list for reporting bugs in GNU make,
and as I've already explained, the make behavior you describe is
entirely proper and according to the documentation (a
cvs export -r $(TAG) $(MODULE)/src/$(*F).cpp
> touch $@
By the way, this looks like a really roundabout way of doing something
that could be accomplished just by saying
all : cvs_update TlWsPPFend TlWsPPDaemon
.PHONY: cvs_update
cvs_update:
cvs update
ile. Or it may be a problem with your environment
or your modifications.
Would you complain to the maker of your can opener if a can of peeled
tomatoes turned out to be rotten inside?
--
Henning Makholm "We can build reactors, we can melt
operating system? Did you compile make yourself? Are you
really sure the file does exist - can you get a C program of your
own to stat(2) it? Etc.
If you run Linux, try to strace(1) the make process and check
whether the filename gets mangled internally, or some weird
chdir takes place.
--
Hen
really check the target's mtime again. Otherwise, assume the target
would have been updated. */
- if (question_flag || just_print_flag)
+ if (question_flag || just_print_flag || touch_flag)
{
for (i = file->cmds->ncommand_line
vertheless)?
Make used *unsigned* UTC times for internal comparison, so if your
localtime 1970-01-01 00:00:00 (the timestamps get converted to
localtime when printed into the warning string) is really, say,
1969-12-31 23:00:00 UTC, make will compare it as some date far into
the futur
r command name to use in that situation is "gmake"
(used, e.g., by {open,net,free}BSD who also ship BSD make). Another
is "Gmake".
In summary: "gmake" and "Gmake" are probably the same thing, though
they may be different versions. Ask your *local* system
dependencies, the command only gets run
if there is no file named driver. And remember that in un*x, a
directory is a file! Hence no reason to run the rule.
Solution: Read the node "Phony Targets" in the GNU make manual,
and add
.PHONY: driver
to your Makefile. Then mak
ter, except that
on certain non-un*x operating systems it attempts to emulate the
un*x-shell behavior.
--
Henning Makholm"I ... I have to return some videos."
___
Bug-make mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-make
s not a bug in make but
perfectly standard getopt behavior. If "j" is not the last character
in an argument string, the entire rest of the argument is supposed
to be the value - and " 1" is not a valid syntax for an integer.
What needs to be fixed is either the application tha
t and patch
from last Friday wasn't acknowledged either ;-)
--
Henning Makholm "Vend dig ikke om! Det er et meget ubehageligt syn!"
___
Bug-make mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-make
Scripsit "Paul D. Smith" <[EMAIL PROTECTED]>
> %% Henning Makholm <[EMAIL PROTECTED]> writes:
> hm> By the way, it is not *every* make that behaves this way. At least
> hm> /usr/ccs/bin/make on SunOS 5.7 doesn't.
> Yes it does.
Mea culpa -
Scripsit "Paul D. Smith" <[EMAIL PROTECTED]>
> %% Henning Makholm <[EMAIL PROTECTED]> writes:
> hm> Hm (checks it..) it works. Amazing. Where should I have looked for
> hm> that behavior in the documentation?
> However, (a) every make has always beha
patch for it,
what would be the chances of having incorporated in the official make
release? I know that the FSF wants legal papers signed, and I assume
that make must be compilable by pre-ANSI C compilers, but which other
pitfalls are there to avoid?
--
Henning Makholm
32 matches
Mail list logo
