Re: Proposalto introduce compiler options passed from dpkg-buildpackage
On Thu, Dec 06, 2007, Manoj Srivastava wrote:
> >> d) stands in the way of technical proposals like passing information
> >> to the build system on the command line
> >> e) prevents people from relying on make semantics for builds.
>
> > The two above points are the same argument. The only proposal I know
> > it stands on the way of is the one to list implemented targets with a
> > special make invocation which seemed flaky anyway.
>
> [...] unimportant, if indeed it works.
I got the feeling it was flaky from the criticism I read on
debian-policy@ and that it couldn't work for all Makefiles; for example
someone proposed to "make -f debian/rules -pn | grep '^build-arch:'"
but this obviously wont fly if this is implemented as a "build-%:"
rule.
In fact I have packages with build-% rules, and certainly they
shouldn't match such checks as they don't implement build-arch.
> > Not constraining the interface if we don't need to? There's a huge
> > difference in possibilities between "any script" and "a Makefile".
> I do not agree that there is no need to so constrain it. I have
> made the argumen in #88111; please read it.
I did; I don't think you can reliably include a Makefile written by
somebody else with the only constraints of the current policy. It
would require tons of policies to make this reliable.
Process interfaces draw a much clearer line. I'm sure that as the make
maintainer you do know how complex a Makefile can get. It seems much
more easy to usefully standardize the behavior of a process (flags /
arguments, exit code, env vars, external deps, current working
directory: sounds sane) than of a Makefile.
> > Yes, we can do it in other ways, such as defining which flags or env
> > vars have to be honored, or which files have to be read.
> Right. We can re-invent the wheel on our own, in a classic
> example of NIH, for absolutely no reason -- apart from not liking a
> solution that is already in place.
I disagree that it's for no reason; some proposed uses aren't safe and
we have better replacement proposals (such as using a control field or
an env var).
We already proved the use over many more years of env vars passed to
debian/rules, arguments passed on the command-line, or of data in
debian/control. Proposing to use the new channels such as makefile
inclusion or querying for the implemented rules is looking for trouble
and discourages other options.
I'm not under the impression that you're still open-minded on the
topic, and since you're one of our beloved policy maintainers, and make
maintainer, I don't think it's worth our time to repeat the arguments
which have already been made.
I simply want it recorded that some people do think it's a bad idea
to require debian/rules to be a Makefile; I hope it will discourages
people to rely on this.
--
Loïc Minier
Reply to: