Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

make is preferred over gmake #5704

Open
Alizter opened this issue Oct 18, 2023 · 6 comments
Open

make is preferred over gmake #5704

Alizter opened this issue Oct 18, 2023 · 6 comments

Comments

@Alizter
Copy link

Alizter commented Oct 18, 2023

%{make} gets expanded to whatever make points to in PATH. On some systems such as *BSD there can be a difference between make and gnu make gmake. OPAM currently prefers the first even though gmake was probably intended. This seems like a bug and gmake should be preferred when available when expanding %{make}.

@rjbou
Copy link
Collaborator

rjbou commented Oct 18, 2023

on *BSD system, it is gmake that is used

makecmd = lazy OpamStd.Sys.(
match os () with
| FreeBSD | OpenBSD | NetBSD | DragonFly -> "gmake"
| _ -> "make"
);

If it's not the case, it's a bug indeed.

@kit-ty-kate
Copy link
Member

which platform are you on? Could you show us the output of opam var?

@Alizter
Copy link
Author

Alizter commented Oct 18, 2023

I'm on Linux. Here is a cram test demonstrating the issue:

Create some fake binaries for a fake PATH
  $ mkdir bin
  $ cat > bin/gmake
  $ cat > bin/make
  $ chmod +x bin/gmake bin/make

Current opam version
  $ opam --version
  2.1.5
We need to access these binaries after we override PATH
  $ opam=$(which opam)
  $ which=$(which which)

Observe that opam simply gives `make` to be resolved by sh or whatever. Hence will
overlook gmake on BSD.
  $ PATH=bin
  > $opam var make
  > $which make 
  make
  $TESTCASE_ROOT/bin/make

You can also modify the above to leave only gmake in path causing opam var to still output make even though it doesn't exist in path.

Edit: I've just seen @rjbou's code and indeed that will work on *BSD.

As more exotic platforms get added, they will need to be special cased. One such platform that isn't covered here is Haiku. I would think that looking for gmake and falling back to make will be more resilient than special casing.

I'm happy closing this issue however just wanted to let you know about it.

@kit-ty-kate
Copy link
Member

kit-ty-kate commented Oct 18, 2023

I remember having issues on platforms such as Windows when using gmake unconditionnally if available.

If my memory is correct the problem i had was that gmake/make was preinstalled by a big project separately (Git maybe?) and made available in Path, but Cygwin’s version of GNU make does not install gmake so it was failing because the two platforms were incompatible.

Maybe it was a problem in the configuration of the system i was on but regardless I would personally feel icky to use gmake by default on all platforms if available.

Maybe we could somehow detect if the make command is GNU Make and use that if so, if not search for gmake ? I’m not sure how to do that though.

@Alizter
Copy link
Author

Alizter commented Oct 18, 2023

I think that in practice preferring gmake is not such a big deal since it is usually not available if make is gmake. So you would essentially which for gmake if its not there then fallback to make. Most cases this would be true, but on platforms where the distinction matters it would prefer gmake.

@kit-ty-kate
Copy link
Member

Maybe we could somehow detect if the make command is GNU Make and use that if so, if not search for gmake ? I’m not sure how to do that though.

I've opened a PoC PR in #5705 showing a working implementation of that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants