On Mon, 27 Jun 2011, Andrew Deason wrote:
On Sat, 25 Jun 2011 19:17:31 -0400 (EDT)
Benjamin Kaduk <[email protected]> wrote:
If that's the way of the future, I don't mind changing a bunch of
lines. I will note, though, that we need to retain (gain?) a way for
kernel sources to be compiled with different flags than userland. The
case that I tripped over most recently is that the (FBSD) amd64
userland build is compiling with PIC, but when I go to bsd.kmod.mk for
libafs, it adds mcmodel=kernel which is incompatible with PIC. (I
currently workaround this by emptying XCFLAGS for the libafs build,
but would like other options.)
_Everything_ is built with PIC? That doesn't seem right.
I guess this was already covered, but not everything. At least one object
file for the libafs build, though I don't remember offhand exactly where
the compiler bailed.
The AFS_*RULE method has a couple of ways of specifying more flags. If
you set MODULE_CFLAGS or MODULE_LDFLAGS to something, they'll get
applied to all AFS_CCRULE and AFS_LDRULE invocations for that makefile.
And if you set CFLAGS_target.o, it'll get applied for that target.
Ideally what everything would look like is
MODULE_CFLAGS = -some -libafs -specific -flags
...
CFLAGS_foo.o = -Dwhatever
foo.o: bar.c
$(AFS_CCRULE) bar.c
or no explicit rule at all if the default .c -> .o rule can pick it up.
Ideally you'd just use that, and set the relevant MODULE_CFLAGS or
CFLAGS_whatever based on whatever other variables.
libafs (and libuafs, etc) is the last big part of the tree that doesn't
really use those, unless there's other parts I'm forgetting. I _think_
this is just because there's a ton of platform-specific weird flags and
such passed around, and it's not often very clear what the rules are
actually trying to do. So it's not quite that it's just a dull and rote
Quite so -- once I got my bsd.kmod.mk build working, I went to install it
... to discover that 'make install' went and build another libafs.ko in
libafs/MODLOAD/MODLOAD ! The path is quite convoluted, jumping back and
forth between Makefile.common and MakefileProto.ARCH. (And at least in my
current hacked state, Makefile is regenerated for every command that is
run ....)
thing to go and change all of them; it's hard to see if it was actually
done right.
So, what I mean is, that's potentially a lot of work just to fix some
otherwise simple conflict in the fbsd libafs build. It'd be great if you
want to work through that, and I can probably help with verifying some
of the builds for platform-specific stuff, but I don't think it's the
required way; I don't have a problem with doing something that's a bit
easier short-term.
However, it seems easier to, instead of having CRULE_TARGET have
different ways of inferring which .c file to use, just change all of the
CRULE_* callers to explicitly list the source files, since we'd need to
do that anyway for AFS_CCRULE. That's probably the easiest way forward
(except it involves a lot of boring changes) and least-impact and afaik
fixes the issue you were looking at, so that may be the best thing to
do.
Changing the CRULE_* callers to explicitly list the .c file again seems
like my best option for now. I will probably file an RT ticket for
improving the sanity of the libafs build (unless we already have one), but
I think that falls behind a few other things on my priority list (like
kFreeBSD support and probably PAGs).
Thanks for the comments,
Ben
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
