Austin Group Defect Tracker

Aardvark Mark IV

Main | My View | View Issues | Change Log | Docs
  

Viewing Issue Simple Details [ Jump to Notes ] [ Issue History ] [ Print ]
ID Category Severity Type Date Submitted Last Update
0000332 [1003.1(2008)/Issue 7] Shell and Utilities Objection Enhancement Request 2010-10-12 00:23 2011-11-03 15:45
Reporter dwheeler View Status public  
Assigned To ajosey
Priority normal Resolution Rejected  
Status Closed  
Name David A. Wheeler
Organization
User Reference
Section make
Page Number 2912
Line Number 95689
Interp Status ---
Final Accepted Text
Summary 0000332: Add automatic remaking of makefiles
Description To be productive, many build processes automatically determine the dependencies of files, and then use make (or a make-like program) to build only what is necessary.

Articles such as "Recursive Make Considered Harmful" by Peter Miller
(http://miller.emu.id.au/pmiller/books/rmch/ [^] and
http://aegis.sourceforge.net/auug97.pdf) [^] and
"Advanced Auto-Dependency Generation" by Paul D. Smith
(http://make.paulandlesley.org/autodep.html) [^] shows how to automatically
determine dependencies as part of processing a makefile, but they
require functionality *NOT* included in the POSIX specification.

One key item is automatic remaking of makefiles, an already-proven ability:
* This is already implemented in GNU make, see
  GNU make section 3.5
  http://www.gnu.org/software/make/manual/make.html#Remaking-Makefiles [^]
* This is implemented in FreeBSD
  (http://www.freebsd.org/cgi/man.cgi?query=make&sektion=1) [^]
  when .MAKEFILEDEPS is present
  (see its "Remaking Makefiles" section).

FreeBSD only enables this capability with .MAKEFILEDEPS, but
the proposal below does not require .MAKEFILEDEPS.
Checking if a makefile needs updating requires very little time,
accidentally *not* including the .MAKEFILEDEPS could cause mysterious
problems, and there does not seem to be a reason for *not* doing this check.

I did not include ".depend" as part of this (this is part of FreeBSD,
but does not appear to be part of many other makes).
Automatic rebuilding of makefiles is far more general than handling
".depend" as a special case.
Desired Action After line 95689, add a new subsection:

Remaking makefiles

After reading in all makefiles (including via "include"),
make must consider each as a goal target and attempt to update them
(either via explicit or implicit rules), and then update them
as necessary.
After all makefiles have been checked, if any were changed
(other than targets without prerequisites and without commands),
make completely starts over again with a clean slate
(this restart would include an attempt to re-update the makefiles).

When remaking a source Makefile the options
-t (touch), -q (query), and -n (no exec) are ignored,
unless the source Makefile is
specified explicitly as a target in the command line for make.
Tags No tags attached.
Attached Files

- Relationships

-  Notes
(0000569)
user27
2010-10-12 15:11

 This is a bit of a side-track, but I think it's worthwhile noting here.

The make command needs accurate dependencies for two reasons:
1) To ensure that things are built in the right order.
2) To determine the minimum set of things that need to be rebuilt when there is a change.

For (2), the list of dependencies is not enough - make also needs to know which files are now out of date. All implementations that I know of depend on file timestamps for this. However, this is not always reliable:
- Some files can be built in less time than the timestamp resolution.
- In a distributed build environment, system clocks may differ.
For true portability of make scripts, a mechanism for determining "out of date" is needed that does not have these problems.

Before you say "this is a quality of implementation issue, not a standardization issue", bear in mind that some of the text for make does talk about the significance of file modification times. At minimum, we should watch for these and consider rewording them, with a note in the rationale about the potential problems above.
(0000570)
davidsarah (reporter)
2010-10-12 23:25

 An additional reason for potential unreliability of timestamps is that the clock may be set backwards, even on a single machine. (Setting the clock back may be undesirable, but few, if any, systems prohibit it.)
(0000571)
dwheeler (reporter)
2010-10-13 02:27

 Would you please post a separate bug report involving "make" and timestamps? That's really a separate topic.
(0001002)
geoffclare (manager)
2011-11-03 15:45

 In the 2011-11-03 teleconference it was agreed to close this bug as there is no consensus to make the requested change.

- Issue History
Date Modified Username Field Change
2010-10-12 00:23 dwheeler New Issue
2010-10-12 00:24 dwheeler Status New => Under Review
2010-10-12 00:24 dwheeler Assigned To => ajosey
2010-10-12 00:24 dwheeler Name => David A. Wheeler
2010-10-12 00:24 dwheeler Section => make
2010-10-12 00:24 dwheeler Page Number => 2912
2010-10-12 00:24 dwheeler Line Number => 95689
2010-10-12 15:11 user27 Note Added: 0000569
2010-10-12 23:25 davidsarah Note Added: 0000570
2010-10-13 02:27 dwheeler Note Added: 0000571
2011-11-03 15:45 geoffclare Interp Status => ---
2011-11-03 15:45 geoffclare Note Added: 0001002
2011-11-03 15:45 geoffclare Status Under Review => Closed
2011-11-03 15:45 geoffclare Resolution Open => Rejected
2011-11-24 18:33 dwheeler Issue Monitored: dwheeler

Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker