everything in acinclude.m4 was something that aclocal should find from the dependency libraries and put in aclocal.m4. If people are having trouble, then they either need to install the dependency libraries development tools, or use a 'make distcheck' tarball that has an appropriately generated aclocal.m4 and configure script. Maybe setting up a daily CVS tarball could avoid some of the support problems.
I agree in principle, but having it there doesn't really hurt us, and does help out a minority of users who we would have to deal with, support wise.
Except when those upstream libraries change their macros, and we don't get the benefit. Also, it can be confusing to know which macro is being used if you keep your own copy but aclocal also grabs one. It took me a significant amount of time to figure that out. I urge you to stick to your principles on this one, not to simply "do what's easy". Can you perhaps point out an old thread or bug that has an example where not having the macros was an issue? another easy way to deal with those users is to say, if you can't figure it out, use a tarball, or a binary. I think this is reasonable. Not everybody needs to use the bleeding edge.
I have thought about daily tarballs, but the code really doesn't change that much unless we are building up for a release. Perhaps monthly, or something, but I just haven't been able to bring myself to see about getting that done. I guess I need to figure out demand for such a thing and that might better motivate me to do something about it. 
daily snapshots shouldn't be hard to set up in a cron job, assuming make distcheck is working correctly (I haven't tried it, but it looks like the Makefile.am's have mostly been maintained correctly). Of course, no tarball should be generated if nothing changed. the script should update a working copy, check if anything changed, call make distcheck, and move the resulting tarball. maybe something like this:
cd $CVSDIR
if test -n "$(cvs up 2>/dev/null | grep '^[PU]')"; then
make distcheck
mv $PACKAGE.tar.gz $DOWNLOADSDIR/$PACKAGE-$(date +%Y%m%d).tar.gz
fi
ah, well, the layout of the tree is non-standard enough that I missed the "tools" target in the top-level Makefile.am. 99% of top-level Makefile.am's have only SUBDIRS in them, so I'm not sure I ever even looked in there. I assumed they depended on libcode because they are in the code directory. Which brings up a completely separate point about using paths in Makefile.am's at all, and keeping your library code in separate places from your binary code.. I was going to leave such things for a later (series of) patches. Anyway, I'll take those parts out for now.[/li][/list]
Yeah, the source tree is really setup for MSVC, not what us Linux users work with. Xcode on OS X handles the current tree setup pretty well too, but that still doesn't make it any easier for automake.
I think any of these tools can deal with a sane source code layout. it's not so much conforming to what automake wants (automake can pretty much deal with anything anyway--it already is, afterall), but to what is logical. Also, maybe you don't need to maintain project files for 5 IDEs. One for each platform seems more reasonable to me. But, I suppose you don't want to leave some developers out in the cold.
