On Oct 1, 2010, at 2:46 PM, David Boyes <dbo...@sinenomine.net> wrote:
>> 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?
Linux Solaris MacOS AIX would be the 4 I'd pick in that order if just 4. Then
BSDs, then Irix, then HPUX
> 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
it's gotten simpler recently and further simplification seems in near-term
grasp._______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
