On 8/4/2010 2:26 PM, Philip Guenther wrote:
On Wed, Aug 4, 2010 at 12:27 PM, tom honermann wrote:
On 8/4/2010 11:25 AM, Alfred M. Szmidt wrote:
There are free software license that are not GPL, for example the
modified BSD license. Pointing you to non-free software would be
wrong
On 8/4/2010 11:25 AM, Alfred M. Szmidt wrote:
There are free software license that are not GPL, for example the
modified BSD license. Pointing you to non-free software would be
wrong, since such software subjugates your rights as a computer user.
Ah, yes, if only the world were that simple.
I'm a little bit off-topic with this email, please forgive me...
I'm interested in finding some examples of proprietary software products
(ie, non-GPL licensed) that distribute a copy of GNU make (preferably a
binary, with or without changes to the GNU make source code) with the
product. If you
On 7/19/2010 4:01 AM, anonymous wrote:
Using Cygwin with its high process creation overhead the proposed change gave
a speedup in the high single-digit procent range.
Are you running on a 64-bit Windows OS? Cygwin's process creation on
64-bit Windows is currently ~6
times slower than on 32-b
On 3/30/2010 11:35 PM, tom honermann wrote:
On 3/29/2010 8:20 PM, Philip Guenther wrote:
Hmm. SysV make has offered the desired feature with the syntax
b1 + b2 + b3: d1
touch -r $^ $@
Ah, thank you! I wasn't aware of a precedent syntax for this
feature. I definitely agree
On 3/31/2010 1:01 AM, tom honermann wrote:
True, but it introduces the problem of making sense of these:
+ b1 + b2 +: d1
b1 + + b2: d1
b1 + b2 b3: d1
Solaris 10 make appears to silently drop dangling and extra '+'
connectors - which is convenient
for handling macros that
On 3/30/2010 2:08 AM, Edward Welbourne wrote:
(While I don't think the sysV syntax is *great*, I personally think
it's a better choice than overloading the meaning of parentheses.)
+1
It also avoids the problem of having to make sense of nesting, e.g.
(b1 (c1 c2)): d1
True,
On 3/29/2010 8:20 PM, Philip Guenther wrote:
Hmm. SysV make has offered the desired feature with the syntax
b1 + b2 + b3: d1
touch -r $^ $@
Ah, thank you! I wasn't aware of a precedent syntax for this feature.
I definitely agree with
using this syntax over what I proposed for comp
On 3/30/2010 2:14 AM, Edward Welbourne wrote:
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.
It actually does serve a roll for testing purposes. Try the following
On 3/2/2010 5:18 PM, tom honermann wrote:
On 3/2/2010 2:45 AM, Edward Welbourne wrote:
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 (rel
On 3/29/2010 2:18 PM, tom honermann wrote:
.INTERMEDIATE: yacc.ts
all: y.tab.h y.tab.c y.output y.tab.o
clean:
rm -f y.tab.h y.tab.c y.output y.tab.o
grammar.y:
@touch $@
yacc.ts: grammar.y
@echo "Running yacc..."
On 3/3/2010 2:03 AM, Edward Welbourne wrote:
Another possibility crossed my mind over-night, with which I haven't
experimented, but that seems like it theoretically should work.
Replace the touch-file with a phony rule:
yacc.ts: grammar.y
yacc -d -v $^
y.tab.h y.tab.c y.output .
On 3/18/2010 2:22 PM, Thiago C. Santini wrote:
Yeah, that was my first thought when using -j, 8 processors each one
with hyper-threading should be optimized with 16 jobs but when testing
it I got better results with 32 jobs and that was working just fine
till last week, so I just sticked to it
Follow-up Comment #3, bug #29074 (project make):
Quoting from the make 3.81 manual:
If you want `make' to simply ignore a makefile which does not exist and
cannot be remade, with no error message, use the `-include' directive instead
of `include', like this:
-include FILENAMES...
T
On 3/2/2010 2:45 AM, Edward Welbourne wrote:
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 one
I've been struggling for some time now with how to write rules for
commands that generate multiple targets and I have so far been unable to
find an elegant solution that works reliably. I know pattern rules have
support for specifying multiple targets, but they don't seem to be
appropriate for
. This is
driving me nuts.
___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make
--
Tom Honermann | Senior Principal Software Engineer | 503.276.2354
Oracle | PeopleTools Development
1211 SW 5th Ave, Suite
On 12/25/2009 4:36 PM, Philip Guenther wrote:
On Thu, Dec 24, 2009 at 7:16 AM, Paul Smith wrote:
You can already completely control the order in which targets are
invoked, even when using -j.
At all times, make will try to build prerequisites starting with the
first one in the prerequisite
On 12/24/2009 7:16 AM, Paul Smith wrote:
You can already completely control the order in which targets are
invoked, even when using -j.
At all times, make will try to build prerequisites starting with the
first one in the prerequisite list, and continuing in order to the last
one in the list.
On 12/24/2009 2:37 AM, Tim Murphy wrote:
Personally I don't like the idea of priorities very much. Large
builds that I have done do have big targets but since we are building
5000 of the same kind of target (using a macro to define a generic
template and $eval to instantiate it for each specific
I'm working on optimizing our GNU make based build system to reduce
build times. Consider the
following dependencies with these run times for each target:
A: # 3 minutes
B: C D # 1 minutes
C: # 1 minutes
D: # 1 minutes
E: # 6 minutes
There are many vali
Follow-up Comment #6, bug #8297 (project make):
How about adding a new special target such as '.MULTIPLE_OUTPUTS'? Usage
would be something like:
.MULTIPLE_OUTPUTS cmdparser.cpp cmdparser.h: cmdparser.y
bison -d -o cmdparser.cpp cmdparser.y
Garrett Cooper wrote:
On May 6, 2008, at 4:56 AM, Paul Smith wrote:
On Tue, 2008-05-06 at 01:09 -0700, Garrett Cooper wrote:
Trying to compile ltp (ltp.sf.net) with modified makefiles and
whenever I run make as follows, it segfaults:
---
shiina:ltp-full-20080430 gcooper$ mak
23 matches
Mail list logo