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

[Benjamin Kaduk]

On Mon, 27 Jun 2011, Andrew Deason wrote:

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