[Build-common-hackers] flavors: pass flavor-specific flags after DEB_CONFIGURE_EXTRA_FLAGS

Emilio Pozuelo Monfort pochu at debian.org
Sat Jan 8 15:31:26 UTC 2011


Hi,

I've already converted (and uploaded) glib2.0 to the flavors system :) I'm
really liking the flavors support in CDBS.

I'm converting gtk+3.0 now, and I've found a little issue:

We build 3 flavors, shared, udeb and static. What I would like to do is
something like

DEB_CONFIGURE_EXTRA_FLAGS += --enable-introspection=no
DEB_CONFIGURE_FLAGS_shared += --enable-introspection=yes
DEB_CONFIGURE_FLAGS_udeb += --disable-some-features
DEB_CONFIGURE_FLAGS_static += --enable-static

i.e. since most flavors shouldn't build introspection support, I disable it in
EXTRA_FLAGS (which is like "common flags"), and only enable it in the shared
flavor flags. This should result in calls like

./configure --enable-introspection=no $(curflavor_flags)

So the shared flavor would be like

./configure --enable-introspection=no --enable-introspection=yes

This means flavor-specific flags override common flags.

However this is not the case because in autotools.mk, flavor-specific flags are
appended to $(cdbs_configure_flags), and ./configure is called this way:

$(DEB_CONFIGURE_INVOKE) $(cdbs_configure_flags) $(DEB_CONFIGURE_EXTRA_FLAGS)
$(DEB_CONFIGURE_USER_FLAGS)

So _EXTRA_FLAGS get passed after flavor-specific flags.

This is easily fixable (I haven't tested it though) with a patch like the
attached one. I was wondering if anyone can think of a better way of doing this,
or whether I shouldn't do this now because it can cause FTBFS or change the
build behavior. I'm not sure how many packages are using CDBS flavors already,
or whether this will affect python-autotools.mk

Opinions?

Also while talking of flavors, the TODO file has

> * Handle packages which compile themselves several times with
>   different compiler flags.
>
> * Handle packages which build multiple versions with different ./configure
>   flags.

The second one seems like the flavors support, so we can remove it. And the
first one would be well supported by the flavors support if we supported
CFLAGS_$(flavor) (and CPPFLAGS, LDFLAGS etc) I guess.

Cheers,
Emilio


More information about the Build-common-hackers mailing list