2.6 Makefile replacement for VPATH

2.6 Makefile replacement for VPATH

[Kyle Hubert]

Hi. I'm requesting information about how to handle a VPATH situation
for drivers in the 2.6 build, with the corresponding solution that we
have.

I refer to VPATH with regards to the situation where you can have
multiple Makefiles target the same source file to build different
objects. In particular, we are using the same source file recompiled
with different options to be able to support different devices.

This is where VPATH can help in the GNU Makefile tradition. Yet, the
2.6 build system has multiple stages to build driver modules, and as
such the VPATH variable is not carried forward. How do other people
handle this?

If you use an obj-m that refers via relative directories to the source
file, ie: "../src", then the two resulting object files have the same
name and the last compiled one will be listed in
.tmp_versions/drv.mod. This will be the only one linked into an
drv.ko.

If you use a multi-object, ie: drv-objs, then you can split the two
drivers into two different names. Each multi-object's parts are
compiled and linked into the multi-object's .o during the compilation
stage, and two .mod files will be created. Thus, two .kos will be
linked during the final stage. This appears to be a solution. However,
during the compilation stage, the two multi-objects will recompile the
original "../src/src.o" intermediary object. This affects the date of
the intermediary .o, and each subsequent execution of the Make command
will consider it a candidate for recompile, and the two drivers will
be rebuilt, regardless of any source code changes.

How do others handle this? Do they just move their driver outside of
the kernel Makefiles so they can iterate through the two builds via
traditional Make routines?

Thank you,
-Kyle Hubert

Re: 2.6 Makefile replacement for VPATH

[Sam Ravnborg]

> I refer to VPATH with regards to the situation where you can have
> multiple Makefiles target the same source file to build different
> objects. In particular, we are using the same source file recompiled
> with different options to be able to support different devices.

Several obvious solutions.

a) Let the same driver handle multiple devices - we do this in very often.

b) Keep all shared functionality in a dedicated lib* module, and
have thin wrappers for the actual drivers. See libata for example.

c) The ugly where you have a thin dedicated .C file for each driver
that includes the source they share.

> How do others handle this? Do they just move their driver outside of
> the kernel Makefiles so they can iterate through the two builds via
> traditional Make routines?
That will most likely not work.

	Sam

Re: 2.6 Makefile replacement for VPATH

[Kyle Hubert]

On Thu, Jun 25, 2009 at 07:47:48PM +0200, Sam Ravnborg wrote:
> > I refer to VPATH with regards to the situation where you can have
> > multiple Makefiles target the same source file to build different
> > objects. In particular, we are using the same source file recompiled
> > with different options to be able to support different devices.
>
> Several obvious solutions.
>
> a) Let the same driver handle multiple devices - we do this in very often.
>
> b) Keep all shared functionality in a dedicated lib* module, and
> have thin wrappers for the actual drivers. See libata for example.

Neither one of them were options for us, since header files also have
macros for defining MMR addresses in the hardware. This can change
from device to device, so the code becomes more complicated to
organize that in a shared driver/library.

> c) The ugly where you have a thin dedicated .C file for each driver
> that includes the source they share.

Thanks for the suggestion. We tried this, and it does indeed solve our
problem. It may be ugly, but it's the cleanest of the four solutions.

Thank you for the response,
-Kyle Hubert