I mostly agree with this; however, a few nits and comments.
>> 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 libafs.ko versus openafs.ko isn't that big of a deal compared to the rest. but yes. > *) 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) LWP will be dying obviously. pthread versus pthread-PIC could be handled today with make rules. the java cache manager *should* become a special case of the userspace cache manager. this is other work and in truth is probably a better use of time than rewriting the make system first. > 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. Well, it's better and worse. You only want some subset of those things in each case; I'd rather that be coded per-module with ifdefs than per (class of) makefile. Then it's obvious why I don't have function X in the kernel: the source makes it obvious. And you have one list of files built for things where it might matter: "all of them". Some just happen to provide nothing. > 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. We never can, in some sense, unless we force people to build as root or have 2 sets of behavior, one if root, one if not. Make install should install a kernel module, right? Well, ... > >> 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. does cmake buy us anything if we're assuming builders (as opposed to developers) don't have it installed? never mind suspicion: if we can do it without screwing people who are building and it improves their lives, we should examine it. forcing another dependency to be able to build, on the other hand, is probably a poor choice. _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
