> I don't think we've ever really done any kind of requirements capture > in this area.
OK. Here's some thoughts I had: Should: Run on Linux, Solaris, AIX, Irix for certain; others? Generate build configurations for native tools to build; Allow overrides for common tools Desirable to also generate Windows Visual Studio build configurations Must permit option specification and provide sane defaults. Should support native packaging options (RPM, DEB, pkgadd/IPS, AIX, Irix) as well as leaving the binaries in a directory with 'make install' to do the deed Basic build logic: 1) Determine platform and build environment, and create header file with the local details 2) Build common parts like libraries (build the variations as separate targets, based on the interrogation in 1) 3) Build server components if desired (part of interrogation) 4) Build cache manager components if desired 5) Build userspace components if desired 6) Execute tests (if available) 7) Build packages (if desired) The comment above about driving native tooling is kind of interesting in that you'd be able to start managing the source in the way you want (eg, saying here are a list of components separate from dealing with the actual make files themselves, and let the tool generate the make files for the appropriate platforms). At least that's how cmake does it. You would end up with something like this for the build process on all platforms: 0) put source tree somewhere 1) mkdir /someconvenientdir-for-binaries 2) cd /someconvenientdir-for-binaries 3) cmake <sourcetree> 4) make 5) make test 6) make install (optional) 7) make package The same method works on Windows, except it can also generate VS workspaces. > 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. Isn't that the case with any build tool other than the status quo, however? I'm not married to cmake; it just struck me as one reasonably successful tool that manages a code base of comparable complexity for lots of platforms (KDE uses it). I don't know if anyone is using it to build kernel modules, but a little experimentation is probably in order. > 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. At some point the current build system will collapse of its own complexity. I'd like to ask the question of what else could we use before we reach that point. _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
