I have a love-hate relationship with autotools. I love the thought of a parallel universe where it doesn’t exist, and hate it with the fiery passion of 1000 suns the rest of the time. I just released Conduit 0.3.3 and have had some reports of some build errors. The recurring build error is basically something like
Running intltoolize…
Running aclocal-1.4…
aclocal: configure.ac: 18: macro `AM_PATH_PYTHON’ not found in library
The problem is, by some combination of luck and ignorance I have never been able to reproduce this or fix it (on Ubuntu). The additional confusion is that Conduit is python, so I understand even less of the interaction of autotools. I therefor have an offer;
I will happily pay the person who fixes the horrible autotools setup in Conduit a crisp $NZ50. This cool cash can be redeemed from me in person at linux.conf.au, in cash or beer form, or I will buy the lucky person a piece of FOSS memorabilia (example) to that value.
That means fixing the above bug, deleting autofoo files that don’t do anything, checking that the translation stuff is setup optimally and generally making it less shameful and easier to follow. The person will also receive additional love points if they implement a skeleton autotools setup for documentation and for themed application icons. Remember, I hate autotools this much…
http://ianbicking.org/docs/setuptools-presentation/
Just ditch autotools and use setuptools instead, wine-doors is switching to it soon
Surely the aclocal: configure.ac: 18: macro `AM_PATH_PYTHON’ not found in library error is caused by either:
1) python’s devel stuff not being installed
2) python’s devel stuff being installed in a different prefix to where aclocal is looking.
I’d suspect the latter
Automake might have been installed to /usr/local in which case it’ll look in /usr/local/share/aclocal/ but the python stuff may be in /usr/share/aclocal
Or it may have been installed to /usr but python might have been installed to /usr/local
The solution is often to call aclocal $AC_LOCAL_FLAGS where the user defines AC_LOCAL_FLAGS in their environment to pass all the paths necessary to find all the files. like -I/usr/local/share or something.
As a suggestion for the short term build problem, I wonder if using a later version of autotools would help? Conduit seems to require autotools v1.4 at the moment. However, under Ubuntu Feisty the automake1.7, automake1.8 and automake1.9 packages all include a file called python.m4 whereas automake1.4 doesn’t. I see you’ve included a python.m4 file in conduit/m4 but I don’t know how to tell aclocal to look at that directory to find it.
Add the -I ./m4 to the aclocal call. -I tells it to look in the supplied directory for the m4 files
Personally, I’d dump autoconf for python use. It’s far too locked to the notion of a c compiler being the primary use, and things like python being addons.
The AM_PATH_PYTHON is supplied on Ubuntu by the automake* packages, and that should be being provided by your already using the AM_INIT_AUTOMAKE macro with version 1.9. Not sure why that’s screwing up, but what you can do to work around this is to copy your system’s python.m4 (probably /usr/share/aclocal-1.9/python.m4) into the m4 folder.
Oh, and adding ‘AC_SUBST(ACLOCAL_AMFLAGS, “-I m4″)’ (without the ‘) somewhere below the initial block of stuff should help fix various annoying maintainer mode related issues i.e. when configure gets auto-rebuilt due to a change in configure.ac.
I’m not sure why you need any of the PKG_CHECK_MODULES stuff, given the lack of C code, but you might want to change the dbus check to something that looks for python-dbus instead, as right now it’s looking for the dbus C headers… Also, what needs DBUS_SERVICES_DIR?
That’s everything I can think of offhand.
Do you have a bug report or a common case so that it will be easier to track the failure? It builds fine on my debian machine too.
Conduit’s python.m4 is missing AM_PATH_PYTHON. You could just include /usr/share/aclocal-1.10/python.m4 from the automake package in Ubuntu.
I love the Autotools, and would cheerfully do a tutorial for you once I arrive back from travelling in mid-September. If you’re interested, drop me an email jbailey@raspberryginger.com. No cash required. =)
autotools is a broken fix around the big design mistake that gnu=-make is anyway.
AM_PATH_PYTHON is automake-1.x or later, your autogen.sh was running automake-1.4, so it broke. No idea what minimal “x” is, 1.9 is good enough for anything unless you are using autoconf-2.60 (another funny thing). You have to specify automake version in some way, in configure.ac or by explicitly running automake-1.9, aclocal-1.9, etc. automake is neither backward nor forward compatible, so you have to deal with it. Or do nothing and see bugs like this. Or use something better, some people say it’s an option.
Thaks a lot everyone!.
Based on patches from Jonny Lamb, Rodney Dawes, and from suggestions in this post (AC_SUBST(ACLOCAL_AMFLAGS, “-I m4″) the -I m4 stuff, and requiring a specific autotools version, conduit autotools are a lot less busted.
Note for anyone now attempting to use autoconf / automake on Conduit 0.3.4, to save them the day of headscratching I had: unless you’re using exactly automake 1.9.6, you need to run aclocal. However, now Conduit ships its own aw35um h4×0r3d .m4 files, this will break everything. You should run:
ACLOCAL=”aclocal -I ./m4″ autoreconf
and it’ll work. John, do you really need to h4×0r the .m4 files? :\