Marty Leisner wrote:
>Also, "Functions That Control Make" doesn't seem to be accurate
>(only $(error) controls make -- perhaps
>
>"Functions to Display Information/Control Make"
How about simply "Diagnostic Functions"?
/Lasse
___
Bug-make mailing
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On
>Behalf Of ext Martin Dorey
>Sent: Tuesday, June 10, 2008 21:29
>To: Herbert Euler; bug-make@gnu.org
>Subject: RE: File timing bug
>
>(I know from experience that you have to tell make about when
>you update
>t
-k ?
http://www.gnu.org/software/make/manual/make.html#Testing
Another possiblity is a command script that unexpectedly returns true.
E.g.:
foo:
gcc ... || true
...will never fail even if gcc fails...
/Lasse
From: [EMAIL PROTECTED]
[mailto
Philip Guenther wrote:
>BTW, $(lastword ${MAKEFILE_LIST}) is _not_ always the makefile
>being parsed
>at that moment, particularly when there's an 'include'
>directive earlier in
>the makefile. There's in fact no 100% general and reliable
>way to get the
>name of the file that's being parsed.
Tim Murphy wrote:
> I think that checksumming might benefit some targets. It would be
> nice to be able to implement different "methods" for different targets
> - because not all methods work well in all circumstances.
> I have one example where every single file in a huge build includes 1
> par
> -Original Message-
> From: ext David Thompson [mailto:[EMAIL PROTECTED]
> Sent: Friday, June 06, 2003 1:52 AM
> To: 'Paul D. Smith'
> Cc: '[EMAIL PROTECTED]'
> Subject: RE: interactive shell is incorrect
>
>
>
> [snip]
> >Can you help suggest experiments?
>
> Maybe this shows the pr
>From http://www.gnu.org/manual/make-3.79.1/html_mono/make.html#SEC124 :
`[foo] signal description'
These errors are not really make errors at all. They mean that a program that make
invoked as part of a command script returned a non-0 error code (`Error NN'), which
make interprets as failure,
> -Original Message-
> From: ext Paul D. Smith [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, July 08, 2003 4:21 AM
> To: J. Grant
> Cc: [EMAIL PROTECTED]
> Subject: Re: Path to binary in --help or --version
[SNIP]
> I'm still not very clear on why you want the path to make.
> It seems to
There is some weirdness going on with the append operator and
target-specific contexts.
The append operator should act immediately if the variable was
originally assigned with an immediate assignment but this does not
happen if the variable was globally assigned and the append is
target-specific,
>Update of bug #18680 (project make):
>Follow-up Comment #1:
>
>Doh! Silly. As a lame excuse I'll mention that the original
>fix was for
>situations where errno was not 0 _before_ invoking the macro,
>not where it
>was set to 0 inside the macro. However it should have been
>obvious that th
>> >Fix applied.
>>
>> Could you commit the fix into CVS?
>
>I definitely can, but is that really useful? The current state of the
>CVS HEAD is pretty pre-alpha: it's right in the middle of a lot of code
>rework.
>
>It seems to me that the safest thing is to apply the simple patch
>attached to t
>Noticed something else.
>
>Something else completely pointless!
>
> must not be > 16385
True, if you have 16 KB pipes...
> gmake -j 16386; # or above hang
> gmake -j 16385; # or below fire along rapidly
Because you're trying to write more into the job tokens pipe than it can
hold...
You app
12 matches
Mail list logo
