[Lustre-devel] Build system and portability

Ken Hornstein kenh at cmf.nrl.navy.mil
Mon Apr 26 11:15:32 PDT 2010


>The autoconf portion is not terribly bad, I think.  It could probably
>use a bit of macro reorganization, and some more reasonable defaults for
>things like kernel, etc. but I am working on the latter currently.  It
>seemed a real mess to me at first, but the more I worked with it, the
>more I understood the organization of it.

Forgive me for implying otherwise; it's really more a bunch of
portability cleanup issues.  Like not doing Linux kernel feature tests
on non-Linux systems, that sort of thing (I guess those don't technically
harm anything, but there were a few things that would fail and those needed
to be system-dependent).

>Why we cannot/didn't just put the modules into it's own tree with kernel
>build system Makefiles and keep everything in a separate tree with their
>own non-kernel build system Makefiles... I am not sure, but as Andreas
>mentioned, is likely just due to the history and the baggage that has
>not been shed when support for historical systems was dropped.

Again, I'm not the expert on how kernel module building works ... but
there seems to be some interdependency in the current Lustre setup (the
Makefiles include Rules, which includes autoMakefile).  I would just be
happy if we could get down to one Makefile; is that possible, given the
way that Linux kernel module builds work?

Oh, as long as we're on the subject ... when I file portability bugs
using bugzilla, I am never happy with the component I have to pick to
file the bug under (I end up with something like "integration").  Can
we get a Bugzilla component titled "portability"?  Or if people are
happy with "integration" (or would rather I use something else), I
guess that's okay as well.

--Ken



More information about the lustre-devel mailing list