Re: Environment variables, debian/rules and dpkg-buildpackage
On Sun, May 10, 2009 at 09:54:11PM +0200, Raphael Hertzog wrote:
> On Sun, 10 May 2009, Steve Langasek wrote:
> > I'm really surprised to see this approach getting traction. To me, this
> > seems like a significant, unprecedented departure from the kinds of
> > interfaces we've mandated in Policy in the past (i.e., environment
> > variables, executables and command-line options). While one build helper or
> > another may mandate Makefile includes, there's never been anything of the
> > sort in Policy, and I don't think it's good to add such a thing now. I
> > thought it was generally recognized that it's a Bad Idea to implement config
> > files using your interpreter's 'include' functionality, but that's basically
> > what we have here.
I have sympathy for Steve viewpoint however it lacks an alternative proposal.
However I cannot only strongly disagree with Raphael argument below:
> Another negative aspect of the include approach is the lack of
> tracability. Right now when the user overrides a build flag it appears
> in the build log since dpkg-buildpackage prints it out in the log:
> dpkg-buildpackage: use CFLAGS from environment: -O3 -Wall
>
> With the include approach, we lack this feature and bad/broken local
> overrides can't be detected if we only have the build log at hand.
There is nothing that prevents a future dpkg-buildpackage to
cat to stdout the relevant files at startup so that they appear
in the buildlog.
Cheers,
--
Bill. <ballombe@debian.org>
Imagine a large red swirl here.
Reply to: