On 1 Oct 2010, at 18:07, David Boyes wrote: >> Yeah, sorry. :/ We're not using Autoconf properly in a lot of ways. >> We're closer than we were, but the configure and build machinery still >> needs a lot of cleanup. > > I need to do some work in this area as well. Is there a set of requirements, > or at least a rough set of expectations as to what a rational build process > should do for OpenAFS, ie, what sort of packages does it need to build, > platforms, etc?
What follows is from a Unix perspective. In addition to this, we obviously have a completely separate Windows build process. I don't think we've ever really done any kind of requirements capture in this area. One of the problems is that the way that we build OpenAFS has diverged so dramatically across all of the supported platforms that we now have a multitude of different options to support... *) Transarc or normal paths *) Install or dest *) libafs.ko or openafs.ko ... Despite our best efforts, I would anticipate howls of anger if we were to kill off any of these. So the build system has to be able to support being many things to many people. Secondly, we build our source multiple times in many different ways ... *) For the kernel module *) For the userspace cache manager *) For the java cache manager *) Twice for the Apache plugin (this isn't currently built, and probably no longer builds, but the rules are there) *) For LWP libraries *) For pthread static libraries *) For pthread shared libraries (with -fPIC) The upshot of all of this is that if I add a new object file to AFS, I potentially have to modify 5 different Makefiles (6 if you count Windows). This is obviously prone to developer error. Ideally I'd like to have a single location that records, for example, RX objects which I can simply add an object to and have it build correctly for all of those build types. I did have a cunning plan for doing this within the existing system, but haven't yet had the time. Thirdly, we now have a very complicated set of feature probes to deal with different platform capabilities. Many of these are pretty standard, but we do a lot of complex things to ensure that we can build on many, many, different Linux kernels. Those are from the developer/packagers perspective. From the user's perspective the problem is that we look like a standard autoconf package. People expect these to work in a particular way, and we currently don't. So, we should work on taking CC (we do, on Linux) CFLAGS, CPPFLAGS, LDFLAGS and so on on the command line, and doing the right thing with them. The fact that we don't is largely to do with the complexity of the build system necessary to support all the different targets listed above. > How much restructuring of the build process is tolerable? The current one is > pretty messy, and really difficult to automate/test in any easy way. Would it > be feasible to scrap the accumulated cruft and fit it into a more modern > build framework like cmake? The main problem with moving to a different tool is that most of us understand autoconf and make. cmake adds an entire new layer of unfamiliarity, and in that respect is probably likely to be regarded with suspicion. Personally, I would rather see us improve the current system within the limitations of autoconf, make (and possibly automake), rather than throwing it all away to start again. Cheers, Simon. _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
