>>>>> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
Bo> I can not imagine a way to trigger autogen.sh from Makefile after Bo> a file removal/rename. I do not know autotools well either. If Bo> there is a way to do this and we can not figure it out after ten Bo> years, it is autotools' fault. When you remove/rename a file, Makefile.am is changed (because the file list is changed) and automake is run automatically. This part is not a problem The real problem is that it breaks the dependency checking scheme. Bo> I had a horrible experience when I try to compile lyx under Bo> windows (using both mingw/cygwin to get automake version right). Bo> That directly triggered my development of scons. I agree that Bo> autotools are generally available under *nix, but version Bo> compatibility can be a problem, and if that happens, installation Bo> of missing parts is non-trivial. I think version compatibility is not a problem anymore. The big problems is that we enforced automake 1.9, and we do not need to anymore. Jose', what about lowering the requirement? Bo> I experience this several times. Something like wrong boost Bo> version (autotools do not check the exact version of boost), wrong Bo> qt installation, wrong command line option. configure passes but Bo> make fails. It is difficult to perform such checks in m4, but very Bo> easy in python. What kind of checks do you do? Since I have little interest in non-local boost, I never got to add a version check, but these things are a matter of cut-and-paste IMO. Bo> We have a recent post: "I always run autogen.sh; configure; make Bo> before I post here". He means: make can fail, but when that Bo> happens, start from autogen.sh and see if the problem can be Bo> resolved. Yes, and some people want to reinstall windows when word does not work anymore :) Seriously, I think I reduced drastically the need for autogen.sh recently (thanks to your gentle nudge :). JMarc
