make not detecting included file changes

[Jan]

Hi,

Just got openSUSE 12.2 update for make 3.82-147.5.1 which is to fix make 
not detecting changes in intermediaries.


It still doesnt detect changes to included files.

The attached project illustrates the problem.

Is it make or this project's makefiles that are at fault?

Regards,

Jan


TestMake.tar.gz
Description: GNU Zip compressed data
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Manual Translation

[Jan]

Hi,

my name ist Jan Kechel,

i was redirected to this email-adress by [EMAIL PROTECTED] and
[EMAIL PROTECTED]

I want to translate the make Manual to German:

---
Jorgen 'forcer' Schaefer <[EMAIL PROTECTED]> wrote:

> > 2. I'd really like to translate the make manual. Is there
> > already someone working on that?
>
> I'm not aware of anyone doing so, you should either await the
> answer of gnu-translation, or ask [EMAIL PROTECTED] ...


Martin v. Loewis <[EMAIL PROTECTED]> wrote:

>Finally, maintainers of GNU make have to agree (preferably in advance)
>to integrate your translation when it is done, so contacting bug-make
>is a good recommendation.

---

So now I ask you about this:
Shall I continue to translate the Manual?
- Of course i won't publish anything without your explicit permission.
- I'm going to translate the texinfo source.
- I would like to publish finished translations under the terms of the "GNU
Free Documentation License", but that's actually your decision not mine.
- On my System i got make version 3.79.1 and the actual manual also
describes version 3.79, so i think it's up to date and well maintained.
- If you want I keep you up to date with my work, at the moment i did not
start any translations yet.

Please give me some advise on 'how to continue'.

Thanks in advance,
Jan Kechel / student University Potsdam - Germany




___
Bug-make mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-make

override MAKEFLAGS and jobserver

[Jan Smets]

Hi

I'm using the Broadcom SDK and one of the Makefiles has 'override
MAKEFLAGS = ...'.

If my observations are correct then "jobserver-fds" (and all
parallelism) is lost here. Is that correct?

If so, is this intentional or a bug?

Thanks
- Jan


-- 
Smets Jan
j...@smets.cx

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #50790] Some kind of memory corruption in error messages with gcc-6.3.0 -flto=4

[Jan Ziak]

URL:
  

 Summary: Some kind of memory corruption in error messages
with gcc-6.3.0 -flto=4
 Project: make
Submitted by: atomsymbol
Submitted on: Wed 12 Apr 2017 06:07:20 PM UTC
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 4.2.1
Operating System: POSIX-Based
   Fixed Release: None
   Triage Status: None

___

Details:

Hello.

The following is the output of a Makefile-based project which uses GCC 6.3.0
to compile C/C++ files. make is invoked with -j4 on the command line. The
command-line option -flto=4 is being passed to the GCC compiler. The bug goes
away if -flto=1 or -flto is used instead of -flto=4.

Is this a make-4.2.1 bug, or a gcc-6.3.0 bug? The line numbers in the garbled
error messages, in this case 79 and 84, are correct.

$ make -j4
...
collect2: error: ld returned 1 exit status
make: *** [Makefile:84: target1] Error 1
make: *** Waiting for unfinished jobs
...
make: *** [Makefile:79: target2] Error 1
...
collect2: error: ld returned 1 exit status
make[1]: *** [4
   �
:79: target2] Error 1
make[1]: *** Waiting for unfinished jobs
...
collect2: error: ld returned 1 exit status
make[1]: *** [4
   �
:84: target1] Error 1
lto-wrapper: fatal error: make returned 2 exit status
compilation terminated.
/usr/lib/gcc/x86_64-pc-linux-gnu/6.3.0/../../../../x86_64-pc-linux-gnu/bin/ld:
error: lto-wrapper failed
collect2: error: ld returned 1 exit status
make: *** [Makefile:71: tul] Error 1

A line obtained by running /usr/bin/make under /usr/bin/strace is:

