bugmake - Bugs: bug #1772, target specific make variables do...

 
 

bug #1772: target specific make variables do not work as documented

Submitted by:  Invalid User ID <Invalid User ID>
Submitted on:  Thu 21 Nov 2002 10:17:26 PM UTC  
 
Severity: 1 - WishItem Group: Documentation
Status: FixedPrivacy: Public
Assigned to: Paul D. Smith <psmith>Open/Closed: Closed
Component Version: 3.79.1Operating System: Any
Fixed Release: 3.81Triage Status: None

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Thu 08 Jan 2004 03:11:38 AM UTC, comment #2:

OK, I added some expository text to the GNU make manual.

Paul D. Smith <psmith>
Project AdministratorIn charge of this item.
Thu 21 Nov 2002 10:35:41 PM UTC, comment #1:

The situation is not as dire as it sounds here. First, it's not really that common for the same file to be a prerequisite of a number of targets, unless your makefile is actually trying to build them different ways (which is what this feature is designed for anyway).

The feature is designed to allow things like:

all: foo bar

debug: CFLAGS += -g
debug: all

Now if you run "make all" you get a non-debuggable version, whereas if you run "make debug" you get a version with debug capabilities... and you didn't have to play fancy tricks with your variables, MAKECMDGOALS, etc.

As for the solutions offered:

1) This is not an option. Not only does it not really solve anything, as you pointed out, but (a) it defeats the purpose of the feature and (b) it's not really feasible: make never computes the full list of possible paths to a given target, it only walks its current path. So make cannot know the full set of rules above this one, without a whole lot more work.

2) This is totally unacceptable: it simply is not how make works. Anyway this also doesn't solve the problem because you can't know in what order the targets will get built, and since they're all building the same file you'll just get a random result. Utter breakage.

3) The feature is useful and used (see above), and will not be removed. It is not hard to use it in a way which is perfectly deterministic and understandable--although I agree it can be used in other ways as well. As the doctor said, "don't do that!"

4) I will add a blurb to the documentation making sure that this behavior is clear. I'm resetting this to a documentation bug.

If your makefiles are using this feature in a way which makes it non-deterministic and hard to debug---then don't use it that way any more. It's not designed to be used that way and as I said above, it's not hard to use it so that it's (pretty) obvious what's happening.

Paul D. Smith <psmith>
Project AdministratorIn charge of this item.

 

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

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

Do you think this task is very important?
If so, you can click here to add your encouragement to it.
This task has 0 encouragements so far.

Only logged-in users can vote.

 

Please enter the title of George Orwell's famous dystopian book (it's a date):

 

 

Follow 8 latest changes.

Date Changed By Updated Field Previous Value => Replaced By
Sat 01 Apr 2006 07:03:48 AM UTCpsmithFixed Release4.0=>3.81
Thu 08 Jan 2004 03:11:38 AM UTCpsmithStatusNone=>Fixed
  Open/ClosedOpen=>Closed
  Fixed ReleaseNone=>4.0
Thu 21 Nov 2002 10:35:41 PM UTCpsmithSeverity3 - Normal=>(Error - Not Found)
  Item GroupBug=>(Error - Not Found)
  Assigned toNone=>NA
  Component VersionNone=>(Error - Not Found)

Back to the top


Powered by Savane 3.1-cleanup1