[MacPorts] #45274: Run portbuild::build_main once for each build.target
#45274: Run portbuild::build_main once for each build.target --------------------------+-------------------------------- Reporter: ryandesign@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: base | Version: 2.3.99 Keywords: | Port: --------------------------+-------------------------------- With parallel building, there is the potential for a problem when a port sets `build.target` to multiple values, as was experienced for example with the faust-devel port in #45241. One solution would be to run `portbuild::build_main` once for each `build.target`, rather than running it just a single time and passing it the entire `build.target` all at once. -- Ticket URL: <https://trac.macports.org/ticket/45274> MacPorts <http://www.macports.org/> Ports system for OS X
#45274: Run portbuild::build_main once for each build.target ---------------------------+-------------------------------- Reporter: ryandesign@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: base | Version: 2.3.99 Resolution: | Keywords: Port: | ---------------------------+-------------------------------- Comment (by larryv@…): Just repeating [[comment:11:ticket:45241|what I said on #45241]]: The [http://www.gnu.org/software/make/manual/html_node/Goals.html#Goals GNU Make documentation] explicitly says that it processes each command- line goal in order: You can also specify a different goal or goals with command line arguments to `make`. Use the name of the goal as an argument. If you specify several goals, `make` processes each of them in turn, in the order you name them. Thus, {{{ make A B C }}} satisfies target “A”, then “B”, and then “C”. I don’t know whether other Make variants behave similarly, but it’s easy enough to force GNU Make if necessary. {{{ build.type gnu build.targets first foo bar baz last }}} -- Ticket URL: <https://trac.macports.org/ticket/45274#comment:1> MacPorts <http://www.macports.org/> Ports system for OS X
#45274: Run portbuild::build_main once for each build.target ---------------------------+-------------------------------- Reporter: ryandesign@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: base | Version: 2.3.99 Resolution: | Keywords: Port: | ---------------------------+-------------------------------- Comment (by larryv@…): Admittedly, the part of the documentation [http://www.gnu.org/software/make/manual/html_node/Parallel.html#Parallel describing parallel execution] is not clear on this. -- Ticket URL: <https://trac.macports.org/ticket/45274#comment:2> MacPorts <http://www.macports.org/> Ports system for OS X
#45274: Run portbuild::build_main once for each build.target ---------------------------+-------------------------------- Reporter: ryandesign@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: base | Version: 2.3.99 Resolution: | Keywords: Port: | ---------------------------+-------------------------------- Comment (by larryv@…): Sorry for the noise. Turns out that the documentation doesn’t describe the behavior very well: Specifying the goals on the command line simply adds them (in order) to the list of targets to be run, so parallel building behavior applies to them as usual. {{{ % >test.makefile <<EOF heredoc> .PHONY: foo bar baz heredoc> heredoc> foo: heredoc> @echo foo start! heredoc> @sleep 10 heredoc> @echo foo end! heredoc> heredoc> bar: heredoc> @echo bar start! heredoc> @sleep 5 heredoc> @echo bar end! heredoc> heredoc> baz: heredoc> @echo baz start! heredoc> @sleep 2 heredoc> @echo baz end! heredoc> EOF % make -f test.makefile foo bar baz foo start! foo end! bar start! bar end! baz start! baz end! % make -f test.makefile -j 8 foo bar baz foo start! bar start! baz start! baz end! bar end! foo end! % }}} -- Ticket URL: <https://trac.macports.org/ticket/45274#comment:3> MacPorts <http://www.macports.org/> Ports system for OS X
#45274: Run portbuild::build_main once for each build.target ---------------------------+-------------------------------- Reporter: ryandesign@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: base | Version: 2.3.99 Resolution: | Keywords: Port: | ---------------------------+-------------------------------- Comment (by ryandesign@…): Replying to [comment:3 larryv@…]:
Sorry for the noise. Turns out that the documentation doesn’t describe the behavior very well: Specifying the goals on the command line simply adds them (in order) to the list of targets to be run, so parallel building behavior applies to them as usual.
That's what I observed too. So it may be that in the build failure that prompted me to file this ticket, the makefile's dependencies really are wrong. However, this may be a case where we can make a single small change to base which would have little or no effect on existing working ports but fix problems in a bunch of other ports and/or make portfile writing easier. I liken it to the small change we made to base some years ago to not run the destroot phase in parallel anymore—that should have worked too, but for many ports, it didn't, because makefile dependencies were wrong. -- Ticket URL: <https://trac.macports.org/ticket/45274#comment:4> MacPorts <http://www.macports.org/> Ports system for OS X
#45274: Run portbuild::build_main once for each build.target ---------------------------+-------------------------------- Reporter: ryandesign@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: base | Version: 2.3.99 Resolution: | Keywords: Port: | ---------------------------+-------------------------------- Comment (by larryv@…): Strictly speaking, this change would penalize ports with correctly-written makefiles that would otherwise benefit from having their command-line goals executed in parallel, but the number of ports satisfying this condition might be insignificant. And in such cases it would be trivial to patch in a new phony target, dependent on the required targets, and use that as `${build.target}`. So this seems like a good idea to me. -- Ticket URL: <https://trac.macports.org/ticket/45274#comment:6> MacPorts <http://www.macports.org/> Ports system for OS X
participants (1)
-
MacPorts