On Thu, Apr 12, 2012 at 8:20 PM, Russ Allbery <r...@stanford.edu> wrote: > Jason Edgecombe <ja...@rampaginggeek.com> writes: >> On 04/12/2012 02:34 PM, Russ Allbery wrote: > >>> runtests itself assumes that something else will handle this, since for >>> all of my other projects I use libtool. OpenAFS is somewhat unique >>> among projects using that test driver at the moment in its reinvention >>> of that wheel. (For reasons that I understand; libtool has its bugs >>> too, of course. But this is something that it normally handles >>> reasonably well with current versions.) > >> is there a reason why we shouldn't use libtool? licensing perhaps? > > I believe that we should use both Libtool and Automake, but the amount of > work required for a transition is immense, and will also require working > with the upstreams of both projects to resolve bugs. OpenAFS is more > broadly portable than a lot of free software, and has some interesting and > special build system challenges (such as the separate build of kernel > modules). > > I've looked at doing this incrementally a few times, as have other people, > but it's a very difficult change to make incrementally, and the amount of > effort required is daunting. It's generally far easier to make > incremental improvements to our current ad hoc arrangement of shell > scripts with portability testing on the platforms we know we care about.
Yeah. I did the first autoconf support while on a train to Boston, and because it wasn't overly ambitious, it was doable. Incremental automake is much harder. Personally, I hate automake, and I find libtool's .lo pollution to be tedious but at least bearable. Sadly, all the other options suck differently, including the status quo. Derrick _______________________________________________ OpenAFS-devel mailing list OpenAFS-devel@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-devel
