Received: by 10.223.176.46 with SMTP id f43csp3408169wra; Mon, 22 Jan 2018 13:47:16 -0800 (PST) X-Google-Smtp-Source: AH8x227/ZB199zV22s0oOhSI+OkQFT1geSmK9wy7Ej3Rc19a3AcT5L6b4wBJOkJ4Ubjvv+L2DgH+ X-Received: by 10.107.69.3 with SMTP id s3mr533039ioa.67.1516657636365; Mon, 22 Jan 2018 13:47:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516657636; cv=none; d=google.com; s=arc-20160816; b=dtk5RKHV+TSJdb/TJ8dGIfz5eQBfnPRbS7QgAndlPJpFuIrfZ2YLL3XQfHIOSik9yR DKNl7AyZXEER6PCR+ap8ahGgGiyp9l5plNfYR4+xAwgsZaLWIbpdt6txZyEDsLxXLEUs l9g4WDJkQtyACoPakW9/h5e0LmFtsBYhi0u4QbRU9Pyj+NF5c2zS/YV02cvhhbcZDnCV JuSsVXgrZrUDfDIcG49uSwL5glsdGg5z5z4ScEufaWUQL9QMVi0x27iMDKqBK3IJZQga 8dtdk5ubBpj5y4Fv5zofZ2GKpDmajWs40SsXdUWOP1rAXguFITrn3zNIkfyNaw9Cx0Ax iuSg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:subject:cc:to:from:date:dkim-signature :arc-authentication-results; bh=1mL7HReGk2dY3E3Ue7VIh9GUPZKPUeFbFjHKOq5z1Yg=; b=NthgOmRUEl3FwmxeVKxnVHMG2Tp+G60dH0DYz/qTNO65v9NRMRQPoAXM4te/Y/rrN8 KdXJytnKMV/ldxpL+lt4RknJhaIjJITQuf6EpvCSSb49cZv0kcDyMMKSN/9nI/4fTZ0i qN9Rers4QRu8E7FCQmhwQd4HPClaU9Ei01hzihNYlYyY/hA0wRMCzFaWez3rwgAAU2Gp IhP/9Dw/2MTBI4svAJRHFk7vXvoNGceaToxqqze8DK+5Suxmohy93nXdE6tNfeh5zLcy NWK6V9TQOvquKQ7LT0K0egbCyeyzx6f8Knci7xyqXgnGCNO6kabmHX5soBF4QjeTg9hc LZlg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass (test mode) header.i=@wp.pl header.s=1024a header.b=Fkz05lnF; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a31si6678891itj.25.2018.01.22.13.46.53; Mon, 22 Jan 2018 13:47:16 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass (test mode) header.i=@wp.pl header.s=1024a header.b=Fkz05lnF; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751115AbeAVVqW (ORCPT + 99 others); Mon, 22 Jan 2018 16:46:22 -0500 Received: from mx3.wp.pl ([212.77.101.10]:54174 "EHLO mx3.wp.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750909AbeAVVqU (ORCPT ); Mon, 22 Jan 2018 16:46:20 -0500 Received: (wp-smtpd smtp.wp.pl 14894 invoked from network); 22 Jan 2018 22:46:17 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wp.pl; s=1024a; t=1516657578; bh=1mL7HReGk2dY3E3Ue7VIh9GUPZKPUeFbFjHKOq5z1Yg=; h=From:To:Cc:Subject; b=Fkz05lnFEBZfZc6WtuSm9YJ59BQMzareE9CxycL1jWYPZsgj53ao+H2JcMbVIOkxs qMhdkw744crFgOsGPDpRJHOT0bFb2zszev3u3xRnZNlHr0A7K0SPjIb7d+EH7qPVc+ AAznolTxLqGaBWxKl3/3ialx4PCV+OWyKE4WAB6g= Received: from unknown (HELO cakuba.netronome.com) (kubakici@wp.pl@[75.53.12.129]) (envelope-sender ) by smtp.wp.pl (WP-SMTPD) with ECDHE-RSA-AES256-GCM-SHA384 encrypted SMTP for ; 22 Jan 2018 22:46:17 +0100 Date: Mon, 22 Jan 2018 13:46:07 -0800 From: Jakub Kicinski To: linux-kbuild@vger.kernel.org Cc: LKML Subject: Mutli-directory module Makefiles Message-ID: <20180122134607.00d77101@cakuba.netronome.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-WP-MailID: 4dfc948e534b9b21cb3328dcb09110d5 X-WP-AV: skaner antywirusowy Poczty Wirtualnej Polski X-WP-SPAM: NO 000000A [oSP0] Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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?