>>> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes:
>>>>>> "Olaf" == <[EMAIL PROTECTED]> writes: [...] Olaf> while the clobbering of the make output is a considerable Olaf> problem -- it's hardly possible to see what is beeing done or to Olaf> find compiler messages among all the garbage :-( ) Tom> I agree, that's a problem. I'm concerned by the fact that Automake shows the call to the `depcomp', but not the calls done by `depcomp' (i.e. the real calls to the compiler). I think the former is nice to debug Automake or depcomp, but the user really needs the latter (so he can reproduce the compilation commands issued by depcomp from the shell if needed). Several times I've been annoyed by the fact the `depcomp' adds flags to the command line but doesn't show them. http://sources.redhat.com/ml/automake/2001-12/msg00065.html is one case where Libtool is confused by these extra arguments, and it's hard to figure what happens until you realize that extra parameters have been secretly appended. Personally, I'd prefer that Automake generates Makefiles that shows *every* calls. This would make debuging (at any level) and bug reporting easier. Maybe Automake could support a trick similar to PRE_INSTALL and POST_INSTALL to hide most of the output. E.g. if the user set `VERBOSE=:' in the Makefile.am or on the command line, only the final calls to the compiler are printed. (Or do the converse: verbose output on request.) Tom> I personally always compile in Emacs. Then I don't have to look for Tom> the output, I just let C-x ` do it for me. But I realize this doesn't Tom> work for everybody. During development I usually compile with `-Werror', this way I can never miss a warning and they are easy to locate (always in the last lines). [...] -- Alexandre Duret-Lutz
