Bill Allombert <bill.allomb...@math.u-bordeaux1.fr> writes:
> 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,
$(info CFLAGS = $(CFLAGS))
in the makefile sniplet.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