execve("/usr/bin/make", ["/usr/bin/make", "-f", "/tmp/ccZfEp7k.mk", "-j4"],
[/* 101 vars */] 




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #50790] Some kind of memory corruption in error messages with gcc-6.3.0 -flto=4

[Jan Ziak]

Follow-up Comment #1, bug #50790 (project make):

It isn't a gcc bug. Please fix it in make-4.2.1+ source code:

==22022== Memcheck, a memory error detector
==22022== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==22022== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info
==22022== Command: /usr/bin/_make -f /tmp/ccEUTdnj.mk -j4 all
==22022==
f.o: In function `f':
f.cc:3155: undefined reference to `tul::ff()'
collect2: error: ld returned 1 exit status
==22022== Invalid read of size 1
==22022==at 0x4A09EF2: strlen (vg_replace_strmem.c:454)
==22022==by 0x4135B6: child_error (job.c:497)
==22022==by 0x415577: reap_children (job.c:866)
==22022==by 0x421C6F: update_goal_chain (remake.c:112)
==22022==by 0x407E0B: main (main.c:2558)
==22022==  Address 0x4caf710 is 0 bytes inside a block of size 200 free'd
==22022==at 0x4A0804B: free (vg_replace_malloc.c:534)
==22022==by 0x41EC52: read_all_makefiles (read.c:210)
==22022==by 0x4073BE: main (main.c:1969)
==22022==  Block was alloc'd at
==22022==at 0x4A06E8F: malloc (vg_replace_malloc.c:306)
==22022==by 0x418334: xmalloc (misc.c:221)
==22022==by 0x40B5C7: initialize_variable_output (expand.c:84)
==22022==by 0x40BDA0: variable_expand_string (expand.c:203)
==22022==by 0x40C2A0: variable_expand (expand.c:417)
==22022==by 0x40C2A0: variable_expand_for_file (expand.c:464)
==22022==by 0x40C2D3: allocated_variable_expand_for_file (expand.c:564)
==22022==by 0x41EC04: read_all_makefiles (read.c:194)
==22022==by 0x4073BE: main (main.c:1969)
==22022==
==22022== Invalid read of size 1
==22022==at 0x32B3446A64: vfprintf (vfprintf.c:1631)
==22022==by 0x32B34F7DD7: __vsprintf_chk (vsprintf_chk.c:85)
==22022==by 0x32B34F7D25: __sprintf_chk (sprintf_chk.c:31)
==22022==by 0x4135F0: sprintf (stdio2.h:33)
==22022==by 0x4135F0: child_error (job.c:498)
==22022==by 0x415577: reap_children (job.c:866)
==22022==by 0x421C6F: update_goal_chain (remake.c:112)
==22022==by 0x407E0B: main (main.c:2558)
==22022==  Address 0x4caf710 is 0 bytes inside a block of size 200 free'd
==22022==at 0x4A0804B: free (vg_replace_malloc.c:534)
==22022==by 0x41EC52: read_all_makefiles (read.c:210)
==22022==by 0x4073BE: main (main.c:1969)
==22022==  Block was alloc'd at
==22022==at 0x4A06E8F: malloc (vg_replace_malloc.c:306)
==22022==by 0x418334: xmalloc (misc.c:221)
==22022==by 0x40B5C7: initialize_variable_output (expand.c:84)
==22022==by 0x40BDA0: variable_expand_string (expand.c:203)
==22022==by 0x40C2A0: variable_expand (expand.c:417)
==22022==by 0x40C2A0: variable_expand_for_file (expand.c:464)
==22022==by 0x40C2D3: allocated_variable_expand_for_file (expand.c:564)
==22022==by 0x41EC04: read_all_makefiles (read.c:194)
==22022==by 0x4073BE: main (main.c:1969)

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: [bug #50790] Some kind of memory corruption in error messages with gcc-6.3.0 -flto=4

[Jan Ziak]

On Tue, Apr 18, 2017 at 9:53 AM, Edward Welbourne
 wrote:
> Jan Ziak (12 April 2017 20:07)
>> Is this a make-4.2.1 bug, or a gcc-6.3.0 bug? The line numbers in the garbled
>> error messages, in this case 79 and 84, are correct.
>
> Given its sensitivity to the specific flags passed to gcc, it's natural
> to suppose it's a gcc bug.  You can test by running gcc manually,
> instead of via make; find the rule that's running gcc, remove @ from the
> start of its line if present, run make to see the command it invokes;
> invoke that command yourself.  If the issue arises then, it's definitely
> gcc.
>
> Eddy.

It isn't a gcc bug. Please fix it in make-4.2.1+ source code:

==22022== Memcheck, a memory error detector
==22022== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==22022== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info
==22022== Command: /usr/bin/_make -f /tmp/ccEUTdnj.mk -j4 all
==22022==
f.o: In function `f':
f.cc:3155: undefined reference to `tul::ff()'
collect2: error: ld returned 1 exit status
==22022== Invalid read of size 1
==22022==at 0x4A09EF2: strlen (vg_replace_strmem.c:454)
==22022==by 0x4135B6: child_error (job.c:497)
==22022==by 0x415577: reap_children (job.c:866)
==22022==by 0x421C6F: update_goal_chain (remake.c:112)
==22022==by 0x407E0B: main (main.c:2558)
==22022==  Address 0x4caf710 is 0 bytes inside a block of size 200 free'd
==22022==at 0x4A0804B: free (vg_replace_malloc.c:534)
==22022==by 0x41EC52: read_all_makefiles (read.c:210)
==22022==by 0x4073BE: main (main.c:1969)
==22022==  Block was alloc'd at
==22022==at 0x4A06E8F: malloc (vg_replace_malloc.c:306)
==22022==by 0x418334: xmalloc (misc.c:221)
==22022==by 0x40B5C7: initialize_variable_output (expand.c:84)
==22022==by 0x40BDA0: variable_expand_string (expand.c:203)
==22022==by 0x40C2A0: variable_expand (expand.c:417)
==22022==by 0x40C2A0: variable_expand_for_file (expand.c:464)
==22022==by 0x40C2D3: allocated_variable_expand_for_file (expand.c:564)
==22022==by 0x41EC04: read_all_makefiles (read.c:194)
==22022==by 0x4073BE: main (main.c:1969)
==22022==
==22022== Invalid read of size 1
==22022==at 0x32B3446A64: vfprintf (vfprintf.c:1631)
==22022==by 0x32B34F7DD7: __vsprintf_chk (vsprintf_chk.c:85)
==22022==by 0x32B34F7D25: __sprintf_chk (sprintf_chk.c:31)
==22022==by 0x4135F0: sprintf (stdio2.h:33)
==22022==by 0x4135F0: child_error (job.c:498)
==22022==by 0x415577: reap_children (job.c:866)
==22022==by 0x421C6F: update_goal_chain (remake.c:112)
==22022==by 0x407E0B: main (main.c:2558)
==22022==  Address 0x4caf710 is 0 bytes inside a block of size 200 free'd
==22022==at 0x4A0804B: free (vg_replace_malloc.c:534)
==22022==by 0x41EC52: read_all_makefiles (read.c:210)
==22022==by 0x4073BE: main (main.c:1969)
==22022==  Block was alloc'd at
==22022==at 0x4A06E8F: malloc (vg_replace_malloc.c:306)
==22022==by 0x418334: xmalloc (misc.c:221)
==22022==by 0x40B5C7: initialize_variable_output (expand.c:84)
==22022==by 0x40BDA0: variable_expand_string (expand.c:203)
==22022==by 0x40C2A0: variable_expand (expand.c:417)
==22022==by 0x40C2A0: variable_expand_for_file (expand.c:464)
==22022==by 0x40C2D3: allocated_variable_expand_for_file (expand.c:564)
==22022==by 0x41EC04: read_all_makefiles (read.c:194)
==22022==by 0x4073BE: main (main.c:1969)

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

unclear error message

[Jan Nieuwenhuizen]

The error message that

$(word 0, a b c )

produces (the `word' function takes a one-origin index argument.) is
unclear, especially given the other meaning of origin in
make. Suggestion:

  the index argument of the word function must be positive.


-- 
Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien   | http://www.lilypond.org

$(eval within conditional causes "missing `endif'" error

[Jan Beulich]

Hello,

investigating the possibilities the new features in make 3.80 offer I
found that I cannot have an $(eval inside any sort of conditional. As
the mailing list documents that this has already been observed I'd like
to find out what the intentions are to fix this. Especially would it
seem questionable to me whether the same logic as in the include
directive handling can be applied here, since it may be useful to be
able to interact with the conditionals state previously in effect.

Thank you very much,

i.A. Jan Beulich
Software Engineer Senior
Novell Linux Platform Engineering

Novell, the leading provider of Net business solutions.
http://www.novell.com/ 


___
Bug-make mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-make

plans for #775

[Jan Beulich]

Hello,

may I ask for the plans to address bug #775 (which as I understand it
would at once fix #108)? The suggested solution (which matches what we
determined) seems rather simple to implement, and there does not seem to
be any risk (incompatibility) with doing so...

Thank you,

i.A. Jan Beulich
Software Engineer Senior
Novell Linux Platform Engineering

Novell, the leading provider of Net business solutions.
http://www.novell.com/


___
Bug-make mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-make

empty $? (bug 8154?)

[Jan Beulich]

In a makefile like presented in the first response to this issue, it is
claimed that it is appropriate for $? to be empty. However, I would
assume that if $? is empty and if the target exists, then there is no
need to remake the target. Or, to say it the other way around, if an
existing target is remade it should be safe to assume $? is non-empty.

Further, the documentation says in 'Rules without Commands or
Prerequisites': 'If a rule has no prerequisites or commands, and the
target of the rule is a nonexistent file, then make imagines this target
to have been updated whenever its rule is run. This implies that all
targets depending on this one will always have their commands run.'
This, to me, also implies that dependencies like the commonly used FORCE
target should be visible in $?.

The problem I'm running into with is in the Linux kernel build: When a
header file gets moved/deleted and the tree is not cleaned, it is
obvious that all objects depending on the no-longer-existing header file
need to be re-built (whether this would result in failure is another
matter; it doesn't have to since through using multiple include paths it
might be possible to find another header that satisfies the source
file's needs). For some cases, the build system appears to already work
around that issue by also examining $(filter-out FORCE $(wildcard
$^),$^), but namely for the compilation of C files this isn't done, and
I suppose that it shouldn't be necessary anywhere.

Jan


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: empty $? (bug 8154?)

[Jan Beulich]

>>> "Paul D. Smith" <[EMAIL PROTECTED]> 28.12.05 04:16 >>>
%% "Jan Beulich" <[EMAIL PROTECTED]> writes:
>
>  jb> In a makefile like presented in the first response to this
issue,
>  jb> it is claimed that it is appropriate for $? to be empty.
However,
>  jb> I would assume that if $? is empty and if the target exists,
then
>  jb> there is no need to remake the target. Or, to say it the other
way
>  jb> around, if an existing target is remade it should be safe to
>  jb> assume $? is non-empty.
>
>  jb> Further, the documentation says in 'Rules without Commands or
>  jb> Prerequisites': 'If a rule has no prerequisites or commands,
and
>  jb> the target of the rule is a nonexistent file, then make
imagines
>  jb> this target to have been updated whenever its rule is run. This
>  jb> implies that all targets depending on this one will always have
>  jb> their commands run.'  This, to me, also implies that
dependencies
>  jb> like the commonly used FORCE target should be visible in $?.
>
>Sorry, Jan, but I don't understand your comments here and how they
>relate to either bug #8154 (other than that they are both about $?)
or
>the FORCE stuff you mention.  That bug talks about updating archives
>where there is no command to update them; you appear to be talking
about
>something completely different here.
>
>Most of the time an example is worth a few hundred words, at least:
can
>you please provide a simple couple of lines of makefile to reproduce
the
>situation you are seeing, show the output make gives, and explain
>exactly why you feel this is incorrect?  We can move on from there.

That's why I referred to the first response to bug #8154, which doesn't
have to do with building archives.

>Just to be clear, I tried this makefile:
>
>$ cat Makefile
>foo: FORCE ; @echo '$$? = $?'
>FORCE:
>
>$ make
>$? = FORCE
>
>every time, so I don't understand your comment that FORCE should be
>visible in $?, as if it weren't visible there... it IS visible there?

The difference to the mentioned example is the missing 'touch foo'
prior to running make. Depending on whether foo exists, $? will or will
not be empty; its commands, however, will always be run (as expected).
My point is that if a target's commands get run, should it be obvious
that then $? cannot be empty?

Thanks again, Jan


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

export vs $(origin )

[Jan Beulich]

Hello,

with documentation stating

"As a convenience, you can define a variable and export it at the same
 time by doing: ..."

It being merely a convenience, is it really intended for "export"
without any assignment done at the same time to change the origin of a
previously undefined variable from "undefined" to "file"? It doesn't
change "default" to "file" for a variable with a default value, for
comparison.

As to the use case - to be able to determine whether a variable has
been given a non-default value, and for such a check to be independent
of whether
- -R was passed to make
- export lives ahead or after the check
a change in behavior would seem to be needed, as such a check can,
afaict, only sensibly check for "undefined" and "default".

FAOD I checked up to 4.3, but not any newer development version of make.

Thanks, Jan

Re: export vs $(origin )

[Jan Beulich]

On 02.07.2020 17:01, Dmitry Goncharov wrote:
> On Thu, Jul 2, 2020 at 8:49 AM Jan Beulich  wrote:
>> is it really intended for "export"
>> without any assignment done at the same time to change the origin of a
>> previously undefined variable from "undefined" to "file"?
> 
> "export" without any assignment done at the same time sets the origin
> to "environment".
> 
> export wom
> introduces the variable to the env and set origin to environment.

Not according to my observations.

> export wom=
> also assigns the value of the variable and sets the origin to "file".
> 
> 
>> It doesn't
>> change "default" to "file" for a variable with a default value, for
>> comparison.
> 
> export CC=
> sets origin to "file" because a new value from the file is assigned.
> 
> export CC
> keeps origin intact because the value does not change.
> 
> 
> 
>> As to the use case - to be able to determine whether a variable has
>> been given a non-default value, and for such a check to be independent
>> of whether
>> - -R was passed to make
>> - export lives ahead or after the check
>> a change in behavior would seem to be needed, as such a check can,
>> afaict, only sensibly check for "undefined" and "default".
> 
> Can you post a sample makefile which demonstrates what you want to achieve?

I can try to; will take a little bit of time though.

Jan

Re: export vs $(origin )

[Jan Beulich]

On 02.07.2020 17:31, Paul Smith wrote:
> On Thu, 2020-07-02 at 17:16 +0200, Jan Beulich wrote:
>>> export wom
>>> introduces the variable to the env and set origin to environment.
>>
>> Not according to my observations.
> 
> The difference is whether the variable already exists in the
> environment or not.
> 
> For this makefile:
> 
>   export FOO
>   $(info FOO: $(origin FOO))
>   all:;
> 
> If you run it like this:
> 
>   $ FOO= make
>   FOO: environment
>   make: 'all' is up to date.
> 
> But if you run it like this:
> 
>   $ unset FOO; make
>   FOO: file
>   make: 'all' is up to date.
> 
> Basically, if you run "export FOO" and FOO does not currently exist at
> all, either in the environment or in the makefile, then it's created in
> make and assigned a "file" origin.
> 
> I'm not sure how it could be otherwise: by specifying "export" you ARE
> creating that variable, because it will be placed into the child's
> environment when a recipe is invoked, even if it's not set.  In other
> words, if FOO is not already a variable make knows about then running
> "export FOO" makes it into a variable that make knows about, which has
> its "export" flag set.
> 
> For example if you change the above makefile:
> 
>   export FOO
>   $(info FOO: $(origin FOO))
>   all: ; @env | grep FOO
> 
> then you run:
> 
>   $ unset FOO; make
>   FOO: file
>   FOO=
>   make: 'all' is up to date.
> 
> you can see that "FOO" is in the environment in the recipe even though
> it wasn't in the environment when make started.

Well, okay, if this behavior is intentional, then may I ask that
the documentation be adjusted to clarify this behavior (i.e. it
is not just a convenience that the variables _can_ be assigned a
value, but instead they always _will_ be assigned one, potentially
empty)? In the case having triggered this report, it has taken me
half a day to wade through makefiles, further complicated by some
non-standard way of recursing as well as the underlying problem
really triggering only on an older version (3.82 in the specific
case) related to how -r and -R get handled when appended to
MAKEFLAGS in a makefile, and when some of the included makefiles
gets remade and hence a re-invocation of make gets triggered.

Also, if this is intentional, then I suppose there is no solution
to the problem I'm having except moving the export line(s) until
after the variable(s) have been assigned to (or moving the
$(origin ) checks ahead of the export, which in my specific case
is not really possible).

As an aside, I am still unconvinced the behavior you describe is
the only one possibly sensible. I could as well view "export" as
a directive to indicate to put the given variable(s) into the
environment, but only if they've been assigned a (potentially
empty) value. I.e. these two would then have different behavior:

export XYZ
export XYZ=

Which means the current behavior could be achieved for people
wanting it, while export wouldn't unconditionally have the effect
of also defining the variable(s) (i.e. more along the lines of
what current documentation says).

Thanks again, Jan

[bug #63347] make 4.4 change in behavior for sub-make invoked via $(shell)

[Jan Palus]

Follow-up Comment #3, bug #63347 (project make):

Just to be clear I don't mind the change with $(shell) now receiving those
vars, what I do mind is that current behavior is selective of which $(shell)s
do receive it. The one in target dependency does not. What I miss is uniform
consistent behavior.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #63347] make 4.4 change in behavior for sub-make invoked via $(shell)

[Jan Palus]

Follow-up Comment #6, bug #63347 (project make):

Thanks Dmitry. I can confirm that the patch fixes nss build that relies on
same flags being passed to all $(shell)s
(https://bugzilla.mozilla.org/show_bug.cgi?id=1800237).


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #63347] make 4.4 change in behavior for sub-make invoked via $(shell)

[Jan Palus]

Follow-up Comment #8, bug #63347 (project make):

Looks like attached patch changes behavior in the way that makes Linux kernel
build system assume silent mode.

For following input:


$ cat Makefile
MAKE_OPTS := A=a C=c H=h
all:
$(MAKE) -C test $(MAKE_OPTS) all

$ cat test/Makefile
MAKEFLAGS += -rR

$(info MAKEFLAGS=$(MAKEFLAGS))

all:


Unpatched make 4.4:

$ make -j2
...
MAKEFLAGS= -j2 --jobserver-auth=fifo:/home/users/builder/tmp/GMfifo655627 -rR
...


Patched make 4.4:

$ make -j2
...
MAKEFLAGS=rR -j2 --jobserver-auth=fifo:/home/users/builder/tmp/GMfifo1150317
-- H=h C=c A=a
...


Differences that I could spot:
- there's "rR" instead of "-rR"
- "-rR" is at the beginning not at the end
- MAKE_OPTS are part of MAKEFLAGS -- that's what confuses kernel's build
system since it merely looks for 's' in MAKEFLAGS after stripping long
options:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Makefile?id=e5f3ec38c8496dd7f6ada8a5e8d4958ef46ddb3f#n97


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

pattern rules with multiple targets producing intermediate files

[Jan Beulich]

Hello,

while something has changed from 4.3 to 4.4 in the dealing with
intermediate files, the example Makefile below still doesn't work
as expected. There are two pairs of *.[ch] files generated, each by
their respective rule. Each of the *.o files to be compiled from the
*.c ones has a dependency recorded on both *.h files. If (up-to-date
or outdated) instances of all four generated files are there, all is
fine. If both *.c files are missing, all is fine as well. However,
if only one *.c file is missing and the other is up-to-date,
compilation of the other *.c file will (provided at least -j2 was
passed) be invoked in parallel to the re-generation of the other
*.[ch] pair, not taking into consideration that one of the *.h files
is in the process of being re-generated (together with its sibling
*.c file).

The difference in behavior of 4.4 compared to 4.3 is that this is
now symmetric. In 4.3 only the C file corresponding to the first
prereq of "all" was permanently affected by the bad behavior
(according to my experiments); a re-run of make would succeed
(because the intermediate file was not treated as such and hence was
not deleted).

Of course I'm not going to exclude that there's something that's
done wrongly in that (heavily stripped down) example - apologies in
advance if so, yet then I'd still appreciate if it could be pointed
out what needs doing differently.

Jan

.PHONY: all
all:tst_b.o tst_a.o

Makefile:: ;

tst_b.o tst_a.o: tst_a.h tst_b.h

#.SECONDARY: tst_a.c tst_b.c

%.o: %.c
@echo 'C: *=$* @=$@ <=$<'
@for i in $^; do test -f "$$i" || echo "Missing: $$i"; done
@for i in $^; do test -s "$$i" || echo "Empty: $$i"; done

%.c %.h: %.a
@echo 'A: *=$* @=$@ <=$<'
rm -f $*.[ch]
touch $*.c $*.h
sleep 1
echo "$*.c ($<)" >$*.c
sleep 1
echo "$*.h ($<)" >$*.h

%.c %.h: %.b
@echo 'B: *=$* @=$@ <=$<'
rm -f $*.[ch]
touch $*.c $*.h
sleep 1
echo "$*.c ($<)" >$*.c
sleep 1
echo "$*.h ($<)" >$*.h

Re: Generating missing depfiles by an automake based makefile

[Jan Engelhardt]

On Wednesday 2023-02-08 03:39, Dmitry Goncharov wrote:
>
>This rule restores a missing depfile file by creating a file with one
>line '# dummy'. (Next version of automake will create an empty one).
>There must have been a reason for generating such a depfile.

depfiles are created ahead of make so that the include command
in Makefiles succeeds (include-with-ignore is non-portable AFAIR).


>However, this depfile fails dependency tracking. Once a depfile was
>removed and recreated in this shape, it will no longer perform its
>function.

depfiles are not specifically tracked; this is impossible,
due to a chicken-egg problem.

.Po file contents control when an .o file -- and thus also
the .Po file itself -- is remade.

If a .Po file has no practical content, there is no indication
that it needs to be remade.

Re: Generating missing depfiles by an automake based makefile

[Jan Engelhardt]

On Thursday 2023-02-09 22:33, Dmitry Goncharov wrote:
>
>> .Po file contents control when an .o file -- and thus also
>> the .Po file itself -- is remade.
>> If a .Po file has no practical content, there is no indication
>> that it needs to be remade.
>
>Absence of the depfile is such an indication.
>Here is a sample bash session which demonstrates how gnu make and sun
>make are able to build a missing depfile.
>
>$ ls
>hello.c  hello.h  makefile
>$ cat makefile
>all: hello.tsk
>hello.tsk: hello.o
>gcc-10 -o $@ $^
>
>hello.o: hello.c hello.Po
>gcc-10 -c hello.c -MD -MF hello.Po
>
>hello.Po:
>gcc-10 -c hello.c -MD -MF hello.Po
>
>include hello.Po

This is a GNU extension. If you try this with e.g.
OpenBSD make, it will complain.

Re: Generating missing depfiles by an automake based makefile

[Jan Engelhardt]

On Thursday 2023-02-09 22:53, Dmitry Goncharov wrote:
>
>> If you try this with e.g.
>> OpenBSD make, it will complain.
>
>That's why i asked those questions about portability.
>Do i understand it correctly, that a need to support bmake forces
>automake to abandon a good mechanism to rebuild depfiles?

Maybe not. autoconf is big on text substitution, and there already is an 
AM_MAKE_INCLUDE m4 macro to test for the type of include directive.

It would probably take a new m4 macro AM_MAKE_SILENT_INCLUDE that tests 
for the availability of "-include", and if found, also somehow changes 
the rest of the depfile logic to use absent-depfiles rather than 
empty-depfiles.

Re: pattern rules with multiple targets producing intermediate files

[Jan Beulich]

On 19.02.2023 15:06, Paul Smith wrote:
> On Tue, 2023-02-07 at 14:51 +0100, Jan Beulich wrote:
>> while something has changed from 4.3 to 4.4 in the dealing with
>> intermediate files, the example Makefile below still doesn't work
>> as expected. There are two pairs of *.[ch] files generated, each by
>> their respective rule. Each of the *.o files to be compiled from the
>> *.c ones has a dependency recorded on both *.h files. If (up-to-date
>> or outdated) instances of all four generated files are there, all is
>> fine. If both *.c files are missing, all is fine as well. However,
>> if only one *.c file is missing and the other is up-to-date,
>> compilation of the other *.c file will (provided at least -j2 was
>> passed) be invoked in parallel to the re-generation of the other
>> *.[ch] pair, not taking into consideration that one of the *.h files
>> is in the process of being re-generated (together with its sibling
>> *.c file).
> 
> Unfortunately the above is hard for me to understand and trying to
> reproduce the behavior you're concerned about with the makefile you
> provided didn't yield success.

Looks like there was a timing issue which I needed to make one further
small adjustment for, to behave more predictably. The .c -> .o rule
wants to be

%.o: %.c
@echo 'C: *=$* @=$@ <=$<'
sleep .5
@for i in $^; do test -f "$$i" || echo "Missing: $$i"; done
@for i in $^; do test -s "$$i" || echo "Empty: $$i"; done

(i.e. the half-second sleep added there). I'm sorry for not noticing
this earlier.

> It would be very helpful if you could (A) explain how to set up the
> environment (I assume I need to "touch tst_a.a tst_b.b"?  Anything
> else?), (B) show a transcript of the commands you ran and the output
> you got, cut and pasted, and (C) point out very clearly in the output
> which things you think are not correct, and what you expected to happen
> instead.

There should be tst_a.a and tst_b.b plus, respectively up-to-date (i.e.
newer) tst_a.h, tst_b.c, and tst_b.h. Then "make -j2" gives

make: Entering directory '/home/jbeulich/tmp/mktst'
C: *=tst_b @=tst_b.o <=tst_b.c
sleep .5
A: *=tst_a @=tst_a.c <=tst_a.a
rm -f tst_a.[ch]
touch tst_a.c tst_a.h
sleep 1
Empty: tst_a.h
echo "tst_a.c (tst_a.a)" >tst_a.c
sleep 1
echo "tst_a.h (tst_a.a)" >tst_a.h
C: *=tst_a @=tst_a.o <=tst_a.c
sleep .5
rm tst_a.c
make: Leaving directory '/home/jbeulich/tmp/mktst'

This shows that the commands to "compile" tst_b.c and the commands to
re-generate tst_a.[ch] run in parallel; note the "Empty: ..." line,
which is what I'd expect to not be there (besides the expectation of
other output to be in different order). This is despite the Makefile
containing enough information for make to know that tst_a.h, being a
dependency of tst_b.o, is to be re-generated.

All this said, others involved in the investigation of the issue the
example was stripped down from meanwhile expressed the opinion that
the behavior is to be expected. Personally I remain unconvinced of
this, primarily because - as said - make has all information
available. It merely doesn't use it (yet maybe, as per the other
views expressed, rightly so).

FTAOD I'm attaching the full Makefile I've been using.

Jan.PHONY: all
all:tst_b.o tst_a.o

Makefile:: ;

tst_b.o tst_a.o: tst_a.h tst_b.h

#.SECONDARY: tst_a.c tst_b.c

%.o: %.c
@echo 'C: *=$* @=$@ <=$<'
sleep .5
@for i in $^; do test -f "$$i" || echo "Missing: $$i"; done
@for i in $^; do test -s "$$i" || echo "Empty: $$i"; done

%.c %.h: %.a
@echo 'A: *=$* @=$@ <=$<'
rm -f $*.[ch]
touch $*.c $*.h
sleep 1
echo "$*.c ($<)" >$*.c
sleep 1
echo "$*.h ($<)" >$*.h

%.c %.h: %.b
@echo 'B: *=$* @=$@ <=$<'
rm -f $*.[ch]
touch $*.c $*.h
sleep 1
echo "$*.c ($<)" >$*.c
sleep 1
echo "$*.h ($<)" >$*.h

Bug: Missing 'S' in GNU make tutorial

[Jan Christoph Ebersbach]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
the Makescript at
http://www.gnu.org/software/make/manual/html_chapter/make_8.html#SEC91
contains a little bug:
server_OBJS = server.o server_priv.o server_access.o
server_LIBS = priv protocol
...
define PROGRAM_template
~ $(1): $$($(1)_OBJ) $$($(1)_LIBS:%=-l%)
~ ALL_OBJS   += $$($(1)_OBJS)
endef
$$($(1)_OBJ) should be $$($(1)_OBJS)
Bye.
Jan Christoph Ebersbach
- --
eMail: [EMAIL PROTECTED]
Hompage  : http://www.e-jc.de/
PGP-KeyID: 0x2D600996
Wo kämen wir hin, wenn alle sagen würden "wo kämen wir hin" und keiner
ginge, um zu sehen, wohin man käme, wenn man ginge ;-)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCA6l2Y+DL3S1gCZYRAn5MAKCC7m0yTSuQNsqKSNNYHVMsoYW+oQCfXI1m
S/oOAVunPgMjxV1pOh9Q/9I=
=KA1Q
-END PGP SIGNATURE-
___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Unexpected feature

[Gert Jan van Loo]

I try to generate a Verilog include file list using:

INC_DIRS = +incdir+\
/projects/maui_vc3/work/gvl/design_database_vc3/verilog_src/memc/+\
/projects/maui_vc3/work/gvl/design_database_vc3/verilog_src/common/+\
/projects/maui_vc3/work/gvl/design_database_vc3/verilog_src/core/+\
/projects/maui_vc3/work/gvl/design_database_vc3/verilog_src/debug/

I find this failing because 'make' does not honour the backslash code at
the end of the line
as any other program: It adds a space!
So the result is:
+incdir+
/projects/maui_vc3/work/gvl/design_database_vc3/verilog_src/memc/+
/projec... etc.
This is NOT accepted by the tool. It needs:
+incdir+/projects/maui_vc3/work/gvl/design_database_vc3/verilog_src/memc
/+/projec...

I have several problems with this:
1/ Adding the space is NOT the normal convention used for the backslash
in other programs.
2/ If I want to have a space I can just add it before the backslash. So
there is a 
   simple solution to anybody who wants a space. This in contrast to the
current state where
   I now have to contort myself to remove the spaces again.
   (Which I still have not found how to do, Probably some complex
replace expression)
3/ I have tried to search the info-text but not found this listed
anywhere.
   In fact the \ at the end of the line is used in examples, shortly
commented upon and
   further ignored as something which is 'self-evident'. 

I assume this 'feature' will not be removed as it will break the
makefile of
all simple souls who are not competent enough to add a space in the
right place.

I DO suggest to add this to the manual somewhere and explain in more
details the processing
which takes place when a backslash is at the end of a line:
It adds one space if it is missing and it reduces multiple spaces and
tabs to a single space.
I also suggest you specify how to get rid of these nasty spaces in case
anybody does not want them.

p.s.
Is this a relic from the original 'make'?
I don't have access to an old Unix machine or Make manual so I can't
check this.






___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make