search

chapel-lang / chapel

a Productive Parallel Programming Language
https://chapel-lang.org
Other
1.79k stars 421 forks source link

Need better error for accidentally using non-GNU Make #8019

Open mppf opened 6 years ago

mppf commented 6 years ago

When building Chapel with a top-level make, the error is pretty inscrutable if BSD or other non-GNU Make is used. If this situation comes up in practice, it would be nice to have a better error message.

mppf commented 6 years ago

I implemented this in PR #8006 but that PR didn't get much support, so this issue documents the problem and links to one solution in case it matters more in the future.

ben-albrecht commented 6 years ago

Instead of checking the gmake version in every target with the Makefile wrapper, would it be sufficient and less intrusive to just check the version in the all target, since that's likely the first and/or only target a user will try?

mppf commented 6 years ago

It doesn't really help; we still have to write a Makefile wrapper and that's the part Brad didn't like. Additionally, I found that I needed checks in both places for the omnios/SunOS make.

edit: also I forgot to mention that BSD make will barf before it tries to run the all target, because of ifeq type things.

ben-albrecht commented 6 years ago

It doesn't really help; we still have to write a Makefile wrapper and that's the part Brad didn't like.

Ah. I was thinking this would avoid the Makefile wrapper, but I now realize that it wouldn't.

ben-albrecht commented 6 years ago

Could we have configure check and complain about BSD make? It's not a bullet-proof approach, but I suspect there's a high chance a user will attempt ./configure if make barfs on them.

mppf commented 6 years ago

Yes that would be relatively easy. But, QUICKSTART.rst (e.g.) doesn't actually say to run ./configure.

ben-albrecht commented 6 years ago

Yes that would be relatively easy. But, QUICKSTART.rst (e.g.) doesn't actually say to run ./configure.

But QUICKSTART.rst does say to use gmake and provides a link to prereqs.rst. If a user is reading documentation, they have a good chance of noticing that requirement. If they are not one to read documentation, they have a good chance of stumbling into a helpful warning message provided by configure.

bradcray commented 6 years ago

I was going to suggest a configure-based approach as well.

mppf commented 2 years ago

If a FreeBSD user would normally do this:

./configure
gmake

but we make configure check that make runs GNU make, how does that help?

bradcray commented 2 years ago

My brain today can't recall what my five-years-ago brain was thinking. Unless it was to make the top-level Makefile so simple and portable that it would work with either make or gmake, and then to have configure specialize it in a way that any subcommands it executed on any sub-makefiles used the appropriate one of the two. Looks like that's really similar to what you did in #8006, though, so that probably wasn't it. :)

I don't have any recollections of users hitting this, so would be OK with closing this without taking action until/unless that situation changed.