-
-
Notifications
You must be signed in to change notification settings - Fork 27
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
Use more standard form of release flag in MESON_ARGS
#98
Conversation
…nda-forge-pinning 2023.09.27.16.11.26
Hi! This is the friendly automated conda-forge-linting service. I just wanted to let you know that I linted all conda-recipes in your PR ( |
This might break packages that does the opposite. So, it's not clear which one is better. |
That's clear, though I think it'd be good to decide on one and try to be consistent.
Given that meson-python uses |
I agree. This change is known to avoid a bunch of argparsing complexity. It is right for all Python packages. In case there are non-Python packages that have an explicit
You'll fix that once, which is a simple 1-line diff, and does not require argument parsing.
|
There are two different ways to set up a release flag to meson,
--buildtype release
, and-Dbuildtype=release
. Apparently the latter is more common; at least it's the recommended way in the docs.Since meson-python will by default add
-Dbuildtype=release
, the fact that the compiler-activation does the other kind leads to a duplicate specification and forces us to strip it out again as follows (e.g. in scipy, but affects all feedstocks using meson-python).To avoid this, use the more common form of the flag.
PS. Stumbled over this old PR, where this was discussed with @rgommers
PPS. Sister PR of conda-forge/clang-compiler-activation-feedstock#112