From: Jakub Kicinski <kubakici@wp.pl>
To: linux-kbuild@vger.kernel.org
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Mutli-directory module Makefiles
Date: Mon, 22 Jan 2018 13:46:07 -0800 [thread overview]
Message-ID: <20180122134607.00d77101@cakuba.netronome.com> (raw)
Hi!
in drivers/net/ethernet/netronome/nfp there is a module which is built
from C sources in 4 directories. What is the best way to handle that?
Currently we just add all the objects in one Makefile:
nfp-objs := \
nfpcore/nfp6000_pcie.o \
nfpcore/nfp_cppcore.o \
etc.
However, this makes it impossible to build a single object in subdirs:
$ make drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cppcore.o
scripts/Makefile.build:45: drivers/net/ethernet/netronome/nfp/nfpcore/Makefile: No such file or directory
make[2]: *** No rule to make target 'drivers/net/ethernet/netronome/nfp/nfpcore/Makefile'. Stop.
Documentation/kbuild/modules.txt also contains an unclear remark that
this is not recommended (or is it about the use of $(src)?):
--- 4.3 Several Subdirectories
...
To build the module complex.ko, we then need the following
kbuild file:
--> filename: Kbuild
obj-m := complex.o
complex-y := src/complex_main.o
complex-y += src/hal/hardwareif.o
ccflags-y := -I$(src)/include
ccflags-y += -I$(src)/src/hal/include
As you can see, kbuild knows how to handle object files located
in other directories. The trick is to specify the directory
relative to the kbuild file's location. **That being said, this
is NOT recommended practice.**
Making the include optional would work:
diff --git a/scripts/Makefile.build b/scripts/Makefile.build
@@ -42,7 +42,7 @@ save-cflags := $(CFLAGS)
# The filename Kbuild has precedence over Makefile
kbuild-dir := $(if $(filter /%,$(src)),$(src),$(srctree)/$(src))
kbuild-file := $(if $(wildcard $(kbuild-dir)/Kbuild),$(kbuild-dir)/Kbuild,$(kbuild-dir)/Makefile)
-include $(kbuild-file)
+-include $(kbuild-file)
# If the save-* variables changed error out
ifeq ($(KBUILD_NOPEDANTIC),)
Or we could create empty Makefiles in subdirectories... Is there a
better way of handling this? Which is preferred?
next reply other threads:[~2018-01-22 21:46 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-22 21:46 Jakub Kicinski [this message]
2018-01-25 13:08 ` Mutli-directory module Makefiles Masahiro Yamada
2018-01-25 19:47 ` Jakub Kicinski
2018-01-27 22:28 ` Masahiro Yamada
2018-01-25 20:42 ` Sam Ravnborg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180122134607.00d77101@cakuba.netronome.com \
--to=kubakici@wp.pl \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox