bugmake - Bugs: bug #13554, Target-specific variable values...


bug #13554: Target-specific variable values inherited by sub-targets

Submitter:  None
Submitted:  Mon 27 Jun 2005 01:57:44 AM UTC
Severity:  3 - Normal Item Group:  Enhancement
Status:  Fixed Privacy:  Public
Assigned to:  psmith Open/Closed:  Closed
Component Version:  3.80 Operating System:  Any
Fixed Release:  3.82 Triage Status:  None
* Mandatory Fields

Add a New Comment Rich Markup

Sun 14 Jun 2009 07:29:27 PM UTC, comment #4: 

In the next version of GNU make there's an ability to declare a target- or pattern-specific variable "private", and it will not be inherited by prerequisites.

Paul D. Smith <psmith>
Group administrator
Wed 27 Jul 2005 03:28:27 PM UTC, comment #3: 

This is not a bug.  The GNUmake documentation states:

"There is one more special feature of target-specific variables: when you define a target-specific variable, that variable value is also in effect for all prerequisites of this target (unless those prerequisites override it with their own target-specific variable value)."

Therefore, this is the expected behavior of target specific variables.


Reid Madsen <srmadsen>
Mon 27 Jun 2005 04:35:20 PM UTC, comment #2: 

I suppose it :)

Well, I hope will exists such enhancement a day.


Mon 27 Jun 2005 01:11:58 PM UTC, comment #1: 

It is absolutely a feature, and it's documented as such in the GNU make manual.  When reading a makefile, the behavior of this feature is always deterministic since make will always read and process the same makefile the same way.  The only time it may give different behavior is if you specify targets on the command line.

Paul D. Smith <psmith>
Group administrator
Mon 27 Jun 2005 01:57:44 AM UTC, original submission:  

Maybe it's a feature...but if so would be useful to have something (as a keyword) to resolve this "problem": when you set a target-specific variable value, that association is inherited into sub-targets.

This implies that the build will be target-specific: making target A and then target B build a different thing than making target B and then target A (in real compilations often only one of those is successful).

For example there are problems in building libraries: to compile the library LDFLAGS must not include, of course, the library itself, but to compile the programs that uses the library you must set it. If you build first the library and then the programs all works, but if you build the program and "make" try to rebuild the library (because it not exists or is out of date), then the wrong LDFLAGS will be inherited breaking the compilation.

In attachment you find a simple Makefile that shown the behaviour with LDFLAGS: if you invoke "make library" and then "make program" the file "library" will contains "none" and the file "program" will contains "library" (ok), but (after "make clean") if you invoke "make program" then both files "library" and "program" will contains "library", that it's not right.



(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

Attached Files
file #3125:  Makefile added by None (163B - application/octet-stream - Simple Makefile that shown the inheritance)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by psmith (Posted a comment)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.


    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2010-07-28 psmith Fixed Release4.0 3.82
    2009-06-14 psmith StatusNone Fixed
        Assigned toNone psmith
        Open/ClosedOpen Closed
        Fixed ReleaseNone 4.0
    2005-06-27 psmith Item GroupNone Enhancement
    2005-06-27 None Attached File- Added Makefile, #2633

    Back to the top

    Powered by Savane 3.13-3cd0.
    Corresponding source code