There is normally no need to rerunning configure, since t is done automatically. autogen.sh s indeed a problem, but I suspect it is our fault and it should work automatically.
I can not imagine a way to trigger autogen.sh from Makefile after a file removal/rename. I do not know autotools well either. If there is a way to do this and we can not figure it out after ten years, it is autotools' fault.
Except that autotools (in unices at least) is already there and there is nothing to install. Note that, since my checking from yesterday) we do not need automake 1.9 anymore and I propose to reduce the needed value to something like 1.5 or 1.6 (have to check).
I had a horrible experience when I try to compile lyx under windows (using both mingw/cygwin to get automake version right). That directly triggered my development of scons. I agree that autotools are generally available under *nix, but version compatibility can be a problem, and if that happens, installation of missing parts is non-trivial.
Bo> Reliability: scons > autotools Bo> autotools may fail after successful configure because of Bo> incomplete check. What do you mean?
I experience this several times. Something like wrong boost version (autotools do not check the exact version of boost), wrong qt installation, wrong command line option. configure passes but make fails. It is difficult to perform such checks in m4, but very easy in python.
Bo> scons seems to be better. Also, autogen.sh and configure may be Bo> needed from time to time, and you can know that only after make Bo> fails. And there?
We have a recent post: "I always run autogen.sh; configure; make before I post here". He means: make can fail, but when that happens, start from autogen.sh and see if the problem can be resolved.
Well, this is in the eye of the beholder. Personally, I can do m4/sh much better than python.
I meant 'majority'. Ask someone who do not know either language or read configure.ac and Sconstruct and he can tell. We replace lib/configure.sh with lib/configure.py because many more people can understand and tweak it.
Bo> In summary, scons can almost replace autotools, but not now. Note that I am not saying that scons should not replace autotools. The main problem that I have with it actually is that it is not generally available on all unices and that I would be surprised if it worked out of the box on the nonlinux unices. The tweaks that will be necessary to make it work will remind us why autotools make sense :)
I generally agree with you on this, although I do not expect 'work-out-of-box' for nonlinux systems for autotools either. Someone should donate a macbook to me so that I can make scons work on a mac though. :-) Cheers, Bo
