That sounds like a nice design. But I don't like the "unpacked
automatically" part -- would it unpack *each* time you run the build?
Here's my variation on the above:
* Makefile in extras/ assumes that any file foo.c is a standalone
module to be installed as foo.o in the "extras" section
* Makefile further assumes that directory bar/ is a standalone module
to be compiled with its own Makefile; said Makefile is responsible
for creating bar/bar.o, which will of course be installed in the
"extras" section
* other files (baz.h etc) are ignored by extras/Makefile
* user is responsible for untarring things
* hmmm, what to do with MODVERSIONS / genksyms?
> I got as far as getting it to unpack before my limited knowledge of
> the kernel makefile and build system became a problem and I ran out
> of time.
I think I could code it. Anyone interested?
> You could even run a mini version of xconfig on the subdirectory to
> allow users to configure it.
I can't think of a real clean way to do *that*. For the same reason, I
can't think of a real clean way to use this scheme for non-module code.
-- Peter Samuelson <sampo.creighton.edu!psamuels>- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/