-
-
Notifications
You must be signed in to change notification settings - Fork 274
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
Flags in compiler activation vs. out-of-conda-forge usage #2002
Comments
Wanted to comment here as I also have struggled with the changes made to environment variables like CFLAGS in the past. The issues this poses range from mildly annoying (ex: having to clean and rebuild your environment when you realize you have the wrong flags) to outright confusing (ex: running benchmarking tools like ASV with conda and having no idea why you get wildly different timings). For users that aren't yet that experienced with how environment variables affect the build system, I think this adds a layer of confusion that makes the compilers seem more mysterious than they actually are. Before I found this I also posted a similar question on SO, as the mechanics of how to prevent this from happening were not that obvious to me: https://stackoverflow.com/questions/77651168/prevent-conda-from-changing-cflags-cppflags Not sure if this is considered too heavy-handed but maybe even a compilers-dev package that doesn't mess with the environment like this would be a net improvement? |
That seems like a good alternative to changing the activation scripts for the |
Another advantage of a debug compiler package is that gdb could be compiled with the appropriate --with-python flag that enables extending the debugger. This is something that would make things like using cygdb for Cython somewhat more tenable. See also cython/cython#5186 (comment) |
Part of the success of conda-forge is that many upstream projects have adopted (or at least support) development environments based on conda-forge packages. Almost inevitably, this ends up pulling in compilers as well - either through the explicit
compilers
package, or through other means (like directly depending ongcc_linux-64
orclang_osx-64
).This runs into the question whether this is something we can or want to support. The status quo following Hyrum's law is of course that they're being used in several ways.
This "off-label" compiler use then runs into issues, like that the flags we inject into our compiler activation create problems for development. Anything from
-DNDEBUG
/-O2
, etc. etc., see:CXXFLAGS
fromx86_64
&aarch64
Linux variants causes build error ctng-compiler-activation-feedstock#74-fvisibility-inlines-hidden
breaks libprotobuf (and potentially other software) ctng-compiler-activation-feedstock#73-fopenmp
or-std=c++17
by default ctng-compiler-activation-feedstock#42Latest comment to this effect:
Assuming we want to make our support explicit (for the usage of our compilers outside of conda-forge), we could potentially have both an internal & external compiler activation; the conda-forge internal one would add all the necessary flags (as now), and the external one would be reduced to a minimum.
Thoughts?
The text was updated successfully, but these errors were encountered: