Thanks for the report.
I will try to reproduce it locally.

Can you try to attach the outut of the build with the flag: V=1 added to the
make commnad line - this enables some more verbose output from kbuild.

Unfortunately V=1 gives me no additional output (although that in itself 
may be meaningfull to you) - I guess since GNU make evaluates its own
makefiles as targets before considering any other targets.

I could attach the output of "make -d" if you want...

Created attachment 8897 [details]
output of "make -d"

I found something interesting, from examining the make debugging output
generated with make -d, it looks like the kernel makefiles are using a VPATH
that is finding a prerequisite in _my_ build environment (from which it was
recursed into).

So, If I check-out my build tree, and then unpack the kernel build tree,
I have no problems since the kernel makefiles are _newer_ than the makefiles
found in _my_ SCCS directories.

If I go on to modify and commit my own makefiles locally, it starts breaking
because the kernel wants to update _its own makefiles_ based on the fact that
my SCCS/s.Makefile is newer.

While the problem is clear to me now - and could be fixed by avoiding vpath
evil in kernel makefiles, I do not propose that it be fixed - the way a program

compiles itself with its own makefiles is entirely its own bussiness. A proper
fix would be to provide some proper compiler flags to the module builder so 
that the module builder can build on its own.

Created attachment 8898 [details]
workaround patch

I am currently reverting this line in the toplevel kernel makefile
to workaround the problem, it seems to be working ok.

Any update on this problem?
Thanks.

The bug is thus:

By way of the VPATH line in the master kernel makefile, the makefile
is saying that my personal kernel module's directory should be taken 
into account as "One of the kernel directories".

This assumption is obviously false, I have my own revisioned files
in my own build sandbox and my own rules which apply to update files
in that sandbox.

What should happen ? :
   - The kernel makefiles should have a clean rule that will invoke
     make in my directory without inheriting all the rules of the kernel
     make mechanism (just .ko:.o, .o:.c)
or even better:
   - The kernel should simply have a pkg-config like program or even textfile
     to let module authors know what are the correct compile flags and
     include paths to compile a module with.

What is the status of this problem? has it been resolved?
thanks.

I dont work for the same company anymore and dont have the setup
to test the latest build.

If you are still using the VPATH variable in the makefile, and
expecting your build to work in someone else's module directory,
then I expect it to still be a bug yes.

In the end, you cant really publish your build system and expect
it to work in someone elses environment, it will have different
bugs for people who have different environments.

You also cant really expect people to archive the compiled .ko
files in their build systems (i.e. imagine that to rebuild to
kernel module for a given build tree, you had to check out the
kernel source and build it by hand and commit the .ko file
just to satisfy the dependancy... it just doesnt work that way).

Documenting the kernel flags is also out of the question
(i.e. in the older days you just had to read the docs and
put -DMODULE etc on your build line... since these days the
required build flags may change alot, its just a nightmare
to maintain these kinds of docs).

So in the end the only real solution would be for the kernel
to output a kernel module .pc file, even if it had to output
a different one for different driver subsystems and directory
levels - nobody would have to explicitly know or transmit the
compile flags, and they would always be available for a given
kernel dist.

Hi Tristan.

> If you are still using the VPATH variable in the makefile, and
> expecting your build to work in someone else's module directory,
> then I expect it to still be a bug yes.
kbuild continue to use VPATH and it works well in almost all cases.
In this particular case it seems that kernel module source where
mixed with some other source file otherwise the mentioned bug
should not trigger.

> You also cant really expect people to archive the compiled .ko
> files in their build systems (i.e. imagine that to rebuild to
> kernel module for a given build tree, you had to check out the
> kernel source and build it by hand and commit the .ko file
> just to satisfy the dependancy... it just doesnt work that way).
The build system will build the .ko file if told so and it is
missin or any prerequisite has changed - like anyone would
expect. So to build a module you will need the prepared
kernel source (tools built etc).
That is the only supported way to build kernel modules.

So unless you convince me otherwise I do not consider this a bug.

	Sam

(In reply to comment #9)
> Hi Tristan.
> 
> > If you are still using the VPATH variable in the makefile, and
> > expecting your build to work in someone else's module directory,
> > then I expect it to still be a bug yes.
> kbuild continue to use VPATH and it works well in almost all cases.
> In this particular case it seems that kernel module source where
> mixed with some other source file otherwise the mentioned bug
> should not trigger.
> 
> > You also cant really expect people to archive the compiled .ko
> > files in their build systems (i.e. imagine that to rebuild to
> > kernel module for a given build tree, you had to check out the
> > kernel source and build it by hand and commit the .ko file
> > just to satisfy the dependancy... it just doesnt work that way).
> The build system will build the .ko file if told so and it is
> missin or any prerequisite has changed - like anyone would
> expect. So to build a module you will need the prepared
> kernel source (tools built etc).
> That is the only supported way to build kernel modules.
> 
> So unless you convince me otherwise I do not consider this a bug.

Generally you do not distribute build systems, sure this is
fine for any kernel module that is included and built inside
the kernel tree, those must be integrated in the kernel build
tree anyway.

But the reality is that people need to build their own modules
that link in the kernel, and these people will want to build thier
kernel modules in an automated way in their own build systems.

As much as you are not convinced that building kernel modules
outside of the kernel tree is a requirement - I dont see any convincing
reason for the kernel to be an exception to the standard: to 
build modules, libraries and objects, you need a set of compiler 
flags to be provided, and binaries possibly to be linked against.

Imagine firefox made you use their own makefiles and build
firefox every time you wanted to use the embedding api - currently
this is almost the case but at least they are working on
a proper sdk (now I believe its the xulrunner dist if you manage
to compile it).

At any rate, if you insist that distributing a build environment
is an acceptable way to provide compilation support to module/driver
developers, then this one does have bugs - because in this 
particular case the kernel makefiles are making assumptions about
irrelevent files that are found in my own build directory (IMO
use of VPATH is the culprit in this case - using exact file lists
based on variables passed to the kernel makefiles, at least
for externally built modules would avoid these assumptions).

Just because what you guys are doing is different from everybody else
doesnt mean I can say its wrong, but Im sure alot of build headaches
for everyone involved could be saved by biting the bullet and just
dumping the proper compile flags into a generated file that may differ
between kernel builds and systems - Im sure it would be easier for 
you to maintain than trying to maintain these distributed makefiles.

-Tristan

Hi Tristan.

It has been discussed to provide a external-module-sdk which
would be a subset of the relevant files from the kernel.
But there has not been any push for it and noone has come up with
a patch either - so for now this is not supported.

> But the reality is that people need to build their own modules
> that link in the kernel, and these people will want to build thier
> kernel modules in an automated way in their own build systems.
Use:
cd dir_with_module; make -C KERNEL_DIR M=`pwd`

and if any prerequisites are outdated - your module will be build.

> As much as you are not convinced that building kernel modules
> outside of the kernel tree is a requirement - I dont see any convincing
> reason for the kernel to be an exception to the standard: to 
> build modules, libraries and objects, you need a set of compiler 
> flags to be provided, and binaries possibly to be linked against.
The kernel is much more dynamic in the configuration
than most other project which is why building kernel
modules needs interaction with the kernel.
It is not enough to provide flags, we need the config too and
the correct headers from a properly configured kernel tree etc.
Things are a bit more complicated than just providing a single
file would fix all cases.

I will close this bug - but I will be happy to see a serie of
patches to either get rid of VPATH and/or to introduce
proper linux-dev-sdk support.

	Sam