diff mbox series

build: explicitly specify Makefile generator

Message ID 20231008165428.109029-1-wolletd@posteo.de
State New
Headers show
Series build: explicitly specify Makefile generator | expand

Commit Message

Eicke Herbertz Oct. 8, 2023, 4:54 p.m. UTC 
From: Eicke Herbertz <wolletd@posteo.de>

When CMAKE_GENERATOR environment variable is defined, CMake will use the
specified generator by default instead of "Unix Makefiles".
This breaks the build of packages setting PKG_USE_NINJA to 0, like
package/kernel/mt76.

Signed-off-by: Eicke Herbertz <wolletd@posteo.de>
---
 include/cmake.mk | 4 ++++
 1 file changed, 4 insertions(+)

Comments

Jonas Gorski Oct. 9, 2023, 10:22 a.m. UTC | #1 
On Sun, 8 Oct 2023 at 18:56, <wolletd@posteo.de> wrote:
>
> From: Eicke Herbertz <wolletd@posteo.de>
>
> When CMAKE_GENERATOR environment variable is defined, CMake will use the
> specified generator by default instead of "Unix Makefiles".
> This breaks the build of packages setting PKG_USE_NINJA to 0, like
> package/kernel/mt76.

Where does that CMAKE_GENERATOR environment variable come from? Would
it make sense to undefine it instead?

Regards,
Jonas
Eicke Herbertz Oct. 9, 2023, 1:03 p.m. UTC | #2 
> 
> Where does that CMAKE_GENERATOR environment variable come from? Would
> it make sense to undefine it instead?
> 
> Regards,
> Jonas

Well, from the environment of my development machine.
I have it set to Ninja for a long time on this system.

Do you mean undefining it manually or as part of the build process?

I'd dislike having to manually undefine it. It's a documented behaviour
of CMake since v3.15 and it's tedious to run "make -j1 V=s" to figure
out the issue first.

As part of the build process, I find explicitly defining the Makefile
generator better communicates intent than undefining an environment 
variable and depending on CMake's default (although that probably won't 
change).

Regards,
Eicke
Rosen Penev Oct. 9, 2023, 6:37 p.m. UTC | #3 
On Mon, Oct 9, 2023 at 6:05 AM Eicke Herbertz <wolletd@posteo.de> wrote:
>
> >
> > Where does that CMAKE_GENERATOR environment variable come from? Would
> > it make sense to undefine it instead?
> >
> > Regards,
> > Jonas
>
> Well, from the environment of my development machine.
> I have it set to Ninja for a long time on this system.
>
> Do you mean undefining it manually or as part of the build process?
>
> I'd dislike having to manually undefine it. It's a documented behaviour
> of CMake since v3.15 and it's tedious to run "make -j1 V=s" to figure
> out the issue first.
I have said before and will say it again: cmake.mk needs to be using
toolchain files instead of these command line shenanigans.
>
> As part of the build process, I find explicitly defining the Makefile
> generator better communicates intent than undefining an environment
> variable and depending on CMake's default (although that probably won't
> change).
>
> Regards,
> Eicke
>
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
diff mbox series

Patch

diff --git a/include/cmake.mk b/include/cmake.mk
index 95870ffdb0..32e94d384b 100644
--- a/include/cmake.mk
+++ b/include/cmake.mk
@@ -68,6 +68,8 @@  ifeq ($(HOST_USE_NINJA),1)
   define Host/Uninstall/Default
 	+$(NINJA) -C $(HOST_CMAKE_BINARY_DIR) uninstall
   endef
+else
+  CMAKE_HOST_OPTIONS += -DCMAKE_GENERATOR="Unix Makefiles"
 endif
 
 ifeq ($(PKG_USE_NINJA),1)
@@ -80,6 +82,8 @@  ifeq ($(PKG_USE_NINJA),1)
   define Build/Install/Default
 	+DESTDIR="$(PKG_INSTALL_DIR)" $(NINJA) -C $(CMAKE_BINARY_DIR) install
   endef
+else
+  CMAKE_OPTIONS += -DCMAKE_GENERATOR="Unix Makefiles"
 endif
 
 define Build/Configure/Default