make not detecting included file changes

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,

Manual Translation

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 m

override MAKEFLAGS and jobserver

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 --

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

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 -

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

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 copyri

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

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 flag

unclear error message

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 &l

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

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 N

plans for #775

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

empty $? (bug 8154?)

le 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

Re: empty $? (bug 8154?)

>>> "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

export vs $(origin )

eck 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 )

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&q

Re: export vs $(origin )

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 whe

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

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

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

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

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

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 MAKEFLA

pattern rules with multiple targets producing intermediate files

oing 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 ts

Re: Generating missing depfiles by an automake based makefile

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 s

Re: Generating missing depfiles by an automake based makefile

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 indicati

Re: Generating missing depfiles by an automake based makefile

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 depf

Re: pattern rules with multiple targets producing intermediate files

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 *.

Bug: Missing 'S' in GNU make tutorial

)_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 se

Unexpected feature

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_vc