Blog
Stuff
- Amazon Wishlist
- Amazon.de Wishlist
- Books Read
- Facebook Profile
- Gallery Photos
- LinkedIn Profile
- Ohloh Profile
- Openismus
- Twitter Profile
Syndication
Flickr Photos
Now Reading
Now Listening
Recent Posts
- What our Trainees Learn
- Openismus Wants More Trainees
- Glom 1.13/14 using boost::python
- Openismus Website Now More Shiny
- In Helsinki at the weekend, Monday and Tuesday
Del.icio.us Bookmarks
- Daviey » Article » Anything but the buttons!
How to fix Ubuntu Lucid's stupid (and unexplained) window title button position. - PHORMS München: PHORMS München
Bilingual school in Munich - Glade: Bug 587256 – GtkVBox and other classes have incorrect default orientation property value
Glade is currently completely broken. - Massif Visualizer - now with user interaction | Milian Wolff
- --: Oliver Jeffers :--
- Ovi - FAQ
"How can I manually setup the Ovi sync settings for my device when I am unable to receive sync settings via SMS" - GtkSourceView Widget and Glade 3
- Those pesky buttons
Silliness. - Abstruse Goose » How to Teach Yourself Programming
- API - Facebook Developer Wiki
Sounds good, but the link that he added as part of the patch is dead (http://members.pcug.org.au/~millerp/rmch/recu-make-cons-harm.html) :(
I completely agree with your post. I (and some coworkers) have wrote a build-system template using autotools with “state of the art” techniques and one of them is, for sure, the single Makefile.am approach.
The template is well documented and should be useful to whoever is starting a project or wants to migrate to a modern autotools build-system, take a look:
http://svn.ademar.org/code/trunk/autotools-build_system-template/
It’s very complete but yet modular. It supports pkgconfig, libtool, check (unit-tests in C), lcov (coverage reports for C/C++), doxygen, gcc warnings, debug mode, etc.
Patches are always welcome as well.
Cheers,
– Ademar
Getting rid of libtool or at least making it a complete no-op on all *sane* configurations (w/ shared library linking & recursive lookups) and do funny stuff on the architechtures that don’t would be a huge improvement. This dumbing down of linking for 99% of all users is terrible.
Automake can be painful, but libtool is just completely bogus nowadays.
Old Havoc’s post about this: http://log.ometer.com/2007-07.html#14
Related article: Recursive Make Considered Harmful (http://www.xs4all.nl/~evbergen/nonrecursive-make.html).
We’re using non-recursive make in gjs.
Oops, correct link to the article: http://aegis.sourceforge.net/auug97.pdf
I am at least glad that there is movement in the Autoconf section too.
For the longest time I thought autoconf devs dont care at all about complaints due to “legacy” reasons.
I just hope that the net result of all those moves – including binutils gold linker – will eventually lead to an
improved build time experience for BOTH developers, distribution packagers and “powerusers” who often
feel left out in decisions imposed onto them by upstream (just look at the craziness of autoconf cmake scons
libtool and so forth).
Computers get fast and faster but software concepts get worse and worse – or dont improve as fast.
“.”: That’s what dolt does (unfortunately there’s no project page, bug google for “dolt libtool”). And yes, my template already includes it. :-)
Can I still do
cd src/libsubproject-library
make
This way? Or do I have to run make in the project’s root always?
@Stefan: Ooops, thanks for the note. I didn’t realize the page had moved. I have corrected the link in the comment now.
@pvanhoof: No, you can’t do that anymore. That’s about the only downside. However, there is nothing preventing you from creating a named phony target for a logical subset of your targets, if you need that ability.
Also note that this isn’t an all-or-nothing decision. You can combine recursive and non-recursive make as you like. Even the new build system of glom still recurses into the po/ and docs/user-guide/ directories, because the associated tools for these parts ship with their own makefiles. (Note that it is possible to list docs/user-guide in the toplevel Makefile.am — it does not have to be an immediate child.)
For reference, here is the link to the Makefile.am in HEAD: http://git.gnome.org/cgit/glom/tree/Makefile.am
Apart from the fixed link, you will also notice that the huge file has been split into functional parts now. Since Automake implements include files itself, you don’t even have to require GNU make for that.
@mark: To put things into perspective:
This is by no means a recent development in the Autotools world. Automake has included explicit support for non-recursive make for a couple of years now! Actually, you got your history exactly the wrong way around. :-) Years ago, the Autotools developers pissed off a lot of people mightily when they made the incompatible switch from Autoconf 2.13 to Autoconf 2.50 and from Automake 1.4 to Automake 1.5. What we now call the “modern” Autotools interface actually had its roots back then. Anything since then has mainly been an incremental improvement upon those major new releases years ago.
The main problem is that a lot of configure.ac (or even still configure.in) files and Makefile.am files I see in the wild do their work the old way from about ten years ago, except for the necessary compatibility adjustments to make things barely work with the newer releases. And this is not surprising given that new projects usually copy the build infrastructure of some other existing project. And that’s fine, not everyone is a crazy nutcase like me who actually enjoys all this stuff. The trick is to know where to copy from. ;-)
ah thanks, that’s a useful trick; I didn’t know, even if I’ve been using autotools for years.
Autotools may have its problems and peculiarities (like combining the sh, m4 and make languages), but as of yet, I haven’t see anything that could take it’s place — maybe this quagmire thing? I can sympathize with people from a non-Unix background who suddenly have to get up to speed with autools… it will take a lot of googling, copy-pasting, and things that just don’t work…
Once you’re past that, it’s not too bad.
Hello,
I recompiled some info about build tools in Gnome/GTK+ here: http://live.gnome.org/JavierJardon/NewBuildSystem
Maybe we can add a new column for modules that uses Non-Recursive Automake. Any help would be very welcome ;)
Regards
Quite a few projects changed from autotools to cmake and they are quite happy with it. and it is really easyer than autotools after a day or 2 of studying. and one *really* large project changed quite a time ago, making it a guinea pig for testing and succeded. ( and it’s nice to see the percentage of the build gently scrolling up )
World needs no alternative to Autoconf/Automake. Both “tools” should simply be gone. Most of the time, they aren’t helping, just adding to the mess.
For me, the ultimate bliss would be to have the Makefile.ams in subdirectories, and automake creates a single, big top-level, non-recursive Makefile.in out of them. (And puts stub Makefiles in the subdirectories so that I can run make there.)
OK, as you are now the second person asking for the ability to run make in a subdirectory, I’d interested in your use case(s) for this. Specifically, would you need to ignore targets not in the chosen directory, or is it merely a convenience for “make -C ..”? It would be trivial to write a script to automatically do the latter.
@Daniel: perhaps a bit unconventional, but I keep my (unit) test cases within the same folder of the library code. When writing new or adjusting existing code I am only interested in that part of the source tree, nothing else. I also use the `subdir-objects’ over the use of convenience libraries as it has come the my notice the latter can introduce a fair amount of additional bloat.
I do think however, that in case your project has somewhat reached a maintenance only stage, a single rooted Makefile.am might be more beneficial.
When looking for “non-recursive makefile” on internet, I found examples of still structured but non-recursive layout. Ie, you still define piece of Makefile in each directory containing a “buildable”. This piece of Makefile is then read by a global Makefile.
This is really interesting because a single big BIG Makefile.am is not an easy way to maintain the building process (IMHO). Spliting the building process in many files, containing rules related to files hosted in the same directory is really much more simpler to maintain.
Does someone know a way to do such thing with automake?
I’m curious how people have dealt with being able to run make in each subdirectory. I’m assuming a layout where there’s one top level Makefile.am that includes Makefile.am’s in each subdirectory. The build directory ends up with a Makefile but subdirectories in the build directory don’t. That’s where I’d like Makefile’s to end up.
Do people add Makefile.in’s to each subdirectory that do something like this (untested):
all:
make -C @top_builddir@
(with the appropriate AC_CONFIG_FILES call in configure.ac)
What else have people tried?
Thanks.
-DB