RE: Manual isn't clear about where $(error) and $(warning) write to
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 list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
RE: File timing bug
>-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 >targets that make knows about but I can't quote from the manual to >support that de jure. (And I believe that the only way you can safely >update multiple targets from a single rule is if it's a >Pattern Rule but >not a Static Pattern Rule.) I was rather hoping I'd provoke a more >authoritative response from one of the real gurus but perhaps the >warnocking should be taken as agreement.) Think of it the other way around; you do not tell make which targets you update but rather make tells you what targets to update by invoking your rules. And you're right that if you update multiple targets from one rule invocation, you should do it with a pattern rule. Last paragraph of this section: http://www.gnu.org/software/make/manual/make.html#Pattern-Intro /Lasse ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
RE: Makefile doesnt stop for non zero error codes
-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:[EMAIL PROTECTED] On Behalf Of ext Murali Krishna Sent: Wednesday, June 25, 2008 08:38 To: bug-make@gnu.org Subject: Makefile doesnt stop for non zero error codes Hi I am working in a makefile issue where the makefile doesn't stop compilation even after it encounters the error in the cpp file. The make continues with next rule even though the earlier rule gives the non zero exit status. What could be the possible cause for this scenario? -- K.Murali Mohana Krishna ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
RE: [bug #23928] Add MAKEFILE variable
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.
Hmm...
Wouldn't MAKEFILE_LIST be more useful if it always contained the list of
makefiles that lead from the top makefile to the current one?
E.g. given makefiles A, B, C and D. If A includes B and B includes D and
then C. Then MAKEFILE_LIST would contain:
"A" when parsing A,
"A B" when parsing B,
"A B C" when parsing C and
"A B D" when parsing D
Wouldn't that make more sense?
/Lasse
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On
>Behalf Of ext anonymous
>Sent: Saturday, July 26, 2008 08:44
>To: Icarus Sparry; Martin Dorey; [EMAIL PROTECTED];
>[EMAIL PROTECTED]; bug-make@gnu.org
>Subject: [bug #23928] Add MAKEFILE variable
>
>
>Follow-up Comment #3, bug #23928 (project make):
>
>Icarus Sparry wrote:
>> You probably want lastword, rather than firstword.
>
>Nope. To quote the original request:
>
>> It is often useful to recursively call the current makefile
>> as part of a rule. Sometimes rules are included from a
>> different file. The included file may not know the name of
>> the make file used to start the make process.
>
>The request was for the name of "the make file used to start the make
>process", which would be $(firstword ${MAKEFILE_LIST}).
>
>(The use of the phrase "current makefile" is slightly
>ambiguous, but I think
>the last sentence makes it clear that it is meant to refer to
>the makefile
>that started the whole deal.)
>
>
>
>
>
>
>___
>
>Reply to this item at:
>
>
>
>___
> Message sent via/by Savannah
> http://savannah.gnu.org/
>
>
>
>___
>Bug-make mailing list
>Bug-make@gnu.org
>http://lists.gnu.org/mailman/listinfo/bug-make
>
___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make
RE: GNU make to consider files checksum
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 > particular header file. The file defines macros which are the > features that are enabled or disabled in the build. > > We know which features are used by particular components so in theory > we could work out not to rebuild components that are not influenced by > what's happened to the header file. e.g. we could switch on a feature > or add a new feature without forcing a rebuild of the entire source > base. You can do that already today by simply splitting your global feature header file into smaller pieces and letting targets depend on only the relevant pieces rather than everything... Of course that means you have to know which targets need which pieces of the feature set to define the correct dependencies but that's the price you pay for properly functioning incremental rebuilds. You can't have your cake and eat it too... This sort dependency generation can usually be automated fairly easily though, but it's something that is highly dependant on your software architecture, build structure, programming language, etc... For that reason it belongs in your makefiles and not in GNU make itself... > This requires something like md5 but also some kind of "filter" to > determine what kinds of changes are significant to the particular > target that you are testing the dependency for IMNSHO, this is not a problem that make can (or should even attempt to) solve for you. This "filter" as you call it would have to know a lot about the the syntax your header and code files which makes it a bad candidate for a core make feature. This is the classic "global.h" problem of large software builds... > You can emulate md5 checksum dependencies in make of course, using > temporary marker files, but it's a bit ugly and complicated.. This problem is not strictly related to MD5 summing. With MD5 summing instead of timestamps, your global header file would still change and cause a full rebuild because this is what you explicitly asked for by saying that all targets depend on it. /Lasse ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
RE: interactive shell is incorrect
> -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 problem is bash, > > $ cat ~/.bashrc > echo Hello bashrc > > $ /bin/bash -c /bin/pwd > Hello bashrc > /home/davidt/tmp > > $ /bin/sh -c /bin/pwd > /home/davidt/tmp > > Why does bash think it's running interactively when > the -c option is present? I need to study the bash > man pages and pursue as a bash problem ... You might wanna try echoing the $- variable in bash. It shows the bash's current options. /Lasse ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
RE: make error with pro*c redhat 7.2
>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, or it exited in some other abnormal fashion (with a signal of some type). See section Errors in Commands. If no *** is attached to the message, then the subprocess failed but the rule in the makefile was prefixed with the - special character, so make ignored the error. So this is not a make problem but probably a compiler problem... /Lasse -Original Message- From: ext Guy L [mailto:[EMAIL PROTECTED] Sent: Friday, June 06, 2003 1:26 PM To: [EMAIL PROTECTED] Subject: make error with pro*c redhat 7.2 Hello, getting this error while using make with the precompiler Pro*C (linux Redhat 7.2). GNU Make version 3.79.1 Here is the error: [make] : *** [sample9.o] segmentation fault How to fix that Thank a lot Guy L. ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
RE: Path to binary in --help or --version
> -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 > me that checking the version value should be able to tell you > much more > easily whether you have the correct version or not. How about just typing 'which make', before running it? /Lasse ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Target specific immediate append operator not working as expected
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, the append does variable expansion (as if the variable had been deferred). Here's a test case showing the problem: colsw07m -> cat Makefile VAR := $$LOGNAME bar: VAR += bar foo bar: echo $(VAR) colsw07m -> ~/src/make/make-3.81rc1/make foo echo $LOGNAME makholm colsw07m -> ~/src/make/make-3.81rc1/make bar echo OGNAME bar OGNAME bar Making the assignment target-specific or making the append global both work as expected. It seems to be a thing introduced in 3.80 which makes sense since AFAIK 3.80 brought some fixes to target specific variables. 3.78.1 seems to work correctly. 3.79.1, as expected, breaks with target-specific variables. 3.80 works the same as 3.80rc1. The documentation (chapter on target-specific vars) states that: "The variable-assignment can be any valid form of assignment; recursive (`='), static (`:='), appending (`+='), or conditional (`?='). All variables that appear within the variable-assignment are evaluated within the context of the target: thus, any previously-defined target-specific variable values will be in effect. Note that this variable is actually distinct from any "global" value: the two variables do not have to have the same flavor (recursive vs. static)." What basically happens though is that the target-specific append treats the global instance of VAR as recursive. I would consider this a bug especially since this: bar: VAR := $(VAR) bar ...also works as expected... On a slightly related side note, the manual seems to switch between the terms immediate/deferred and static/recursive for describing the same things; the two flavours of variables... Perhaps the two pairs of terms should be unified into one? /Lasse ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
RE: [bug #18680] fix for bug#2846 does not work as expected, still hang sometimes
>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 the >latter was necessary as well. > >Fix applied. Could you commit the fix into CVS? /Lasse ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
RE: [bug #18680] fix for bug#2846 does not work as expected, stillhang sometimes
>> >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 the bug report to your 3.81 code and run with that, if you >need this fix right away. Doh! Silly me, I didn't notice the patch attachment... :-) You are absolutely right, I'll apply the to my tree... Thanks! >Let me know if you'd find the commit useful anyway. Nope... :-) /Lasse ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
RE: EAGAIN in "read jobs pipe"
>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 appearantly have 16K pipes (ulimit -a should tell you)... I get the
same on x86 Linux if I go beyond 4K jobs...
This code (from main.c) assumes that the pipe will be big enough to hold
all tokens:
while (--job_slots)
{
int r;
EINTRLOOP (r, write (job_fds[1], &c, 1));
if (r != 1)
pfatal_with_name (_("init jobserver pipe"));
}
A bug? Perhaps... On the other hand, if you're using -j 65K, why not
just -j? Does you build even have 65K jobs?
I could be wrong of course, but I in my experience you don't gain any
real benefit from going beyond 3-4 jobs per (virtual) core... What's the
difference in build time from, say, -j 128 and -j 65385 for you?
The fact that your machine stays responsive during a build does not
necessarily mean that you will gain any benefit from increasing the -j
number...
/Lasse
___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make
