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

CMake overhaul and architecture #8827

Open
2 of 7 tasks
tejlmand opened this issue Jul 10, 2018 · 7 comments
Open
2 of 7 tasks

CMake overhaul and architecture #8827

tejlmand opened this issue Jul 10, 2018 · 7 comments
Assignees
Labels
area: Build System Enhancement Changes/Updates/Additions to existing features Meta A collection of features, enhancements or bugs

Comments

@tejlmand
Copy link
Collaborator

tejlmand commented Jul 10, 2018

This is an umbrella issue for a series of changes to the current CMake usage.

The purpose is to have a holistic view on the complete CMake build system in order to link multiple tasks together, where each change might seems a minor issue, but where the complete Zephyr CMake build architecture could be improved.

In general, it is better to have few, well organized / structured libraries, and populate those in a well defined way.
Those libraries should follow the general KConfig and folder structure, so that e.g. a subsystem folder corresponds exactly to a single library, to which dependencies can be clearly defined.

Example: Subsystem Net creates a library target: subsys_net (file name: libsubsys_net.a)

It must also be remembered that there is a difference between working in vi(m)/emacs/etc. and IDE's such as Eclipse.
Certain elements, such as target / libraries are more visible in an IDE.

Furthermore it suggest to avoid the wrapping of CMake functions, and instead use plain CMake whenever possible. Currently, many wrapped cmake functions limits the feature set of CMake and thus spawns additional commands (=> increased maintenance + additional API to learn for new comers).
Instead, functions that can assist the user, before using the plain CMake function should be preferred.

@SebastianBoe
Copy link
Collaborator

Hi,

"Bug related to too many libraries when enabling application memory space:"

should be removed as the bug has now been resolved.

@SebastianBoe
Copy link
Collaborator

Also,

start-group and end-group has been removed, so

"Whole-archive / start-group / end-group link command"

can be changed to

"Whole-archive command"

@tejlmand
Copy link
Collaborator Author

"Bug related to too many libraries when enabling application memory space:"

should be removed as the bug has now been resolved.

Check marked it, as I think that is more correct

@tejlmand
Copy link
Collaborator Author

tejlmand commented Aug 21, 2018

Whole-archive / start-group / end-group link command

Partly true.
When --whole-archive is used, then --start-group / --end-group is not needed.
--whole-archive includes the whole archive, and thus any circular dependencies of course disappears.
But when removing the --whole-archive, then the problem which --start-group / --end-group addresses re-appears.

Removing --whole-archive doesn't by itself ensure correct ordering of libraries during linking, and unless correct link dependencies (including circular dependencies) is introduced in CMake, then linking will fail, as the linker will search for down the chain.
Example:
libA depends on libB
libB also depends on libA
this dependency can be handled by:
--start-group libA libB --end-group
or when correctly described in CMake you'll get:
libA libB libA
during linking, in which case all symbols can be resolved.

@tejlmand tejlmand reopened this Aug 21, 2018
@SebastianBoe
Copy link
Collaborator

SebastianBoe commented Aug 21, 2018

Sorry, what I was trying to say, is that we can update the issue description. It is stating that we need to get rid of "Whole-archive / start-group / end-group". But "start-group / end-group" has been gotten rid of, so now the issue description should just say that we need to get rid of "--whole-archive".

I am well aware of what the flags do.

EDIT: If you want, you could split out "start-group, end-group" into it's own checkmark and checkmark it.

@tejlmand
Copy link
Collaborator Author

ok.

Updated, and made own check-mark, as I believe we don't want the --start-group / --end-group reintroduced when removing the --whole-archive.

@zephyrbot
Copy link
Collaborator

Hi @tejlmand,

This issue, marked as an Enhancement, was opened a while ago and did not get any traction. It was just assigned to you based on the labels. If you don't consider yourself the right person to address this issue, please re-assing it to the right person.

Please take a moment to review if the issue is still relevant to the project. If it is, please provide feedback and direction on how to move forward. If it is not, has already been addressed, is a duplicate, or is no longer relevant, please close it with a short comment explaining the reason.

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: Build System Enhancement Changes/Updates/Additions to existing features Meta A collection of features, enhancements or bugs
Projects
Status: To do
Development

No branches or pull requests

5 participants