Raphael Hertzog <hert...@debian.org> writes: > From the whole discussion, relying on Standards-Version was not well > accepted so the only sane way of doing it (and parsing make's output is > not sane enough for me, even if debhelper does it) is to have the > package explicitly record that it provides the required support in a new > control field, something like "Build-Features".
And I think there was general support for doing this for build-arch/build-indep support. But every time it comes up... > The not-so-evident part is that I want the syntax of this field to be > sufficiently extensible so that we can encode more information like > support of hardening build flags and similar stuff that we might want to > know to adjust the behaviour at build time. ...it gets derailed by this feature request for Build-Features, which a lot of people are much more dubious about (myself, for example: I think hardening flags should be handled similarly to parallel build flags, not via Build-Features). So I think solving this problem via the Build-Features route is going to keep struggling as long as that's always closely linked to using Build-Features to change compiler flags. IMO, Build-Features should declare interfaces and capabilities that the source package supports, not a desire for the build system to change other things about the build environment. I think we have a good way forward for handling hardening flags now with your proposal to externalize acquiring build flags from another program, which debian/rules can then invoke with appropriate options depending on what sorts of flags the source package wants. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87iq1rvzf7....@windlord.stanford.edu
