Skip to content

Compiler flags added late in the build are not exported to external build systems #5605

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

Closed
SebastianBoe opened this issue Jan 9, 2018 · 6 comments
Assignees
Labels
area: Build System bug The issue is a bug, or the PR is fixing a bug priority: low Low impact/importance bug

Comments

@SebastianBoe
Copy link
Collaborator

SebastianBoe commented Jan 9, 2018

The current infrastructure for integrating with external build systems can cause flags to be omitted in a way that is confusing and inconvenient for build script developers.

Today it works like this:

CMakeLists.txt code is processed in a sequential manner. Different subsystems (arch/, zephyr/CMakeLists.txt, subsystems/, ext/) can globally add flags to the build, and the zephyr_get_*
API reads out this global list of flags when it is invoked to export flags to external build systems.

For third party build systems that are integrated in the 'app' CMakeLists.txt file this works fine, because the code in the 'app' CMakeLists.txt that is placed after boilerplate.cmake is the last code to be executed and will therefore have access to all flags.

For Zephyr components things are trickier. No matter how careful we are in ordering arch, ext, subsys, there will eventually arise a use-case where two different systems are both exporting flags to external build systems and also globally adding compiler flags.

@SebastianBoe SebastianBoe added bug The issue is a bug, or the PR is fixing a bug area: Build System labels Jan 9, 2018
@SebastianBoe SebastianBoe self-assigned this Jan 9, 2018
@SebastianBoe
Copy link
Collaborator Author

A temporary workaround is to re-order CMakeLists.txt code until you get all the flags you need.

Not sure what a proper fix would look like. Perhaps in addition to the boilerplate.cmake header we could have a footer_boilerplate.cmake that reads out the final list of flags. But this solution would both increase bloat in the 'app' CMakeLists.txt code and be a breaking change, so we should try to find a better solution.

The CMake-way of solving this generic problem of "configuration done late must affect configuration done early" is generator expressions. CMake can evaluate CMake variables at generation-time (Just after all CMakeLists.txt code has been processed). Perhaps if the flags were contained in generator expressions we could make this work.

@SebastianBoe
Copy link
Collaborator Author

@pfalcon : @KaSroka : FYI

@pfalcon
Copy link
Collaborator

pfalcon commented Jan 9, 2018

Ack, thanks for ping.

@nashif
Copy link
Member

nashif commented Feb 6, 2018

is this fixed already?

@SebastianBoe
Copy link
Collaborator Author

Unfortunately no.

@nashif nashif added the priority: low Low impact/importance bug label Feb 15, 2018
@nashif
Copy link
Member

nashif commented Feb 19, 2019

over 1 year, closing

@nashif nashif closed this as completed Feb 19, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: Build System bug The issue is a bug, or the PR is fixing a bug priority: low Low impact/importance bug
Projects
None yet
Development

No branches or pull requests

3 participants