if you have a configure.ac script in your project, and it contains a line that says “AM_MAINTAINER_MODE”, you’re doing it wrong. period.
what this macro means is that changes to your Makefile.am will not automatically result in the Makefile being regenerated unless –enable-maintainer-mode is given to ./configure. i’m almost sure that this isn’t what you want. it’s also breaking jhbuild whenever you add a new source file (since people pull the updated version and end up trying to build it with the old Makefile).
*not* using “AM_MAINTAINER_MODE” means that your makefiles will always be updated in response to changes to Makefile.am.
“AM_MAINTAINER_MODE([enable])” is acceptable. this means that Makefile updates are enabled by default but you have the option to pass “–disable-maintainer-mode” to disable them. i personally think that this is stupid, but i understand that some distributions think that this is kinda useful for some strange reason. since it’s useful to them and causes no harm to me, this is actually what i recommend.
fredp made a report page for packages using AM_MAINTAINER_MODE. green mean no “AM_MAINTAINER_MODE” at all (good). yellow “low” means “AM_MAINTAINER_MODE([enable])” which is also fine (perhaps better than green, in fact). orange “average” means that your package is currently broken and needs to be fixed.
note: many packages attempt to work around this issue by passing –enable-maintainer-mode to ./configure at the bottom of their autogen.sh. i do not consider this to be a particularly good solution.
By not using AM_MAINTAINER_MODE you are just pissing off downstream distributors. It is not possible to distribute patched sources that are not using it.
I’d appreciate if people could stop wasting all efforts to have a sane build system. The correct line that fits everyone is AM_MAINTAINER_MODE([enable]), period. Not using it is a no-no.
I blame gnome-common:
AC_DEFUN([GNOME_MAINTAINER_MODE_DEFINES],
[
AC_REQUIRE([AM_MAINTAINER_MODE])
A bit of explanation – sometimes for miscellaneous reasons the timestamps of the assorted autotools related files will be messed up (maybe you pulled them out of an scm of some sort), and because often autotools is used in complex and not completely correct ways, when make attempts to rebuild the autotools junk it fails, although it would have succeeded at a normal build.
Sometimes if I really need to regenerate autotools stuff and it’s just not working (maybe I need to be running the right version of ubuntu with the right libtool version and autoconf version and automake version and who knows what) I just write a whole new Makefile from scratch.
I just discovered that even though Vino and Vinagre do not use AM_MAINTAINER_MODE in configure.ac, they were still marked as requiring fixing due to GNOME_MAINTAINER_MODE_DEFINES pulling in maintainer mode (without the [enable]). Nasty. I just fixed this in master, so thanks for the notification!
“””
“AM_MAINTAINER_MODE([enable])” is acceptable. […] i personally think that this is stupid, but i understand that some distributions think that this is kinda useful for some strange reason.
“””
It’s mainly useful if you patch the autotools-generated files (some maintainers swear by this practice, others swear *at* it) or if you aren’t confident that updated autotools will still be able to deal with your package (any GNOME project that actually gets updated should be fine, but some mostly-dead-upstream packages in Debian still expect automake 1.7).
I personally think the right route is:
* if you don’t patch autotools source, you could autoreconf but you don’t necessarily need to;
* if you do patch autotools source, run autoreconf before configure
* maintainer mode is irrelevant
but some maintainers prefer:
* patch the autotools source in the usual way
* have the results of running autoreconf with known-good autotools versions as the last patch in your patch series
* disable maintainer mode
or even:
* patch the autotools source, and include the results of autoreconf as part of that same patch
* disable maintainer mode
Some packagers do this, but I think it’s fundamentally wrong:
* patch only the generated files
* disable maintainer mode
I agree that if you want maintainer-mode support, AM_MAINTAINER_MODE([enable]) is The Right Thing; it’s a pity the default is “disable”.
[WORDPRESS HASHCASH] The poster sent us ‘0 which is not a hashcash value.
In the xorg world, AM_MAINTAINER_MODE is used in most if not all the modules. However, I recall the debian maintainer being adamant that it be disabled by default so that regeneration of the autotools files don’t happen automatically in their packages. He greatly preferred to keep control over that process himself. I could see both sides of that argument, but I typically prefer for the autotools to DTRT on their own.
On the other hand, I never noticed that not using AM_MAINTAINER_MODE at all leaves you with the behavior of AM_MAINTAINER_MODE([enable]). Just tested it out and sure enough it only serves to comment out things that are available in the default Makefile.
maintainer mode is pretty buggy under MSYS, it’s useful to be able to disable it there :)
Doesn’t the gnome-common autogen.sh automatically pass –enable-maintainer-mode to configure? If so, shouldn’t this have zero effect in building modules directly from version control?
If the makefiles regenerate and rerun configure, it should be passed the same options so it should again enable maintainer mode. In which cases is it actually causing a problem?
As of jhbuild I always set alwaysautogen variable in .jhbuildrc to True and I’m fine. I would even recommend having it as set to True by default.