-
Notifications
You must be signed in to change notification settings - Fork 984
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
AutotoolsToolchain: curate paths coming from tools.build:compiler_executables
on Windows before defining CC
, CXX
etc
#12194
Conversation
134a4a3
to
4a26229
Compare
4a26229
to
73345fa
Compare
CC
/CXX
/LD
env vars handling on Windows
CC
/CXX
/LD
env vars handling on WindowsCC
/CXX
/LD
/NM
env vars handling on Windows
@madebr @ericLemanissier if you have some time, I would appreciate feedbacks. |
I'm wondering whether AutotoolsToolchain could expose arguments to conditionally prefix these env vars with custom values in a recipe, like it's done in https://github.com/conan-io/conan-center-index/blob/1d04372ae1bead2e86a3f7183561361e9fcd9761/recipes/coin-cgl/all/conanfile.py#L90-L93 |
CC
/CXX
/LD
/NM
env vars handling on WindowsCC
/CXX
/LD
/AR
/NM
env vars handling on Windows
9863092
to
3ad51c3
Compare
Why not providing these scripts in conan (but GPL-2.0-or-later license)? compile wrapper
ar-lib wrapper
|
I would do this another way and add This approach allows a recipe to override any variable without conan trying to be too smart (e.g. unwanted conversion of a path to unix path). So allow this code: def generate(self):
tc = AutotoolsToolchain(self,
compile_wrapper=self._user_info_build["automake"].compile if is_msvc(self) else None,
ar_wrapper=self._user_info_build["automake"].ar_lib if is_msvc(self) else None,
)
assert tc.cc == "/path/to/compile cl"
assert tc.cxx == "/path/to/compile cl"
assert tc.ar == "/path/to/ar-lib lib"
tc.cc = "my_awesome_compiler"
assert tc.cc == "my_awesome_compiler"
assert tc.cxx == "/path/to/compile cl"
tc.generate() |
The main problem I see with this approach is to delegate to recipes the responsibility to honor CC, CXX etc set as absolute paths in profiles, it might mean lot of boilerplate in each recipe while it would be better to delegate all of this to conan. If conan or recipe overrides CC with just cl while users have set this env var as an absolute path in their profile, it might not compile with expected msvc version. |
If set, I would let the constructor initialize |
But you lose compile or ar-lib wrapper injection, it shouldn't be handled by final users, it's an internal build detail of the recipe. |
Oh, I think I see what you mean, you just want to populate all these attributes during initialialization, expose them so that they may eventually be overridden by a recipe before tc.generate(), and after that they are injected in build scope during tc.generate()? Just want to say that all these variables would be just None when related env var is not set in profile (except for msvc). |
CC
/CXX
/LD
/AR
/NM
/OBJDUMP
/RANLIB
/STRIP
env vars handling on Windowstools.build:compiler_executables
on Windows before defining CC
, CXX
etc
@memsharded any chance to consider this PR? I don't know what to do, should I close it? |
The main use case for this would be the Together with the complexity of having to deal with win32 specific APIs, I am afraid that we cannot move this PR forward at this moment. Thanks very much for your contribution anyway. Regarding some of the other discussions above, we definitely have in mind to develop some built-in helper that will automatically manage the definition of the environment, injection of wrappers, etc in |
Could you at least convert paths from tools.build:compiler_executables with |
why was it rejected? |
@memsharded @madebr any feedback would be appreciated. |
The use case, need, and solved problem is not evident enough to introduce the proposed complexity. Quoting has worked well for lots of similar cases, are we fully sure that this is not just a matter of adding some quote somewhere, and avoid the added complexity? For this to be considered, it would be necessary more evidence, well described detailed and real scenarios with reproducible cases (something that could also be a test in the test suite). |
@memsharded I think that curating paths from It would become a one line change in AutotoolsToolchain: -env.define(env_var, compilers_by_conf[comp])
+env.define(env_var, unix_path(self._conanfile, compilers_by_conf[comp])) |
That change might be fair, but that is unrelated to this current PR. |
This PR was exactly about that: curating CC, CXX etc on Windows. Why do you say it's unrelated? |
The PR was about Windows shortening syntax with |
It was about curation of env vars in general. There is a call to unix_path in this PR. Nevermind. |
This was not about env-vars in general but about the You are totally right about |
@memsharded sorry for not reading the PR, I just assumed it was related since it was linked to my issue (can you also take a look at it for more context?). My question is whether this kind of handling (namely wrapping compiler paths in In my understanding with conan2, the conan is no longer "passive", in the sense that it just tagged the binaries before, but also tries to take care of the right flags for different platforms and settings, using different build tools. If that's correct, then this kind of fix shouldn't be out of place (in another PR and with all the tests of course). |
Sure, @yowidin, thanks for the clarifications. Yes, the purpose of the build system integrations like I am going to spin off a new ticket for it. |
This PR has been submitted before availability of
I've found only 1 test of AutotoolsToolchain on Windows where autotools are called then configure then make, but it's disabled, so it's hard to write anything for this PR if the basic test without any CC/CXX set is not even covered :s |
#13867 adding |
Changelog: (Fix): In
AutotoolsToolchain
, if build machine is windows, curate paths coming fromtools.build:compiler_executables
before definingCC
,CXX
,CCAS
,NVCC
&FC
env varsDocs: conan-io/docs#2845
Scope of this PR has been simplified: #12194 (comment)
==========
Old logic description here but not valid anymore:
This PR tries to honor
CC
/CXX
/LD
/AR
/NM
/OBJDUMP
/RANLIB
/STRIP
if they are set from profile -specially if a path was given-, fall back to good defaults for msvc if they are not set in profile, and convert them to a value compatible with autotools scripts & current subsysem (specially on Windows):As a workaround on Windows, users may use short file names to refer to their compiler path if the long name contains spaces (
PROGRA~1
instead ofProgram Files
for example). I guess it might be possible for conan, if build machine is windows, to find the short file name (if it exists) of directories containing spaces, and do this conversion on the fly, but it's not implemented here (win32api.GetShortPathName
frompywin32
?).CC=cl
), nothing special is done (except adding extra options like-nologo
or eventually wrap withcompile_wrapper
&ar_wrapper
as explained below).-nologo
is added toCC
,CXX
&LD
vars if msvc to avoid noisy messages during build.All these values are stored in new
AutotoolsToolchain
attributes:cc
,cxx
,ld
,ar
,nm
,objdump
,ranlib
,strip
. If needed, these attributes can be overridden before callinggenerate()
(where these values are injected in conanautotoolstoolchain script injected in build scope if they are different than the ones ofVirtualBuildEnv
).This PR also adds two new arguments to
AutotoolsToolchain
constructor:compile_wrapper
&ar_wrapper
. They are None by default, but a recipe can fill them with path to a wrapper script likecompile
orar-lib
fromautomake
(or sometimes source code of the library) to provide robust autotools compatibility to compilers like msvc.If set,
compile_wrapper
wraps compiler calls (CC
&CXX
).If set,
ar_wrapper
wraps archiver calls (AR
).A typical usage in an autotools based recipe would be:
Since
AutotoolsToolchain
may override CC, CXX etc, recipes using it must not callVirtualBuildEnv
afterAutotoolsToolchain
, always before if they have to call it.=======
develop
branch, documenting this one.Note: By default this PR will skip the slower tests and will use a limited set of python versions. Check here how to increase the testing level by writing some tags in the current PR body text.