On Wed, 2013-05-01 at 00:59 +0200, Stefano Lattarini wrote:
# With make 3.82, compiled from official tarball:
$ make -f- 'all:; @echo $(MFLAGS)' -I none
-I none
# With development version of make:
$ make -f- 'all:; @echo $(MFLAGS)' -I none
-Inone
I think MFLAGS is
On Tue, 2013-04-30 at 10:39 -0400, Paul Smith wrote:
On Tue, 2013-04-30 at 16:04 +0200, Stefano Lattarini wrote:
On 04/30/2013 03:37 PM, Paul Smith wrote:
Just to be clear, you're saying that the testsuite runs as one long
operation, updating one target, and the recipe invokes one test
On Wed, 2013-05-01 at 18:26 +0300, Eli Zaretskii wrote:
You forgot to make the same change in the WINDOWS32 branch. I did
that in commit a87ff20.
Sorry, I missed that.
This should be fixed now. Those who use recursive makefiles and were
seeing annoying delays in output with -O, please
On Wed, 2013-05-01 at 22:08 +0300, Eli Zaretskii wrote:
Yes. But I thought the change was about -Otarget, not -Ojob. Stefano
was complaining about a plain -O, so -Ojob is not what was his
problem.
Yes, it is about -Otarget. As I said, I added -Ojob output just for
completeness. The
On Tue, 2013-04-30 at 11:19 +0200, Stefano Lattarini wrote:
The above has been obtained with GNU make built from latest
git version (commit 'moved-to-git-46-g19a69ba').
Yes. I know the email lately has been daunting but if you wade through
it you'll see a number of emails discussing this
Just to be clear, you're saying that the testsuite runs as one long
operation, updating one target, and the recipe invokes one test script,
right? I can see how that environment might be problematic for this new
feature. It works much better for lots of smaller targets.
However, you could avoid
On Tue, 2013-04-30 at 16:04 +0200, Stefano Lattarini wrote:
On 04/30/2013 03:37 PM, Paul Smith wrote:
Just to be clear, you're saying that the testsuite runs as one long
operation, updating one target, and the recipe invokes one test script,
right?
No; the testsuite runs as a recursive
On Tue, 2013-04-30 at 17:48 +0100, Tim Murphy wrote:
i.e. I don't just have
load X.dll
I have to supply the recipe to build it on windows:
X.dll:
cl.exe /Fdo$@ # use microsoft's compiler
and on Linux
X.so:
gcc -o $@ ... # using gcc
Actually this supports Eli's point
On Mon, 2013-04-29 at 19:30 +0100, Tim Murphy wrote:
I must clarify - I think that make should provide plugins with an
allocation mechanism. Not the other way around.
It's probably a good idea for make to provide a gmk_free() function
that will free memory returned to the plugin when it calls
On Mon, 2013-04-29 at 22:34 +0300, Eli Zaretskii wrote:
Yes, that should be possible. My concern is that, at least on UNIX, the
rules for this are complex and I don't want to reimplement the runtime
linker :-). Maybe something like, first try the path as given and if
that fails, try
On Mon, 2013-04-29 at 17:00 -0400, David Boyce wrote:
On Mon, Apr 29, 2013 at 4:34 PM, Paul Smith psm...@gnu.org wrote:
Plus on UNIX any extension is acceptable since we're using dlopen()
(even with the normal linker you can give any library name you want,
it's only the -l flag that makes
On Fri, 2013-04-12 at 13:41 +0200, Reinier Post wrote:
Hmm, indeed:
| /tmp % cat Makefile
| %.1:; echo $*.1 for $@ $@
| %.e.1 %.f.1:; echo $*.1 for $@ $@
| %.c.1 %.d.1:; for f in $*.c.1 $*.d.1; do echo $$f for $@ $$f; done
| %.ab.2: %.a.1 %.b.1; cat $+ $@
| %.cd.2: %.c.1 %.d.1; cat $+
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
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
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
On Sun, 2013-04-28 at 20:00 +0300, Eli Zaretskii wrote:
I've pushed a change to add a new argument to the -O/--output-sync
option, job, to write output after each line of the recipe.
What is its purpose? To avoid mixing in the same screen line
characters from several parallel sub-makes?
On Thu, 2013-04-18 at 22:36 +0200, Frank Heckenbach wrote:
% make -Omake # same with -Otarget
m:2: recipe for target 'foo' failed
make: *** [foo] Error 1
foo:error
This seems at least strange to me: The conclusion recipe failed is
printed before the reason (the messages from the job).
Now that we seem to have a workable solution for output synchronization
for both POSIX and Windows systems, I wonder if we shouldn't consider
enabling it as the default mode when parallel builds are running.
I understand that this will be a change that could be visible (beyond
the collection of
On Sat, 2013-04-27 at 13:09 +0300, Eli Zaretskii wrote:
Is this intended behavior that these two messages:
mkfsync:6: recipe for target 'two' failed
gnumake[1]: [two] Error 1 (ignored)
are separated and wrapped by separate Entering...Leaving blocks,
instead of being produced together?
On Sat, 2013-04-27 at 14:39 +0300, Eli Zaretskii wrote:
The changes needed to make -O work on MS-Windows are now committed to
the master repository, see commits da7df54 and 049f8e8. Please review
and comment.
Thanks Eli!!
I'll take a look over the next few days.
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
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
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
On Thu, 2013-04-18 at 22:36 +0200, Frank Heckenbach wrote:
This is useful (to me) because at any time, I know what's running.
([Start] messages minus [End] messages.)
Thanks, this is the reason I was looking for; that use-case wasn't clear
to me based on the previous email.
OK, so
On Thu, 2013-04-25 at 07:14 +0100, Tim Murphy wrote:
To be honest, I have done all this before with named semaphores
including the file that gets left over problem and it's all solvable
quite nicely. You pass the build id in the environment which is,
after all, what it's for.
Sure. Given
On Wed, 2013-04-24 at 21:17 +0300, Eli Zaretskii wrote:
There's one issue that perhaps needs discussing. A mutex is
identified by a handle, which on Windows is actually a pointer to an
opaque object (maintained by the kernel). As such, using just 'int'
for sync_handle is not wide enough,
I'm fully prepared to accept the blame for not doing the best job
getting buy-in etc. on this effort. Can we leave the discussion on the
process behind? I'd prefer that, unless there are real constructive
comments on how to do better next time rather than rehashing what was
done wrong. I think
On Wed, 2013-04-24 at 22:25 +0300, Eli Zaretskii wrote:
From: Paul Smith psm...@gnu.org
Cc: e...@gnu.org, bug-make@gnu.org
Date: Wed, 24 Apr 2013 15:07:21 -0400
I'm not so sure fstat() is that cheap. struct stat contains a lot of
information. Although I guess since we are only ever
On Wed, 2013-04-24 at 22:39 +0300, Eli Zaretskii wrote:
Nothing is actually read by lseek (and even if it were, it would
only need to look at the first and last part of the file, not read
all the content, if that was the worry).
Are you sure? How can lseek jump to the last byte of the
On Wed, 2013-04-24 at 22:55 +0100, Tim Murphy wrote:
why not use a named semaphore wherever possible (windows and linux)
and lock a file where not instead of trying to pass kernel object
handles around (seems a bit nasty to me)?
Hi Tim; I think you're late to the party :-). Let me summarize a
On Tue, 2013-04-23 at 21:40 +0300, Eli Zaretskii wrote:
Date: Tue, 23 Apr 2013 11:29:35 -0700
From: David Boyce david.s.bo...@gmail.com
Cc: Frank Heckenbach f.heckenb...@fh-soft.de, bug-make bug-make@gnu.org
Since you asked basic questions I'm going to start this at a basic level.
On Tue, 2013-04-23 at 23:16 +0300, Eli Zaretskii wrote:
All it requires is inheriting the redirected stdout/stderr to child
processes. This was already possible under Dos (with the exception
that since there was no fork, you had to redirect in the parent
process, call the child, then
On Fri, 2013-04-19 at 14:09 +0300, Eli Zaretskii wrote:
Date: Fri, 19 Apr 2013 11:54:05 +0200
Cc: bo...@kolpackov.net, bug-make@gnu.org
From: Frank Heckenbach f.heckenb...@fh-soft.de
Is there a simple enough Makefile somewhere that could be used to test
this feature, once
On Fri, 2013-04-19 at 12:36 +0300, Eli Zaretskii wrote:
Also, where is the best place to put the emulated Posix functions?
Some new file in w32/compat/?
I'd like to see it there. I'm thinking I want to move the new stuff out
of job.c even for POSIX systems. The ifdefs are really getting to
On Sat, 2013-04-20 at 13:50 +0300, Eli Zaretskii wrote:
Do we really need to require 0.18.1 or can this restriction be lifted?
I hacked configure.ac to require 0.17, and didn't see any problems
afterwards.
You can see this bug:
http://savannah.gnu.org/bugs/?37307
I confess I didn't get a
On Fri, 2013-04-19 at 18:07 -0600, David Sankel wrote:
In section 7.3 and 8.2 the function 'findstring' is recommended as a
means to search a space separated list for a given value. This
suggestion is problematic as findstring really searches for
substrings. So, for example $(findstring
On Sat, 2013-04-20 at 19:38 +0300, Eli Zaretskii wrote:
From: Paul Smith p...@mad-scientist.net
Cc: bug-make@gnu.org
Date: Sat, 20 Apr 2013 11:44:02 -0400
On Sat, 2013-04-20 at 13:50 +0300, Eli Zaretskii wrote:
Do we really need to require 0.18.1 or can this restriction be lifted
On Thu, 2013-04-18 at 19:09 +0200, Frank Heckenbach wrote:
This mechanism was unaffected by my output-sync patch, and I
expected your change broke it.
I was reading your email with interest, waiting for the punch-line, but
then after all that description you just said that the change broke it,
On Thu, 2013-04-18 at 20:36 +0200, Frank Heckenbach wrote:
And with my progress mechanism, that's exactly what I want. In my
case it'd look like this:
[Start] Compiling foo.c
[Start] Compiling bar.c
# time passes
foo.c: some error
# time passes
bar.c: some error
# time passes
[End]
On Wed, 2013-04-17 at 19:10 +0300, Eli Zaretskii wrote:
That could be a misunderstanding on my part: I didn't realize that by
handle you mean a FILE object. I thought you meant Windows specific
HANDLE objects (which underly every open file).
I'm not very familiar with Windows terminology. Is
On Wed, 2013-04-17 at 23:00 +0300, Eli Zaretskii wrote:
I'd be surprised if this were a real problem nowadays. E.g., the
Windows C runtime is documented to allow up to 512 FILE streams, which
can be enlarged to 2048 by calling a function. The max number of file
descriptors is also 2048.
GNU
On Tue, 2013-04-16 at 11:30 +0300, Eli Zaretskii wrote:
Date: Tue, 16 Apr 2013 05:54:13 +
From: Paul D. Smith invalid.nore...@gnu.org
I did a little bit of code rearrangement, but I still think this code will
not
work on Windows and might possibly not compile on Windows.
On Tue, 2013-04-16 at 01:34 -0700, Jim Michaels wrote:
I have been toying with this idea of parallel builds to gain project
compile speed (reducing time to a fraction) for quite a while.
Can you explain the difference between what you're suggesting and the
existing --jobs (-j) feature available
On Tue, 2013-04-16 at 09:57 +0100, Tim Murphy wrote:
What would be super cool is being able to get make to expand some sort
of variable at the start and another one at the end of the output so
that there was a way to see where one rule ended and the next one
began.
Well, the new feature adds
On Tue, 2013-04-16 at 13:40 +0100, Ray Donnelly wrote:
Pretty simple, needs little explanation.
Maybe not but a patch would be nice :-) :-p
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
On Tue, 2013-04-16 at 09:57 +0100, Tim Murphy wrote:
When most rules are a single job this doesn't seem important but when
you're doing anything non trivial it becomes hard to see what is
where.
Just to be clear: in this implementation the output from all individual
commands in a recipe are
On Tue, 2013-04-16 at 16:43 +0300, Eli Zaretskii wrote:
I'm not sure what the semantics of tmpfile() are on Windows.
The file is automatically deleted when closed. But the documentation
doesn't say what happens if it is open on more than one descriptor, or
what happens if the original
On Tue, 2013-04-16 at 15:31 +0100, Tim Murphy wrote:
So this is great and you can see that there are 4 targets in my
makefile and that each one is a start X followed by an end X. I
don't see any enter/exit delimitation - have I missed out some option?
Um. Yes, the enter/leave only happens
On Tue, 2013-04-16 at 19:20 +0300, Eli Zaretskii wrote:
From: Paul Smith psm...@gnu.org
Cc: bo...@kolpackov.net, bug-make@gnu.org, f.heckenb...@fh-soft.de
Date: Tue, 16 Apr 2013 10:44:39 -0400
On Tue, 2013-04-16 at 16:43 +0300, Eli Zaretskii wrote:
I'm not sure what the semantics
On Thu, 2013-04-11 at 12:14 +0200, Reinier Post wrote:
It's just a shorthand for writing a lot of identical rules; it does NOT
mean that a single invocation if the rule will generate all three
targets, which is what you are expecting.
Incidentally: other workflow/inference languages can
On Wed, 2013-04-10 at 18:18 +0200, Vincent de Phily wrote:
SHELL := /bin/bash
date := $(shell date -R)
prevtag := $(shell git describe --tags|cut -d- -f1)
This is not good: what if your tag contains a - in it?
I think you want: $(shell git describe --tags --abbrev=0)
release:
#
On Wed, 2013-04-10 at 19:56 +0200, Vincent de Phily wrote:
On Wednesday 10 April 2013 13:28:38 Paul Smith wrote:
On Wed, 2013-04-10 at 18:18 +0200, Vincent de Phily wrote:
If the behaviour is expected (why ?), it would be usefull to explain the
difference between `command` and $(shell
On Wed, 2013-04-03 at 21:24 -0500, Roger Pepitone wrote:
TEST_TEXTS := test1.txt test2.txt test3.txt
$(TEST_TEXTS) : xtest.txt
echo Rebuilding $@
touch $(TEST_TEXTS)
xtest: $(TEST_TEXTS)
On Mon, 2013-04-01 at 12:56 -0400, Andriy Sen wrote:
I have found inconsistent behavior of make in regard to chain of implicit
rules with multiple targets.
For example lets suppose we have a rule that generated multiple c++ files:
%1.cpp %2.cpp: %.ext
[command]
The c++ files are
On Fri, 2013-03-29 at 19:20 +0800, jida...@jidanni.org wrote:
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.
We've
On Wed, 2013-02-27 at 12:47 -0700, Brian Vandenberg wrote:
What it doesn't make clear is, if it's configured with 'nointr' will
that just cause the system function to block? That seems the most
plausible.
Correct. With nointr, you won't be able to (for example) ^C a program
that is hung
On Sat, 2013-02-23 at 17:28 +, Ian Lynagh wrote:
On Sat, Feb 23, 2013 at 06:57:27AM +0200, Shachar Shemesh wrote:
What I'm also interested in is why .SECONDARY made everything slow.
I've put a cut-down makefile demonstrating this here:
http://urchin.earth.li/~ian/tmp/Makefile
I
On Sat, 2013-02-23 at 21:02 +, Ian Lynagh wrote:
On Sat, Feb 23, 2013 at 03:45:59PM -0500, Paul Smith wrote:
I've never really been clear on the purpose and use of .SECONDARY; the
comments in both the GNU make manual and in the code seem odd to me. I
would really appreciate anyone
On Sat, 2013-02-23 at 02:32 +, Ian Lynagh wrote:
The problem was that our compiler generates 2 output files (foo.o and
foo.hi) when compiling one source file, and we had thus ended up with
a bunch of rules like
%.hi: %.o ;
The right way to declare a rule that generates multiple
On Tue, 2013-01-29 at 14:42 +0100, Liang, Jian wrote:
Make cannot handle the word or path that contains space.
You're right. The syntax of makefiles precludes this, and no version of
make supports it.
https://savannah.gnu.org/bugs/?712
___
On Sun, 2013-01-06 at 19:04 +0100, Stefano Lattarini wrote:
Here is the error:
make[2]: Entering directory `/devel/bleeding/src/make/po'
make[2]: `be.gmo' is up to date.
make[3]: Entering directory `/devel/bleeding/src/make/po'
File cs.po does not exist. If you are a translator, you
On Fri, 2012-12-14 at 17:07 +0200, Eli Zaretskii wrote:
Does it even make sense to use -j with no arguments? Should we
perhaps remove that possibility, or have some internal sane limit,
like twice the number of cores, say?
In general I'd say no, the current behavior is not ideal. However I
On Thu, 2012-12-06 at 14:12 -0800, Chris Penev wrote:
I would expect there to be no difference between the two hashes.
That expectation would not be correct, clearly :-). Make has its own
escaping and expanding procedures that it follows, in addition to /
aside from what the shell does.
If
On Wed, 2012-11-07 at 12:33 +0100, Daniel Borkmann wrote:
Hi together,
I have make 3.81 on a Debian stable machine. I tried out the example
from the eval function given in
http://www.gnu.org/software/make/manual/make.html#Eval-Function . The
example *only* works for me if I remove the
On Sat, 2012-10-27 at 01:22 +0900, Namhyung Kim wrote:
* doc/make.texi: Fix a typo
Thanks; this fix is already present in the current latest version of the
document.
___
Bug-make mailing list
Bug-make@gnu.org
On Sun, 2012-10-14 at 15:08 +0200, Sebastian Pipping wrote:
On 10/13/2012 05:09 PM, Eric Seerden wrote:
I'm trying to get in contact with Paul D. Smith who worked with rms on
the GNU make (gmake) utility apparently he is now the maintainer of
the software..
Since you have the attention
On Mon, 2012-07-23 at 11:59 -0700, icegood wrote:
.PHONEY: all
all:
if [ \( $$(ls *.lock 2/dev/null) == \) ]; then \
touch $@.lock; \
if [ \( ! -e $@ \) -o \( ../$(tag_fn) -nt $@ \) ]; then \
echo $@ done; \
else \
touch $@; \
fi; \
rm -f $@.lock;
On Thu, 2012-07-19 at 13:32 -0400, David Boyce wrote:
I think it would be a good thing
if older manuals could be kept online, e.g. by adding a version level:
http://www.gnu.org/software/make/manual/3.81/make.html
http://www.gnu.org/software/make/manual/3.82/make.html
No, I'm not offering
On Fri, 2012-07-06 at 22:36 +0200, Reinier Post wrote:
On Fri, Jul 06, 2012 at 03:19:11PM +, Jason Merrill wrote:
[...]
I note that patch #5108 seems to create a single global mutex, whereas the
documentation for the SCO .MUTEX target suggests that each occurrence of
.MUTEX creates
On Fri, 2012-07-06 at 16:59 -0400, Paul Smith wrote:
export _MASTERPID ?= $(shell echo $$PPID)
MASTERPID := $(_MASTERPID)
LOCKFILE := /tmp/linklock.$(MASTERPID)
Bleah, that won't work right.
It'll have to be something like:
ifeq ($(MASTERPID),)
export
On Thu, 2012-06-21 at 10:52 +0400, Yakunin Vladimir wrote:
Not shure that this is bug, but this behavior looks strange. Couldn`t
find anything about it, so write here.
This isn't a bug; check out the section in the GNU make manual titled
How Makefiles Are Remade. That will explain what's going
On Mon, 2012-06-11 at 18:40 +0200, Stefano Lattarini wrote:
The GNU make 3.82 manual reads:
Normally, this is exactly what you want: if a target's prerequisite
is updated, then the target should also be updated.
Occasionally, however, you have a situation where you want to
On Mon, 2012-05-14 at 00:14 +0200, Stefano Lattarini wrote:
LAZYVAR = $(override LAZYVAR := val)$(LAZY)
I don't have any idea what this is supposed to do... it doesn't make any
sense as written.
In fact, it should have been s/$(LAZY)/$(LAZYVAR)/. Sorry for the confusion.
It
On Sat, 2012-05-12 at 19:42 +0200, Stefano Lattarini wrote:
BTW: to make it more easy to discover at make runtime whether the bug has
been fixed in the make version in use, could a proper new entry be added
to .FEATURES? Maybe 'can-have-lazy-variables'? (I know, I suck at choosing
names).
On Sat, 2012-05-12 at 00:04 +0530, Samkit Jain wrote:
I have been breaking my head over a simple thing of measuring the
progress of build
It's simple to say, but it's not simple to know. The structure of make
and how it performs builds means that it's not possible to know this.
make simply
On Mon, 2012-05-07 at 11:45 -0700, Nitin A Kamble wrote:
The attached patch fixes build of make with automake.
Thanks for your interest in GNU make. Note that GNU make 3.81 was
released in 2006 and we are no longer creating patches for that release.
The AM_C_PROTOTYPE option was already
On Thu, 2012-04-26 at 00:19 +, Christophe Poncy wrote:
I have a have a bug during the compile phase of my Funtoo GNU/Linux
box. I was trying to emerge the 'boot-update' package, it seems there
is a problem for compiling one of its dependency (lzo ).
[...]
Compiling source in
On Wed, 2012-04-18 at 10:35 +0800, jida...@jidanni.org wrote:
m;groups.html;w3m -cols=999 -dump $?
g:g.xq; basex $?
Please remember to always include the version of GNU make you are using.
In the current release (GNU make 3.82), I get:
Makefile:1: *** missing separator. Stop.
--
On Fri, 2012-04-06 at 22:35 +0300, Eli Zaretskii wrote:
Date: Fri, 6 Apr 2012 13:30:31 -0400
From: David Boyce david.s.bo...@gmail.com
Cc: tnmur...@gmail.com, bug-make@gnu.org
Sorry, I've never used libltdl. Maybe it would have been better just
to say libraries exist to paper over the
On Thu, 2012-04-05 at 18:27 -0400, David Boyce wrote:
A few years ago I suggested a plugin architecture much like this (but
I didn't supply a patch - crucial difference), to allow a plugin to
make the up-to-date determination, replacing the hardwired timestamp
system. [...] Any idea how hard
On Thu, 2012-04-05 at 23:59 +0100, Tim Murphy wrote:
I see the value in a plugin system as being that I don't have to
recompile the plugins for every version of make. In a way it's tending
towards why bother if you did have to do that.
Well, this kind of combines with my other issue regarding
On Mon, 2012-04-02 at 23:13 -0400, Brown, Ruben wrote:
Is this behavior by design or an unfortunately long lived bug? If it
is by design, what purpose does maintaining this behavior serve?
***Makefile***
.PHONY: all A B
all: A
VAR := 0
A: B
A: VAR:= 1
B:
@echo VAR=$(VAR) @ B
A:
On Tue, 2012-04-03 at 16:20 -0600, Teng wrote:
Excuse me. I have a question about Section 3.7 of the GNU Make Manual
Version 3.81 whose title is How Makefiles Are Remade. It said
After reading in all mkefiles, make will consider each as a goal target
and attempt to update it. But according to
On Fri, 2012-03-09 at 18:17 +0100, Sebastian Pipping wrote:
on page [1] it reads:
CFLAGS should be used in every invocation of the C compiler,
both those which do compilation and those which do linking.
It would be nice to have an explanation why CFLAGS whould be used with
linking,
On Fri, 2012-03-02 at 06:57 -0700, Eric Blake wrote:
Make fails to restrict output to just directories when a wildcard
contains both a trailing slash and internal slashes, even though it does
the right thing with no internal slashes.
Hi Eric;
This is actually a bug in glibc's glob() function
On Sun, 2012-02-26 at 21:58 -0800, Howard Chu wrote:
You've just described an O(n^2) behavior. This is definitely a drag;
but it really depends on how heavily you make use of macros.
Well, in this case it depends on how heavily you make use of APPEND
operations on macros. Is it worth adding a
On Sat, 2012-02-18 at 18:46 +, Tim Murphy wrote:
The option you need is:
-p, --print-data-base Print make's internal database.
This is the (only) place to start but just to warn you: the output of
this option was not designed to be used this way and we don't guarantee
that the format
On Thu, 2012-02-09 at 17:25 +, Tim Murphy wrote:
I also think that it can be expensive to append things onto very long
lists in make but that's just suspicion and I really need to take a
proper look at it instead of making accusations.
Appending is not very expensive. Make doesn't know
On Sun, 2012-02-12 at 19:34 +0200, Eli Zaretskii wrote:
Date: Sun, 12 Feb 2012 18:11:49 +0100
From: Sebastian Pipping sebast...@pipping.org
CC: psm...@gnu.org, bug-make@gnu.org
Since we would run into buffer overflows with sprintf/vsprintf, we
rely on snprintf/vsnprintf for that task.
On Mon, 2012-01-30 at 17:44 -0500, David Boyce wrote:
Thanks, this will make a lot of people happy.
One nit: as mentioned earlier I think it would be good to document the
relationship of $(file ...) with timestamps. Assuming nothing special
is done (I haven't looked at the code) then writing
On Mon, 2012-01-30 at 21:33 -0500, David Boyce wrote:
On Mon, Jan 30, 2012 at 6:19 PM, Paul Smith psm...@gnu.org wrote:
Is there something special you would prefer beyond this?
Well ... it's more of a thought than an actual request or preference,
but I'm suggesting that make might want
On Mon, 2012-01-23 at 09:52 -0800, Lawrence Ibarria wrote:
I do like this suggestion, feels quite clean!
I implemented the write side of this proposal and committed it to CVS,
along with regression tests and documentation.
The read side is slightly more work but I can do this one too if
people
On Thu, 2011-12-15 at 15:13 -0800, Lawrence Ibarria wrote:
This is a rather simple path that implements a very simplified version
of what Tim suggested in his message of Sept 25th
(https://lists.gnu.org/archive/html/bug-make/2011-09/msg00044.html ).
Paul, what do you think? I’d rather not
On Thu, 2012-01-05 at 19:29 +0100, Sebastian Pipping wrote:
I confess I'm not an expert in i18n, so it's quite possible I'm making
something out of nothing very important here. But I think it's worth
investigating. It's possible, for example, that it's sufficient to
translate the prefix
On Thu, 2012-01-05 at 22:42 +0100, Sebastian Pipping wrote:
On 01/05/2012 09:46 PM, Eli Zaretskii wrote:
The easiest way of abstracting this is to have a function that turns
on a given color, and another function that turns off a color and
returns to the default color. (Color can actually
On Thu, 2012-01-05 at 22:35 +0100, Sebastian Pipping wrote:
Function vsnprintf could be used to fill variable output.
Quoting the local printf(3) man page:
Erhm. Forgot about that: neither vsprintf() nor vsnprintf() were
included in the C89 standard. They were added in the C99 standard.
On Sun, 2012-01-01 at 01:31 +0100, Sebastian Pipping wrote:
I have to say that I feel that David's
point of 20 Oct is well-taken, that a more flexible command line
interface would be better.
Alright. I propose to transform
--output-format=(color|plain)
into
On Fri, 2011-12-16 at 12:41 +, Tim Murphy wrote:
I looked at the implementation and it seems like a different name
would suit this function - e.g. writefile. It basically writes text
from it's arguments out to a file.
Thanks all; I'll take a look.
--
On Wed, 2011-12-07 at 16:04 +0200, Atte Peltomäki wrote:
Hello,
here's a small fix for a corner case I happened to run into.
Scenario:
Run 'make -t' on an incomplete tree, where a dependency file and
the subdirectory it should be in, are completely missing. Make fails
and exits.
On Wed, 2011-12-07 at 11:53 -0800, Tim Newsome wrote:
Does anybody know what the right solution to this problem is? I'm
happy to implement/test either one, but I don't want to spend my time
working on a solution that won't be accepted upstream.
I committed a fix for this.
--
1001 - 1100 of 1343 matches
Mail list logo
