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

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-%:"
   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: