Austin Group Defect Tracker

Aardvark Mark IV


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0001325 [Online Pubs] Shell and Utilities Editorial Clarification Requested 2020-02-09 17:17 2020-02-10 13:27
Reporter dmitry_goncharov View Status public  
Assigned To
Priority normal Resolution Open  
Status New  
Name Dmitry Goncharov
Organization
User Reference
URL
Section (section number or name, can be interface name)
Summary 0001325: Allow make to remake an included file
Description https://austingroupbugs.net/view.php?id=333 [^]

proposes the following wording
 
"If the file cannot be opened, and if the word include was prefixed with a
<hyphen> character, the file shall be ignored. Otherwise, if the file cannot be
opened an error occurs."

If this wording is added to the standard it'll outlaw a widely used scenario.
Specifically a makefile has a rule to build a dependency file and an include
directive without hyphen to include this freshly built dependency file.
If the file is missing the rule builds it and include includes it.
include rather than -include is more useful for this scenario because if the
file cannot be remade the user will know.
This mechanism is supported by gnu make and is used by automake and thus by a
miriad projects that use autotools.
Desired Action After
"If the word include"
append
", optionally prefixed with a <hyphen> character,".

At the end, append:
"If the file cannot be opened and the makefile has a rule to build the file
make may remake the file.
If the file cannot be opened and cannot be remade, and if the word include was
prefixed with a <hyphen> character, this -include directive shall be ignored.
If the file cannot be opened and cannot be remade, and if the word include was
not prefixed with a <hyphen> character, an error occurs."
Tags No tags attached.
Attached Files

- Relationships

-  Notes
(0004780)
shware_systems (reporter)
2020-02-09 18:29

As a potential breaking change to some implementations I'm not sure this is desirable. If such a workflow is needed the same effect is produced by having the file as a target of its own before the include line, with the current wording. Having include fail indicates the commands associated with an explicit target were not successful in creating it. I can see an App Usage note explaining this, not modifying the include argument to be treated fully as a prerequisite file; matching targets and inference rules, especially if the file suffix matches additional inference rules built-in to a particular implementation. The gnu make behavior would still be allowed to makefile's that don't have the .POSIX special target.
(0004781)
joerg (reporter)
2020-02-10 13:27
edited on: 2020-02-10 13:28

Re: Note: 0004780 Nobody will implement a behavior since SunPro Make introduced the behavior of first trying to evaluate an existing rule before the include statement is handled.

Prepending "include" by a minus thus just can be seen as "do not cause an error if the file cannot be included after a potential rule to create it has been run".

A big problem in this area however is that GNU make did missbehave for this statement for a really long time. The new gmake version that appeared recently fixed this in serial mode, but fails even more miserably in parallel mode.

But it may be of interest that SunPro Make see schilytools: http://sourceforge.net/projects/schilytools/files/ [^]

supports "include" since SunOS-3.5 (January 1986) and my enhanced version supports "-include" since January 2018, the way I documented above.

My smake (first written by me in 1985) supports include and -include since 24 years.

I cannot speak for GNU make, but SunPro Make passed the POSIX compliance tests together with the Solaris certification. It would be a really bad idea to make the standard in conflict with the current behavior of the most important make implementations.

BTW: I was in the assumption, that the new POSIX text is compatible with the SunPro Make implementation.


- Issue History
Date Modified Username Field Change
2020-02-09 17:17 dmitry_goncharov New Issue
2020-02-09 17:17 dmitry_goncharov Name => Dmitry Goncharov
2020-02-09 17:17 dmitry_goncharov Section => (section number or name, can be interface name)
2020-02-09 18:29 shware_systems Note Added: 0004780
2020-02-10 13:27 joerg Note Added: 0004781
2020-02-10 13:28 joerg Note Edited: 0004781


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