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
0001437 [1003.1(2016/18)/Issue7+TC2] Shell and Utilities Editorial Enhancement Request 2020-12-15 21:02 2020-12-17 21:16
Reporter steffen View Status public  
Assigned To
Priority normal Resolution Open  
Status New  
Name steffen
Organization
User Reference
Section Vol. 3: Shell and Utilities, Issue 7, make
Page Number (2975) 2989
Line Number (98708, 98742) 99308
Interp Status ---
Final Accepted Text
Summary 0001437: make: (document .NOTPARALLEL and .WAIT special targets) in RATIONAL
Description Parallel, even massively parallel processing has become the widely supported and
used default, yet the standard make(1) does not document it.

If the -j command line option as requested in issue #1436 is standardized,
the standard should also mention ways to synchronize rule processing, in order
to support more complicated build relationships seen in real-life projects.

The suggestion given here can be used with the most widely used make(1)
implementations (GNU make, BSD make) on any tested platform (Linux, *BSD, SunOS
/ Solaris).

The make family rooted on the Sun side of likfe has has at least .WAIT: reserved
for decades, and in practice

  .NOTPARALLEL:
  .WAIT: # Luckily BSD make supports specifying this as target, too

  tangerine: config .WAIT build .WAIT test .WAIT install
  citron: config .WAIT build .WAIT install
  all: config .WAIT build

produces the desired outcome.
Desired Action (
On page 2975, insert before line 98708

  .NOTPARALLEL
    When specified all rules specified in the given makefile are processed
    sequentially, as if -j has not been given.

On page 2975, insert before line 98472

  .WAIT
    When .WAIT appears in a dependency line, prerequisites that appear after it
    are built no sooner until all preceeding prerequisites have been built
    successfully.

On page 2975, change on line 98472 ff.

  The special targets .IGNORE, .POSIX, .PRECIOUS, .SILENT, and .SUFFIXES shall
  be specified without commands.

to

  The special targets .IGNORE, .NOTPARALLEL, .POSIX, .PRECIOUS, .SILENT,
  .SUFFIXES and .WAIT shall be specified without commands.
)

On page 2989, insert before line 99308

  The special targets .NOTPARALLEL and .WAIT represent different, rather
  incompatible synchronisation concepts of parallel build environments as
  used by the diverse implementations. By using an indirection both approaches
  can be supported: for implementations which use .NOTPARALLEL in a makefile to
  ensure sequential rule processing in the given file the full power of parallel
  processing will be available in recursive make instances invoked on makefiles
  without the directive, implementations which synchronize on the .WAIT special
  target will synchronize on it, for example:

    .NOTPARALLEL: # Process all rules sequentially
    .WAIT: # Define to satisfy "the other implementation"

    install: config .WAIT all
      echo Installing..
      ..
    all: config .WAIT build
    build:
      make -f makefile.build
    config:
      ./configure
Tags No tags attached.
Attached Files

- Relationships

-  Notes
(0005184)
psmith (developer)
2020-12-17 17:10

Just to note, GNU make does not support the .WAIT special target.
(0005185)
steffen (reporter)
2020-12-17 19:23

Ach! I wish it would, i think the .WAIT approach "is better" (as in explicit, and does not need an indirection).
But you said on the ML that you do not plan to support it either.

This is why the first part above is in parenthesis, and this issue actually requests some words in RATIONALE instead.

The presented solution has the desired effect also in GNU make ("build" target uses parallel processing).
(0005186)
psmith (developer)
2020-12-17 21:16

I don't believe I said I didn't want GNU make to support it; I agree that it seems like a useful feature. I just said that given the way make's parallel support works I suspect implementation is not so easy and I didn't plan to work on it as I have other things on my (relatively small) plate.

But, if someone else were to get motivated to try to get this working that would be fine with me :). I wonder if creating some kind of internal/implicit prerequisite relationship that wasn't visible to users would be a simpler way to implement this... or not. Well, something for someone to consider.

- Issue History
Date Modified Username Field Change
2020-12-15 21:02 steffen New Issue
2020-12-15 21:02 steffen Name => steffen
2020-12-15 21:02 steffen Section => Vol. 3: Shell and Utilities, Issue 7, make
2020-12-15 21:02 steffen Page Number => (2975) 2989
2020-12-15 21:02 steffen Line Number => (98708, 98742) 99308
2020-12-17 17:10 psmith Note Added: 0005184
2020-12-17 19:23 steffen Note Added: 0005185
2020-12-17 21:16 psmith Note Added: 0005186


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