MacOS gmake failure to build

[marksull]

This code was added last week to builder/__init__.py

        if sys.platform.startswith('darwin'):
            if item.startswith('make '):
                item = 'g' + item

            if ' make ' in item:
                item = item.replace(' make ', ' gmake ')

which results in a build failure with the follow error

Cleaning build....
Getting ESP-IDF build Environment
bash: line 1: gmake: command not found
bash: line 1: gmake: command not found
Compiling mpy-cross....
bash: line 1: gmake: command not found

Running the latest Macos Sonoma 14.5.

Could be an environment issue for me.

Guess I could symlink make -> gmake, but removing this code and the build works fine.

[kdschlosser]

I don't use macOS at all and the only thing I am able to work from is what is provided by the CI that is set up in GitHub Actions. Whatever they are doing with the image doesn't include GCC make so I have to install it using Homebrew. When it is installed using Homebrew it's not called make. It is called gmake. I do not know if the make you are using is GCC make as I know that Apple has altered versions of build system components. An example of this is Clang. The Clang that gets installed is Apple Clang and not LLVM Clang. If you are not using GCC make gmake I cannot gurantee that the build system will not have any issues in the future because I do not know if what you are using is an Apple variant of GCC make.

To install make on macOS the command I am using is brew install make and that command installs gmake If you are compiling for the ESP32, I recommend getting Ninja as well brew install ninja

[marksull]

How we install make may differ, as you mention, gmake when using brew.

Maybe a more compatible implementation would be to use which to determine which is installed and use that:

>>> from shutil import which
>>> which("make")
'/usr/bin/make'
>>> which("gmake")
>>>

And if both are None you can raise en exception

[kdschlosser]

IDK if which handles environment aliases. I believe that is what is being done when make is being installed using Homebrew. I believe it is creating an alias that points to the absolute location of the installed GCC make. I do know that which searches the path specifically for 'gmake'. To my knowledge there is no 'gmake' file that it would be able to locate.

We also have the issue of knowing what make has actually been installed. Is it GCC make or is it Apples "flavor" of make. Apples flavor of CLang has caused me to loose some hair because of how it is defaulted to all compiler warnings being errors and also it's inability to be told to statically link to a library. It will always dynamically link if there is a shared library available that has the same name. An example of this is SDL2 and the build system compiling the latest version of SDL2 where as if SDL2 is already installed using a package manager it is going to be a lesser version that causes linking errors.

Hence the preference to to using a known GCC make which should be called gmake on macOS

[marksull]

make which should be called gmake on macOS - I am not aware of such a convention. Maybe this is standard that brew has adopted, but I wouldn't say "this is the way".

So right now, this breaks if make is not installed by brew. If your concern is it is not GNU Make, then if "darwin" and which("make") and "GNU Make" in subprocess.run(['make', '--version'], capture_output=True, text=True, check=True) else use gmake. That would cover all bases right?

[kdschlosser]

what other package manager does darwin use?

[marksull]

Macports or build directly.

Consider this fact though. I can't have been the only Mac user using your package. And until last week us Mac users were compiling your package fine. So the conclusion you must make (pun intended) is that whatever make we are using, has been working fine. With your change to cater for you your build environment and locking Darwin to "gmake" breaks it for us outside your build environment.

[kdschlosser]

as you have said, there are other mac users. This is the first time this problem has come up so I can only be led to believe that the problem for whatever reason is unique to your environment.

That being said, I am one for keeping things as uniform as possible and I would prefer to use make in favor of gmake. I did do some digging and I did learn that by default xcode does not install the command line tools and it needs to be done using xcode-select -–install. Once that is done GCC make is installed and it will be named make and not gmake I changed things up so make is used. I have to update the readme and remove the homebrew installation of GCC make (gmake ) and edit the the requirement for the command line tools so it is correct.

[kdschlosser]

That gmake alteration was made a long while ago as well. I know you mentioned it being made like last week and that is not the case. I may have moved it from a different location in the code but it has been in the code for some time. I would have to go and specifically check to see when it was added.

[marksull]

Confirmed with your latest changes no patch was required to build on macOS with make in lieu of gmake.