Re: EXTRA_DIST respects Automake conditionals?
Hello Ben, * Ben Pfaff wrote on Thu, Jul 30, 2009 at 04:57:08AM CEST: > I was surprised today to discover that EXTRA_DIST respects > Automake conditionals. I think you are the first person to report this, but thinking about how generally conditionals more or less cover file creation and installation, but only less than more cover distribution, I see that this makes perfect sense to assume. In fact, we have at least one open bug report to the opposite where it was undesirable to distribute some file that was conditionally not used. Generally, it might be necessary to introduce more than one kind of conditionality here, or, in practice, introduce prefixes that declare that some item is to be conditionalized not only for creation and installation, but also for distribution. Not sure whether that will suffice for all kinds of use cases. For example, could a user want to let COND1 govern creation and installation only but COND2 also govern distribution? If yes, then we'd need to think about something more general, like another type of conditional. In the particular case of EXTRA_DIST, there is only one semantic attached to this variable: distribution. So, barring the need for another type of conditional, it would be sufficient to add another variable that unconditionally distributes things. Changing the current semantics seems like way too dangerous a thing to do I think. As a workaround, as you say, you could use noinst_HEADERS; can't think of any better off the top of my head. Cheers, Ralf
Re: EXTRA_DIST respects Automake conditionals?
Hi Ben, The reason this works is because of the way AM Conditionals are implemented. If a conditional is true, then all contained statements are in effect. Otherwise, all contained conditions are commented out in the resulting makefile. Regards, John On 7/29/2009 8:57 PM, Ben Pfaff wrote: I was surprised today to discover that EXTRA_DIST respects Automake conditionals. In other words, if I have the following Makefile.am: AUTOMAKE_OPTIONS = foreign EXTRA_DIST = if COND bin_PROGRAMS = foo foo_SOURCES = foo.c EXTRA_DIST += EXTRA endif and configure.ac: AC_INIT([mumble], [1.0]) AC_CONFIG_SRCDIR([foo.c]) AC_CONFIG_FILES([Makefile]) AM_INIT_AUTOMAKE AC_PROG_CC AM_CONDITIONAL([COND], [false]) AC_OUTPUT then "make dist" will not put EXTRA into the generated tarball. It will put foo.c into the tarball, though. Is there an appropriate target to put files that should always be distributed, regardless of conditionals? noinst_HEADERS works, but to me it feels like abuse to use it for this purpose. For what it's worth, in the actual project where I encountered this, the usage is more like this: if ENABLE_USERSPACE ... include lib/automake.mk include ofproto/automake.mk include utilities/automake.mk include tests/automake.mk include include/automake.mk include third-party/automake.mk include debian/automake.mk include vswitchd/automake.mk include xenserver/automake.mk if HAVE_CURSES if HAVE_PCRE include extras/ezio/automake.mk endif endif endif In other words, I'm using a conditional to disable a great many features, and it's convenient not to push that conditional down into all the included files. Here's the Makefile.am in question: http://openvswitch.org/cgi-bin/gitweb.cgi?p=openvswitch;a=blob;f=Makefile.am;h=dccb8cfdf92a3dd4dc9f3276e7533f68769587f8;hb=c2b070214097fa40dc78252882d96babe7fab4b4 Thanks, Ben.
EXTRA_DIST respects Automake conditionals?
I was surprised today to discover that EXTRA_DIST respects Automake conditionals. In other words, if I have the following Makefile.am: AUTOMAKE_OPTIONS = foreign EXTRA_DIST = if COND bin_PROGRAMS = foo foo_SOURCES = foo.c EXTRA_DIST += EXTRA endif and configure.ac: AC_INIT([mumble], [1.0]) AC_CONFIG_SRCDIR([foo.c]) AC_CONFIG_FILES([Makefile]) AM_INIT_AUTOMAKE AC_PROG_CC AM_CONDITIONAL([COND], [false]) AC_OUTPUT then "make dist" will not put EXTRA into the generated tarball. It will put foo.c into the tarball, though. Is there an appropriate target to put files that should always be distributed, regardless of conditionals? noinst_HEADERS works, but to me it feels like abuse to use it for this purpose. For what it's worth, in the actual project where I encountered this, the usage is more like this: if ENABLE_USERSPACE ... include lib/automake.mk include ofproto/automake.mk include utilities/automake.mk include tests/automake.mk include include/automake.mk include third-party/automake.mk include debian/automake.mk include vswitchd/automake.mk include xenserver/automake.mk if HAVE_CURSES if HAVE_PCRE include extras/ezio/automake.mk endif endif endif In other words, I'm using a conditional to disable a great many features, and it's convenient not to push that conditional down into all the included files. Here's the Makefile.am in question: http://openvswitch.org/cgi-bin/gitweb.cgi?p=openvswitch;a=blob;f=Makefile.am;h=dccb8cfdf92a3dd4dc9f3276e7533f68769587f8;hb=c2b070214097fa40dc78252882d96babe7fab4b4 Thanks, Ben. -- Ben Pfaff http://benpfaff.org
