Bug#432564: Proposalto introduce compiler options passed from dpkg-buildpackage

[Loïc Minier <lool@dooz.org>]

On Tue, Dec 11, 2007, Stefano Zacchiroli wrote:
> >  Nope, this is correct, "pyversions -vr debian/control" gives you "2.4
> >  2.5", not "python2.4 python2.5".  (In practice, I don't think there are
> 
> Yeah, but personally I wouldn't call Makefile targets as such, I would
> rather prefer to $(foreach ...) on the output of "pyversions -vr ..."
> (which IIRC was not in your posted example FWIW) in order to replace the
> bare version names with some more meaningful target names as
> "build-python2.4" or something such.

 Foreach isn't very readable in Makefiles, and really hard to write for
 expressions spanning multiple lines; I'd be curious how you intended to
 use foreach to replace the example I gave.

> >  I wouldn't lose anything; I don't think I would gain anything either;
> >  the point was that it isn't a good idea to call make as a method to
> >  check whether I implemented the build-arch concept.  In fact, I already
> 
> Well, if the example is the one you gave, I still think that it is the
> example itself which should be improved rather than took as a proof of
> concept that build-arch can't be detected that way.

 I don't understand what you find wrong about the example.  You probably
 came across CDBS which uses "%" in targets almost everywhere to
 transport the package name.  In the examples I gave, "%" transports the
 flavor (as in glib2.0, gtk+2.0, pango1.0, gtk2-engines...) or the
 python version; I find these are reasonnable use of this feature.  I
 honestly consider it elegant while you seem to suggest it's bad style.

 (But of course the point was not about whether this is good or bad
 style, but about whether the build-arch check being reliable.)

 I don't think the example needs fixing, but the implementation in my
 packages were checked to not conflict with build-arch.

>                                                     How many examples
> are around there like yours? I think they should be fixed nevertheless,
> and I don't even think there are many ...

 13 packages just in the official GNOME desktop+platform which is about
 half of pkg-gnome; this represents about 10/15%.  3 in pkg-gstreamer on
 about 23 packages, 10/15% again.  Most are Python or packages with
 multiple builds (like an udeb build with different flags).

 This doesn't speak for the archive at large, but still.

 Oh and the Wiki page on the new Python Policy also suggets this trick:
    <http://wiki.debian.org/DebianPython/NewPolicy>
 (and I didn't touch it! :)

-- 
Loïc Minier