On Thu, Jul 04, 2002 at 01:01:15PM -0600, Tom Tromey wrote: > >>>>> "Nathanael" == Nathanael Nerode <[EMAIL PROTECTED]> writes: > > [ moved to the automake list ] > > Nathanael> On the other hand, the better I understand Automake, the > Nathanael> more I HATE it. > > Over 1 million now served. I hate McDonald's too. :-)
> I found your message pretty irritating, since it is just a bunch of > assertions without any real supporting evidence. Please help us make > tools better; random "automake sucks" flamage is pretty useless. Sorry. > Nathanael> It makes it waaay easier to generate nasty, stupid > Nathanael> dependency problems. > > Can you explain this comment? Yes. <rant> Automake is quite good at generating dependencies for things which behave 'normally': C files compiled to O files with the same name, & so on. In fact it appears to do so via ordinary suffix rules. Automake does little or nothing to help generate dependencies for unusual cases; it can't, no automated tool can. What it does do is to demand extra work for the maintainer in order to tell Automake that theses *are* unusual cases. This isn't positive for dependency handling. > Nathanael> It does a poor job of getting dependencies right > > And this one? I think automake does a very good job here. We've > spent a lot of time on dependency tracking. I'm not talking about automatic dependency generation for C headers; that's really a separate issue in many ways. I'm talking about the same thing I'm talking about above. I guess what I'm saying is that I like a tool which makes things simple, but not TOO simple. I think automake oversimplifies, to the point where it's making assumptions about the nature of files and how they're used, which are only true some of the time. Although it allows you to override its assumptions, doing so is generally harder than writing a raw Makefile. (At least for someone who understands Horn clauses! Don't they teach PROLOG in CS departments any more?) I have a philosophical bone to grind here, and I admit it. I think developers ought to write out the dependencies in their build. It's great to say "let's do it automatically", but it *can't* be done automatically, because each project is structured differently. It's wise to allow developers not to write dependencies *twice* (hence automatic C header dependency generation, since the dependencies are written in the C and H files already; also the information in 'clean' rules is in many ways redundant with specified dependencies). It's wise to allow developers to specify a whole bunch of similar dependencies at once (suffix & pattern rules, autogenerated rules). I don't think it's wise to tell developers that a program will 'take care' of their dependencies, and unfortunately that's the message being sent out by automake. Makefile dependencies are easy to write if you have the first clue about how 'make' works, and you know what your dependencies are. The message sent by automake, sadly, is "Make is a bad tool. Make is hard to use." [ Makefile *rules* are another matter; 'make' was designed with the idea that all rules would be simple one-liners, but it can be hard to actually write rules in that form. Libtool *helps* write rules in that form, which is why I like it. :-) One of the primary (good) uses of Make macros was to allow rules to be written in that form, but that use is mostly obseleted by autoconf subsitutions now, really. I have a lot of respect for the rather slick definitions of 'COMPILE' and 'LINK' used by automake, although the nested use of macros is worrisome from a speed point of view. It's not as unhealthy as the use of macros in dependencies, though. ] > Nathanael> I don't see an easy way of fixing most of the problems even > Nathanael> with a complete rewrite (although some of the functionality > Nathanael> could be better implemented with a few command-line > Nathanael> enhancements to 'make'... but that's a complicated other > Nathanael> story). > > The whole point is not to require changes to make. If we could do > that, then we could eliminate a lot of automake. Or just use a better > tool to start with. There's actually a subtle concept I had here, which is why I said it was another story. The command line options I want would only be used by maintainers, or for diagnostics, and would not need to be present in the 'make' used by people building and installing. I want the ability to see what the dependency tree looks like once all the macros have been expanded, *without* looking at all the rules. But as I said, it's another story. Make isn't a bad tool, it's an abused tool. (It does have a typo-diagnosis problem, true.) There really isn't a better way to express dependencies than Make's way, although better ways of getting alternative information out of the dependency tree would admittedly be lovely. > Nathanael> An example of this is the way *Automake* uses libtool. Not > Nathanael> libtool itself, but the way automake uses it. > > Please explain. Yes. Automake thoughtfully specifies the same libtool command and simplistic dependencies for all objects being built. This is *sort of* nice. In the 10-20% of cases where you want weird behavior, you have to write it by hand. Which *would* be fine, except that automake documentation tells you that you don't need to write it by hand, libtool documentation is less than would be desirable on using libtool without automake (the information's actually mostly there, in fact, but its use is actively discouraged), and automake-generated Makefiles are often nearly undecipherable. Automake allows for great customixation at the linking level (all done with Makefile macros) which is in contrast to its treatment of what it considers 'intermediate' files. </rant> --Nathanael
