Modestas Vainius wrote: > Policy defines parallel=n. n is NOT optional. `dpkg-buildpackage -j` sets > some > bogus value -1 (aka unlimited?) which is not supported by policy... Yeah, it > seems that thing is really a bit broken.
Since policy has no way to specify unlimited, I assume this behavior is
intentional. I suppose debhelper can support it.
> However, I'm a bit concerned about the fact that there is no way to tell
> dh_auto_* (-> makefile.pm) not to pass -jX to make at all (i.e. defined $this-
> >get_parallel() in makefile.pm:do_make() will never be false). Some packages
> might need this. In parallel branch, this used to be the case when --parallel
> was not specified at all (hence set_parallel() never got called and
> $opt_parallel defaulted to undef). Now set_parallel() is always called and
> always defines $opt_parallel to some value. Maybe --max-parallel=-1 for this
> (since --max-parallel/--max-parallel=0 is already an alias for "unlimited")?
Perhaps we can wait to see if there is any use case for this before
worrying about it? Only use case I can think of is a package that
somehow builds using two dh_auto_builds, and can do it in parallel.
Something like:
build: build-foo build-bar
build-foo:
cd foo && dh_auto_build
build-bar:
cd bar && dh_auto_build
Here parallel=4 would cause up to 8 concurrent jobs to run,
which is too many. So you might do:
build: build-foo build-bar
export MAKEFLAGS=-j4
build-foo:
+cd foo && dh_auto_build --max-parallel=-1
build-bar:
+cd bar && dh_auto_build --max-parallel=-1
Now the two builds would run, sharing a jobserver.
But isn't this a clearer way to do the same thing?
build: build-foo build-bar
export MAKEFLAGS=-j4 # really, calculate from DEB_BUILD_OPTIONS
build-foo:
$(MAKE) -C foo
build-bar:
$(MAKE) -C bar
(It also has the bonus of working, since dh_auto_build
will fail if foo/debian/control doesn't exist.)
--
see shy jo
signature.asc
Description: Digital signature
