Skip to content
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

Preventing the toolchain to run as an environment variable breaks further runs. #146

Open
JonasVautherin opened this issue May 20, 2022 · 5 comments
Assignees
Labels

Comments

@JonasVautherin
Copy link
Contributor

This breaks my build:

if(DEFINED ENV{_IOS_TOOLCHAIN_HAS_RUN})
  return()
endif()
set(ENV{_IOS_TOOLCHAIN_HAS_RUN} true)

Where the previous version is fine:

if(IOS_TOOLCHAIN_HAS_RUN)
  return()
endif(IOS_TOOLCHAIN_HAS_RUN)
set(IOS_TOOLCHAIN_HAS_RUN true)

I believe that's because it now sets this as an environment variable, and the second time I try to build a project using the toolchain, it just doesn't do anything.

Feels weird to me that I need to unset _IOS_TOOLCHAIN_HAS_RUN between two cmake runs, though 🤔.

Any thoughts on that? 😇

@leetal
Copy link
Owner

leetal commented May 20, 2022

Hmmm, i have never had to unset the environment variables between runs? I cannot remember either why i changed that in the first place... Seems to run equally good using both the "old" solution as with the ENV solution.

@JonasVautherin
Copy link
Contributor Author

JonasVautherin commented May 20, 2022

Does it work if you do something like this?

export _IOS_TOOLCHAIN_HAS_RUN=true
cmake -DCMAKE_TOOLCHAIN_FILE=<...> -B<...> -S<...>
cmake --build <...>

It will disable the toolchain, right?

Similarly, without manually setting the env variable, if you run it twice:

cmake -DCMAKE_TOOLCHAIN_FILE=<...> -BprojectA/build -SprojectA
cmake --build projectA
cmake -DCMAKE_TOOLCHAIN_FILE=<...> -BprojectB/build -SprojectB
cmake --build projectB

Then I expect the first run to set the env variable (just like export above), and disable the toolchain for further projects, right?

I have a slightly different setup where my cmake project calls cmake projects as subprocesses, but I think it's similar 🤔.

I mean it's not a big deal for me, I just remove it now that I know it breaks my build. Just wanted to take this as an opportunity to question it 🙂.

@dmyger
Copy link

dmyger commented Aug 15, 2022

Let me also add some notes about the same issue:
As for my project this construction is not compatible with conan where it's require multiple times use the same toolchain file while configure all external libraries. Because it's run in the same process it leads to main project would configured for arm64, while all conan libraries for x86_64. And it brokes linker.
As workaround I had to comment out this if(_IOS_TOOLCHAIN_HAS_RUN)

@depnz
Copy link

depnz commented Apr 3, 2023

An interesting, related issue is if a CMake project includes a subproject, where the subproject will set and use the toolchain. When the top level project then tries to use the same tool chain, it does not configure fully.

This leads to the situation where e.g. DEPLOYMENT_TARGET settings for the subproject are respected, but all these sorts of settings are defaulted-out for the top-level project, as if the toolchain was not even set.

I'm employing the workaround unset(ENV{_IOS_TOOLCHAIN_HAS_RUN}) as a final step when the subproject is included.

@JonasVautherin
Copy link
Contributor Author

It is still here, and given this past message:

I cannot remember either why i changed that in the first place... Seems to run equally good using both the "old" solution as with the ENV solution.

@leetal: would you be open to a PR that would either remove those lines or add an option (e.g. ALWAYS_RUN) to work around it?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants