On Thu, 6 Dec 2007 20:54:29 +0100, Loïc Minier <[EMAIL PROTECTED]> said:
> 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.
*Sigh*.
__> cat makefile
build-%:
echo $@
__> make build-foo
echo build-foo
build-foo
__> make build-arch
echo build-arch
build-arch
__> make -pn build-arch | grep '^build-arch'
build-arch:
OK?
> 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.
But at least it is a starting point.
> Process interfaces draw a much clearer line. I'm sure that as the make
> maintainer you do know how complex a Makefile can get.
You can write FORTRAN in any language, sure. But for the most
part, since we specify the entry points for the make call anyway, the
complexity does not matter, as long as the policy requements for
targets and ordering are met.
> 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.
With make as a starting point, most of this already present, and
even standardized. Make has a well known interface, it's behaviour is
also defined; we no longer have to reinvent the wheel.
>>> 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).
I do not think you have made your thesis that the alternatives
are better.
> > 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.
> 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.
What new channel? This channel (./debian/rules as a Makfile)
has been in practice since around 1996, and in policy as a mUST since
2001 (which was, I think, before you became a DD).
If you think it is new, you must not really have read policy
very well.
> 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.
Ah. Argumentum ad Hominem. "I can't refute Manoj's arguments, so
let us paint him as an irrational bigot". I am going to ignore this as
the logical fallacy that it is.
manoj
--
"Anger makes you smaller, while forgiveness forces you to grow beyond
what you were." -Cherie Carter-Scott
Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
