help-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: implementing emake's #pragma multi in GNU make?


From: Gerhard Fiedler
Subject: Re: implementing emake's #pragma multi in GNU make?
Date: Sun, 10 Feb 2013 16:13:10 -0200
User-agent: 40tude_Dialog/2.0.15.84

Mark Galeck wrote:

> --- On Fri, 2/8/13, Gerhard Fiedler <address@hidden> wrote:
> 
>> Having to rely on "clean" builds when incremental builds could do the
>> job just fine is IMO either an artifact of an insufficient build
>> system or a result of a bug (or missing feature) in make.
> 
> Gerhard,  IMHO you are misinterpreting me.  I am not relying on
> "clean" for anything.  In fact, I strongly recommend against using
> "clean" at all.  The build should work correctly without any need for
> clean. 

A few messages back you wrote: "If you delete a crucial intermediate
file without knowing what you are doing, then in my opinion it's not the
build system's job to do anything other than say 'it's your fault, now
you have to do a complete clean'."

So there do seem to be situations where you recommend "clean". It's
those situations (and this specific comment) that I was referring to.

> The only use of clean, is to clean up when the user messed up, such
> as, I say, when they corrupted the system - like, deleted
> intermediate files. 

This seems to be where we disagree... IMO missing intermediate files
should be tolerated in build systems. (I don't say 'must be'...)

> I say, the only things the build system has to support is : touch the
> sources, and make anything that is a target, and the build system is
> supposed to perform correctly for any sequence of these steps. 
> 
> You and Michael, and Eric, seem to be saying, "no, there is more to
> it". 
> 
> OK, what other "allowed" actions to you propose? 

The allowed actions are a consequence of the build system's
functionality. For me, part of it is to create all missing files. Hence,
removing intermediate files shouldn't affect the build system's correct
functionality. Deleting any intermediate (or output) file is considered
(by me, and by many others) a "poor man's local 'clean'".

> Obviously, not all actions are allowed.  If you do your build, and
> then edit some bytes in your intermediate file, I hope we all agree
> that no system will correctly recover from that.  So that is not
> allowed. 

Correct. Neither is 'touch'ing intermediate files.

> Yet you are saying, that deleting the file is OK. 

Correct. 

> All right, then please explain where exactly you draw the line
> between "allowed" and "not allowed" actions to the intermediate
> files, and why you draw the line there and not somewhere else? 

I think deleting intermediate files is the only difference in the lines
we draw.

As for why: Mostly usability and robustness, I think. Being able to
delete any intermediate file that is suspect without having to do a full
'clean' build afterwards (and without messing up the build system) is
IMO helpful and generally desired by build system users. (FWIW, I agree
with you that it's not necessary.)

Also FWIW, I'm writing this with a focus on the 'wild' development that
precedes the production phase, where experimenting and other
uncontrolled activities are normal.

Gerhard




reply via email to

[Prev in Thread] Current Thread [Next in Thread]