[OpenAFS-devel] Re: [RFC] splitting out CRULE_TARGET from libafs/Makefile.common

[Andrew Deason]

On Sat, 25 Jun 2011 19:17:31 -0400 (EDT)
Benjamin Kaduk <kaduk@MIT.EDU> wrote:

> > Shouldn't libafs makefiles just be converted to use AFS_CCRULE ?
> 
> Maybe?  I'm still finding my way around our build system.

Sorry, yeah. What I meant was more like: I think these should just be
converted to AFS_CCRULE, but I'm not the most familiar with those rules
and what the intention for them was, so I'm not completely sure.

> 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.

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
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.

-- 
Andrew Deason
adeason@sinenomine.net