CMake overhaul and architecture

[tejlmand]

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.

• Improve documentation on CMake build architecture

  • Issue: CMake build architecture documentation #9947

• Reduce number of libraries in IDE

  • Issue: CMake: Many libraries causes noise in IDE's #8826 : Number of libraries presented
  • Issue: CMake libraries overview and content in IDE #8825 : File placement in libraries
  • PR: [RFC][DNM] cmake: RFC for single libraries to use CMake dependencies and remove whole-archive #8451

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

  • Issue: NUM_KERNEL_OBJECT_FILES is too small #7703
  • PR:

• Whole-archive link command

  • Issue: cmake: Improve library dependencies by removing whole-archive, start/end-group #8441
  • Issue: The 'app' library and additional application libraries created are linked differently #6961
  • PR: [RFC][DNM] cmake: RFC for single libraries to use CMake dependencies and remove whole-archive #8451

• Remove start-group / end-group command

  • Issue:
  • PR: ld: Don't use --start-group and --end-group #9342

• Remove multiple wrapped CMake functions

  • Issue: cmake: Use plain CMake instead of Zephyr's custom interface #8439
  • Issue: cmake: Zephyr wrapped functions does not allow keywords on zephyr_link_libraries #8614 : Wrapped functions reduces CMake feature set
  • PR: [RFC] [DNM] cmake: Created functions populating a list based on IFDEF / IFNDEF. #8442

• General clean-up of linker flags

  • Issue: cmake: Cleanup of linking flags and improving structure #8440
  • PR: cmake: Kernel and offset libraries linking flags #8445

[SebastianBoe]

Hi,

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

should be removed as the bug has now been resolved.

[SebastianBoe]

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]

"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]

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.

[SebastianBoe]

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]

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]

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!

[clamattia]

I am a bit dissatisfied with the cmake situation.
For example:

function(zephyr_library_include_directories)
  target_include_directories(${ZEPHYR_CURRENT_LIBRARY} PRIVATE ${ARGN})
endfunction()

How should someone know, that it is PRIVATE?
Why do we only have a wrapper for PRIVATE and not for example INTERFACE?
Why not use plain cmake (inlining the above function), which would increase readability for people familiar with cmake?

similar with the zephyr_library and zephyr_library_named etc etc...

What is the current situation on this subject @tejlmand ?

[yashi]

@clamattia

• cmake: Use plain CMake instead of Zephyr's custom interface #8439