[ISSUE] GNU Make package doesn't make a symlink for /usr/bin/gmake

[ISSUE] GNU Make package doesn't make a symlink for /usr/bin/gmake

[rudzik8]

[-- Attachment #1: Type: text/plain, Size: 1381 bytes --]

New issue by rudzik8 on void-packages repository

https://github.com/void-linux/void-packages/issues/50812

Description:
### Is this a new report?

Yes

### System Info

Void 6.6.32_1 x86_64 AuthenticAMD notuptodate rFFF

### Package(s) Affected

make-4.4.1_1

### Does a report exist for this bug with the project's home (upstream) and/or another distro?

_No response_

### Expected behaviour

Since our `make` implementation is GNU Make, it is really weird for it to not include a symlink for `gmake`.

For example, this is the output of `ls -l /usr/bin/ | grep "make"` on an Ubuntu system with `make` package installed is:
```
lrwxrwxrwx 1 root root           4 Feb 15  2022 gmake -> make
-rwxr-xr-x 1 root root      255696 Feb 15  2022 make
-rwxr-xr-x 1 root root        4905 Feb 15  2022 make-first-existing-target
```
And all `gmake` commands resolve without any problems there.

### Actual behaviour

CMake checks for `gmake` don't pass, its "simple test program" to verify `cc` doesn't compile (because it expects `gmake` to exist, and doesn't find it), and nobody's happy. :(

This is, however, easily fixed by doing `sudo ln -s /usr/bin/make /usr/bin/gmake`.

### Steps to reproduce

Try CMake'ing anything on a new Void install with `make` and `gcc` installed. [In my case, it was Minetest (+ its deps ofc)](https://github.com/minetest/minetest/issues/14746)

Re: GNU Make package doesn't make a symlink for /usr/bin/gmake

[ahesford]

[-- Attachment #1: Type: text/plain, Size: 512 bytes --]

New comment by ahesford on void-packages repository

https://github.com/void-linux/void-packages/issues/50812#issuecomment-2166997386

Comment:
Why would we make a symlink? The package installs itself as `make` and it's the default and expected version of make in a Void development environment. Also note that we have a metric ton of CMake packages in the repo, and they all build fine with our make.

Your CMake scripts are broken (and probably aimed at some BSD) if they demand to find GNU make as `gmake`.

Re: GNU Make package doesn't make a symlink for /usr/bin/gmake

[ahesford]

[-- Attachment #1: Type: text/plain, Size: 637 bytes --]

New comment by ahesford on void-packages repository

https://github.com/void-linux/void-packages/issues/50812#issuecomment-2166997386

Comment:
Why would we make a symlink? The package installs itself as `make` and it's the default and expected version of make in a Void development environment. Also note that we have a metric ton of CMake packages in the repo, and they all build fine with our make.

Your CMake scripts are broken (and probably aimed at some BSD) if they demand to find GNU make as `gmake`.

Edit: although our CMake uses ninja by default, this wasn't always the case, and we've never installed a `gmake` symlink.

Re: GNU Make package doesn't make a symlink for /usr/bin/gmake

[classabbyamp]

[-- Attachment #1: Type: text/plain, Size: 417 bytes --]

New comment by classabbyamp on void-packages repository

https://github.com/void-linux/void-packages/issues/50812#issuecomment-2167039838

Comment:
```
$ cat /usr/share/cmake-3.27/Modules/CMakeUnixFindMake.cmake
...
find_program(CMAKE_MAKE_PROGRAM NAMES gmake make smake)
...
```
pretty sure cmake should find `make` just fine without it being called `gmake`. what's the *exact* cmake output where this occurs?

Re: GNU Make package doesn't make a symlink for /usr/bin/gmake

[classabbyamp]

[-- Attachment #1: Type: text/plain, Size: 466 bytes --]

New comment by classabbyamp on void-packages repository

https://github.com/void-linux/void-packages/issues/50812#issuecomment-2167039838

Comment:
```
$ cat /usr/share/cmake-3.27/Modules/CMakeUnixFindMake.cmake
...
find_program(CMAKE_MAKE_PROGRAM NAMES gmake make smake)
...
```
pretty sure cmake should find `make` just fine without it being called `gmake`. what's the *exact* cmake output where this occurs? do you have a minimal reproducing cmake project?

Re: GNU Make package doesn't make a symlink for /usr/bin/gmake

[sgn]

[-- Attachment #1: Type: text/plain, Size: 452 bytes --]

New comment by sgn on void-packages repository

https://github.com/void-linux/void-packages/issues/50812#issuecomment-2167080388

Comment:

> Your CMake scripts are broken (and probably aimed at some BSD) if they demand to find GNU make as `gmake`.
> 

If a CMake scripts care about its backend, or assuming its backend is Make, it's broken.

If a CMake scripts want GNU Make, it's very broken. If it  wants specially gmake, it shouldn't be existed.

Re: [ISSUE] [CLOSED] GNU Make package doesn't make a symlink for /usr/bin/gmake

[ahesford]

[-- Attachment #1: Type: text/plain, Size: 1384 bytes --]

Closed issue by rudzik8 on void-packages repository

https://github.com/void-linux/void-packages/issues/50812

Description:
### Is this a new report?

Yes

### System Info

Void 6.6.32_1 x86_64 AuthenticAMD notuptodate rFFF

### Package(s) Affected

make-4.4.1_1

### Does a report exist for this bug with the project's home (upstream) and/or another distro?

_No response_

### Expected behaviour

Since our `make` implementation is GNU Make, it is really weird for it to not include a symlink for `gmake`.

For example, this is the output of `ls -l /usr/bin/ | grep "make"` on an Ubuntu system with `make` package installed is:
```
lrwxrwxrwx 1 root root           4 Feb 15  2022 gmake -> make
-rwxr-xr-x 1 root root      255696 Feb 15  2022 make
-rwxr-xr-x 1 root root        4905 Feb 15  2022 make-first-existing-target
```
And all `gmake` commands resolve without any problems there.

### Actual behaviour

CMake checks for `gmake` don't pass, its "simple test program" to verify `cc` doesn't compile (because it expects `gmake` to exist, and doesn't find it), and nobody's happy. :(

This is, however, easily fixed by doing `sudo ln -s /usr/bin/make /usr/bin/gmake`.

### Steps to reproduce

Try CMake'ing anything on a new Void install with `make` and `gcc` installed. [In my case, it was Minetest (+ its deps ofc)](https://github.com/minetest/minetest/issues/14746)