mainmake - Support: sr #102515, Alternative to using modification...


You are not allowed to post comments on this tracker with your current authentication level.

sr #102515: Alternative to using modification dates

Submitter:  None
Submitted:  Wed 15 Oct 2003 07:11:11 AM UTC
Votes: 100
Category:  None Priority:  5 - Normal
Severity:  2 - Minor Status:  None
Privacy:  Public Assigned to:  None
Originator Email:  -email is unavailable- Open/Closed:  Open
Operating System:  None

Tue 04 May 2004 04:57:41 AM UTC, comment #2: 

> However, what you term an "implementation detail" is
> in fact a fundamental change to the entire paradigm of
> make: make has always been a stateless command. These
> features would make it stateful.

I thought about this some more, and I wonder could it be done in the same way as .d files for tracking dependencies? They are essentially stateful, but don't change the paradigm of make.

So for example, you have some way to generate a target.t.metadata file for each target, with contents something like this:

target.t: source.s[MD5=xyz]
target.t: source.s[size=512]
target.t: source.s[color=red]
target.t: source.s[ -abc -def]
target.t: source.s[$ENVVAR=envvalue]

then in the makefile, you just "include" whatever metadata files you want same as you would a .d file, and specify how to generate metadata somehow like this:

    md5 -i $@
    wc -c < $@ # or could be builtin
    color -i $@
meta[command]: # might have to be build in
meta[$ENVVAR]: ${ENVVAR} # environment variable setting at the time. needs better syntax I am sure.
meta[uservar]: hello # user variable. need syntax to distinguish commands from strings
# need a way to specify output files for metadata
# need a way to change metadata commands for different rules.

In you rules specify which metadata to generate for a particular type:

%.t: %.s %.s[size]

Of course there is still plenty of problems left, but is the above any more broken in terms of backwards compatability and statelessness than including .d files for dependencies?

I have probably missed or glossed many important issues of course.

Mon 17 Nov 2003 02:57:40 PM UTC, comment #1: 

This is a long-standing request, and it's also tied to the
long-standing request to implement something like Sun's
.KEEP_STATE feature, where the command line used to
construct the object is kept so that changes to that command
line will result in re-compiles.

However, what you term an "implementation detail" is in fact
a fundamental change to the entire paradigm of make: make
has always been a stateless command.  These features would
make it stateful.  The implementation is not that simple,
since you need to track potentially multiple different
attributes of a given target, you need to consider
portability to the various platforms make supports, and
you need to carefully consider issues of locking and
contention for the state files, since make is often invoked
recursively so you may have multiple make instances running,
even in the same directory.

Paul D. Smith <psmith>
Group administrator
Wed 15 Oct 2003 07:11:11 AM UTC, original submission:  


I think that it would be nice to have an option on
make to use something (for example MD5 sums?) other
than modification dates to check whether the
dependencies/targets have changed.

The justification for this is that if you recieve a
delivery of code in say a zip file, or from some
source control tools, the modification date of those
files will not really correspond in any meaningful way
to the dates of targets in your work area. You are
then basically left with the option of doing a "make
clean", which is fine for small projects, but when
doing the corresponding make takes hours or days as it
can on larger projects it becomes frustrating.
Especially when you are recieving a lot of different
components in this way.

Of couse if you do this, you then need to maintain a
database of checksums and so on, but that's an
implementation detail... ;-)

Best regards,



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

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


CC list is empty


There are 100 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.


Follows 1 latest change.

Date Changed by Updated Field Previous Value => Replaced by
2006-02-23 heini Carbon-Copy- Added heini

Back to the top

Powered by Savane 3.13-3736.
Corresponding source code