[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#428213: policy 4.9: minor (non-normative) patch for 'debian/rules build' explanation



On Sat, Jun 09, 2007 at 06:03:41PM -0500, Peter Samuelson wrote:
> The suggestions given in Policy 4.9 about a build target being empty
> and the binary target depending on other build targets seems a bit
> wrong - why would the build target itself not depend on the other
> targets?  I suggest a patch below, wording is borrowed from a paragraph
> about the binary target.

> This is not really a functional change, just explaining best practices.
> It's also not officially a proposal, as my key isn't in the keyring.

> --- policy.sgml
> +++ policy.sgml
> @@ -1738,17 +1738,10 @@
>  	      </p>
>  
>  	      <p>
> -		For some packages, notably ones where the same
> -		source tree is compiled in different ways to produce
> -		two binary packages, the <tt>build</tt> target
> -		does not make much sense.  For these packages it is
> -		good enough to provide two (or more) targets
> -		(<tt>build-a</tt> and <tt>build-b</tt> or whatever)
> -		for each of the ways of building the package, and a
> -		<tt>build</tt> target that does nothing.  The
> -		<tt>binary</tt> target will have to build the
> -		package in each of the possible ways and make the
> -		binary package out of each.
> +		<tt>build</tt> may be (and commonly is) a target with
> +		no commands which simply depends on <tt>build-arch</tt>
> +		and <tt>build-indep</tt> (see below), or on other
> +		targets split from <tt>build</tt> for readability.
>  	      </p>
>  
>  	      <p>

This patch seems to miss the point of the existing text, which is not about
build-arch vs. build-indep, but rather about a source package that must be
compiled twice using different options in order to generate all of the
binary (-> binary-arch) packages.  In that case, no, the build target
*should* be empty, because the implication is that you have to run a 'make
clean' between the two builds because you're building them both in place, so
there's no reason to give one of these configurations precedence over the
other by making it the 'build' target.

Now my own preference is definitely to use autoconf and VPATH and have a
separate build tree for each compilation, so that everything *can* be put
under the build rule; dunno if that should go in policy though.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/



Reply to: