[lldb][test] Prefer gmake to make and warn for potentially non-GNU make

[DavidSpickett]

System make on FreeBSD is missing some GNU make features so out of the box you get a lot of:

make: "<...>/Makefile.rules" line 569: Invalid line type

To solve this, you can install gmake which is a port of GNU make. However because we prefer 'make', gmake won't be used unless you set LLDB_TEST_MAKE.

To fix that, prefer 'gmake'. Also check (as best we can) that the make we found is GNU make. This won't be perfect but it's better than the cryptic error shown above.

-- Found make: /usr/bin/make
CMake Warning at /home/ec2-user/llvm-project/lldb/test/API/CMakeLists.txt:63 (message):
  'make' tool /usr/bin/make may not be GNU make compatible.  Some tests may
  fail to build.  Provide a GNU compatible 'make' tool by setting
  LLDB_TEST_MAKE.

When a make isn't found at all, the warning message will show the names we tried:

-- Did not find one of: gmake make
CMake Warning at /home/ec2-user/llvm-project/lldb/test/API/CMakeLists.txt:69 (message):
  Many LLDB API tests require a 'make' tool.  Please provide it in Path or
  pass via LLDB_TEST_MAKE.

[llvmbot]

@llvm/pr-subscribers-lldb

Author: David Spickett (DavidSpickett)

Changes

gmake is GNU make where make is not GNU compatible. This leads to a lot of tests failing to build
with errors like:

make: "<...>/Makefile.rules" line 569: Invalid line type

See https://cmake.org/cmake/help/latest/variable/CMAKE_SYSTEM_NAME.html for the platform names.

Tested on Linux and FreeBSD. Not tested on NetBSD, but the logic was always "if netbsd or freebsd use gmake" so I think I'm safe to assume NetBSD will be fine with this.

---

Full diff: https://github.com/llvm/llvm-project/pull/119573.diff

1 Files Affected:

• (modified) lldb/test/API/CMakeLists.txt (+9-2)

