-
-
Notifications
You must be signed in to change notification settings - Fork 25
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
Why isn't CMAKE_BUILD_TYPE=Release
included in CMAKE_ARGS
?
#94
Comments
Yes, please |
What would be the path to override this if a user wants a debug build of a package? |
Instead of
you do
|
It's ok to specify |
Yes. The last value will be used. |
Why has this been done? It has started breaking CI builds for us in Arrow. The build type is a developer-oriented setting, not something that Conda should dictate to users. For example, it is often recommended to build in Debug mode for development. |
I think this conflates two different things:
There really should be two different environment variables for those. For example |
We could set some variables like
|
@pitrou I'm sorry this has caused an issue for you. I appreciate that unexpected build failures are always frustrating.
The motivation is two-fold:
Could you please explain why the workaround noted above isn't ideal for your setup? If you know you need a specific build type, you can include it in the call to cmake, and the value set in this repository is overridden. For example, if your CI builds use |
It certainly works. It's just that 1) it's more fragile (you have to make sure you use the correct parameter order in your Certainly, regardless of the final decision made by conda-forge, we can easily work around it... However, in general, I don't think conda/conda-forge should change compilation defaults except where necessary (such as setting the correct library search path). A general request: please think about user experience instead of doing unexpected changes like that. Also, I would suggest looking at what other package repositories do, because it can serve as a reference for good packaging practices. If Ubuntu/Fedora/etc. don't force the default CMake build type, why would conda-forge behave differently? |
(in our particular case, "broke things for us in a rather gratuitous way" implies that we had 1) to research the underlying cause of our CI issues 2) try a workaround and schedule a general CI rebuild to ensure it doesn't break something else; that's easily one or two hours lost, not to mention the annoyance of unrelated CI failures on pending PRs) |
Comment:
I recently started using the auto-defined
CMAKE_ARGS
environment variable for my CMake-based conda builds, as suggested in the conda-forge docs on using CMake. Not only is it convenient, but I agree with the perspective in #77 (comment) that using shared CMake settings helps keep the conda-forge ecosystem consistent.However, I was recently surprised to learn that
CMAKE_BUILD_TYPE=Release
is not set byactivate-gcc.sh
in this repo (conda-forge/staged-recipes#23297). It is set byactivate-clang.sh
for osx builds and byactivate.bat
for MSVC builds on Windows. I wasn't able to find any discussion on the motivation for this inconsistency across the platforms. In fact, all I could find was a discussion that was debating settingCMAKE_BUILD_TYPE=None
(#87, conda-forge/conda-forge.github.io#1859).Is there a particular motivation why
CMAKE_BUILD_TYPE=Release
is the default for osx and win builds, but not linux? If not, can I send I PR to includeCMAKE_BUILD_TYPE=Release
inCMAKE_ARGS
?The text was updated successfully, but these errors were encountered: