On Sunday 14 June 2009, Kevin Bowling wrote: > Indeed, autotools are not a magic bullet. However, > maintaining our own build system seems unnecessarily time > consuming.
It is often presented as a magic bullet. The "old" build system takes nearly zero time to maintain. I would estimate that the total time invested in Gnucap's use of autotools is at least a thousand times the total time invested in the old system, which dates back to when "shar" files were the usual distribution mechanism, and hasn't really been updated since. The "old" build system is really just plain old "make", with a tiny configure script to provide an interface like autotools, for those who want it. Where autotools generates a monstrosity of a Makefile, the "old" system cats three pieces, each one is simple. I think I have a pretty good grasp on what it will take to make the "old" build system do what it needs to do, and where to steal the code. (Autotools, of course.) Every time I try to do anything with autotools, I give up in frustration. But, some people like it, so it is provided for them. > It also will make it hard for users to build > Gnucap on platforms we don't have access to. A lot of this > comes free with auto*. Considering that in my experience, auto* rarely works correctly on mainstream systems, I shudder to think what it is like on a non-mainstream system. Before auto*, I could always figure out what to hack. On Sunday 14 June 2009, Kevin Bowling wrote: > Having two build systems is both confusing to > users/developers and cumbersome. My vote is to take the time > now and fix one or the other, and only carry it in the > default package. I have confidence that autotools can be > made to work since many complex projects make use of it. I don't have confidence in it. Aside from the fact that I haven't figured out how to gracefully turn debugging features on and off, how to simultaneously do multiple builds with different options, and lots of other things that are trivial with plain old "make", it seems that most of the time I try to build some package that uses autotools, it doesn't work and the messages are not at all useful at figuring out what is needed. Just compiling and letting it fail gives more useful information. I am still bewildered about the relation between autotools and "libtool". It seems to me that if autotools is doing its job, libtool isn't necessary. There is a new challenge now with plugins, that I think is satisfied by the "old" system and not by the new one .. With the "old" system, a plugin only needs the first part of the Makefile, and you can compile with just "make". So, if the choice is one or the other, let's COMPLETE the old one. I think that is easier than FIXING autoconf. Also, I think the world would appreciate it. Done right, it could be as much of an improvement over autoconf as Git is over RCS. _______________________________________________ Gnucap-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnucap-devel