diff --git a/lldb/test/API/CMakeLists.txt b/lldb/test/API/CMakeLists.txt
index 36f4973ad9a452..66eccff297a999 100644
--- a/lldb/test/API/CMakeLists.txt
+++ b/lldb/test/API/CMakeLists.txt
@@ -52,11 +52,18 @@ set(LLDB_DEFAULT_TEST_DSYMUTIL "${LLVM_TOOLS_BINARY_DIR}/dsymutil${CMAKE_EXECUTA
 if(LLDB_TEST_MAKE)
   set(LLDB_DEFAULT_TEST_MAKE ${LLDB_TEST_MAKE})
 else()
-  find_program(LLDB_DEFAULT_TEST_MAKE make gmake)
+  set(MAKE_NAMES "gmake")
+
+  # "make" on FreeBSD and NetBSD is not GNU make compatible.
+  if(NOT CMAKE_SYSTEM_NAME STREQUAL "FreeBSD" AND NOT CMAKE_SYSTEM_NAME STREQUAL "NetBSD")
+    list(APPEND MAKE_NAMES "make")
+  endif()
+
+  find_program(LLDB_DEFAULT_TEST_MAKE NAMES ${MAKE_NAMES})
   if(LLDB_DEFAULT_TEST_MAKE)
     message(STATUS "Found make: ${LLDB_DEFAULT_TEST_MAKE}")
   else()
-    message(STATUS "Not found: make")
+    message(STATUS "Did not find one of: ${MAKE_NAMES}")
     message(WARNING
           "Many LLDB API tests require 'make' tool. Please provide it in Path "
           "or pass via LLDB_TEST_MAKE.")

[DavidSpickett]

We could say we require a "GNU compatible" make but I didn't want to get into the weeds of whether Mac's make is technically GNU compatible or just happens to have all the features we need.

This change makes FreeBSD work out of the box, that's the key goal here.

[weliveindetail]

Yes, I believe there was a condition like that in my patch that introduced the check. And then I simplified it.

So, now the problem is that FreeBSD has both, make and gmake, and when we pick up make, the tests fail right? Wouldn't it be sufficient to change the order?

find_program(LLDB_DEFAULT_TEST_MAKE gmake make)

The only difference to your proposed change is that it would silently pick up make on the BSDs if gmake isn't found (like today).

However, it shows an issue that is a concern actually: Do we really want to prefer gmake over make on all platforms? Not sure which platforms actually have it, but it feels incorrect. Why not do something like this?

if (FreeBSD or NetBSD)
  find_program(LLDB_DEFAULT_TEST_MAKE gmake)
else()
  find_program(LLDB_DEFAULT_TEST_MAKE make gmake)
endif()

[DavidSpickett]

So, now the problem is that FreeBSD has both, make and gmake, and when we pick up make, the tests fail right? Wouldn't it be sufficient to change the order?

It will fix the build on FreeBSD where you have pkg install gmake, but on a system without it, it will find make and all the tests will fail to build.

Though.

It is a warning when we don't find a make at all. So you could argue that we should accept make on FreeBSD so you can build out of the box, and if you run the tests that's your problem. But in this case - it was my problem!

So yes maybe gmake only on those systems is a bit harsh.

Not sure which platforms actually have it, but it feels incorrect.

I'm assuming anything that has "gmake" it'll be a GNU compatible make, or at least more compatible than "make.

I could just switch the order. Prefer gmake on BSDs, prefer make everywhere else. Which is effectively what was happening before your patch, and it means you can still build on BSD without having to install gmake. At the cost of weird errors maybe.

I'll add a warning on BSD that we've found make but it likely won't compile tests properly.

[DavidSpickett]

I've updated it so that we prefer gmake on the BSDs, but we will use make if we cannot find gmake. Everywhere else we prefer make instead.

If we can't find a gmake on BSD we will warn but not error.

Which means you can build on a fresh FreeBSD without installing gmake. The tests won't build, but at least if they look at the cmake log / we ask them for the cmake log, there will be an obvious warning to explain the reason.

[labath]

I'm going to jump in here, since I think this was my idea. :)

I actually believe that preferring gmake is the right thing to do because we are (for whatever reason) looking for GNU make, and gmake (unlike make, it seems) is very likely to be the a "gnu make" -- if it exists. It's true that this would mean we use the name "gmake" on systems that usually call it "make" but so what... maybe we'll educate some people.

Conditionalizing it on the platform (particularly on the target platform) seems wrong. I think it be better to stick to the "gmake, make" order, and then check whether the thing we found was actually a GNU make (through make --version I guess) -- if it's not then issue a warning/error or whatever.

We could say we require a "GNU compatible" make but I didn't want to get into the weeds of whether Mac's make is technically GNU compatible or just happens to have all the features we need.

FWIW, the Mac make is not just "GNU compatible". It is GNU:

$ which make
/usr/bin/make
$ make --version
GNU Make 3.81
Copyright (C) 2006  Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

This program built for i386-apple-darwin11.3.0

(amusingly it thinks it's an i386 binary even though I'm running an arm macbook)

[DavidSpickett]

I thought they would have switched to a BSD make but perhaps this is left over. Ok cool then I just need to check a few --version to see what we can look for.

[DavidSpickett]

I've updated it as suggested. The non-GNU check isn't great but as long as it isn't spamming the build logs it should be ok.

FreeBSD make's --version is just an empty string (odd, but ok) and all the GNU makes I tried start with "GNU Make".

[labath]

Looks good. Thanks.

[DavidSpickett]

However, it shows an issue that is a concern actually: Do we really want to prefer gmake over make on all platforms?

I was using RHEL9 today and it has gmake and make but they are both GNU make. So I think we're safe using gmake if we find it.

[labath]

However, it shows an issue that is a concern actually: Do we really want to prefer gmake over make on all platforms?

I was using RHEL9 today and it has gmake and make but they are both GNU make. So I think we're safe using gmake if we find it.

On my system (Gentoo), gmake is a symlink to make.

$ ls -l `which make`
lrwxr-xr-x 1 root root 5 Nov 12 19:29 /usr/bin/make -> gmake

I'd be willing to bet that the version of the code before this patch (which preferred make) would fail on a linux system (if it even exists) where make is NOT "GNU make" .

(In other words, I agree with you :) )