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: Zephyr wrapped functions does not allow keywords on zephyr_link_libraries #8614

Closed
tejlmand opened this issue Jun 28, 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

@tejlmand
Copy link
Collaborator

tejlmand commented Jun 28, 2018

During work on: #8445 I discovered that the wrapping macro: zephyr_library_named()
break the possibility of later using PUBLIC / PRIVATE / INTERFACE keywords together with
zephyr_library_link_libraries(INTERFACE <linking_flag>)
or using plain cmake:
target_link_libraries(myLib INTERFACE <linking_flag>)

as cmake will break with:
The plain signature for target_link_libraries has already been used with
the target "zephyr". All uses of target_link_libraries with a target must
be either all-keyword or all-plain.

The uses of the plain signature are here:

* ../../../cmake/extensions.cmake:431 (target_link_libraries)

EDIT: the correct reference for this has been updated to #8445

@SebastianBoe
Copy link
Collaborator

Thank you for reporting.

This has been fixed. The fix will be up for review after all of it's dependent PR's are merged:

Dependents:
#8533

Branch with fix:
https://github.com/SebastianBoe/zephyr/tree/proper_fix_of_8438

@SebastianBoe SebastianBoe added bug The issue is a bug, or the PR is fixing a bug area: Build System and removed bug The issue is a bug, or the PR is fixing a bug labels Jun 28, 2018
@tejlmand
Copy link
Collaborator Author

Hi,

your fix does not fix the problem, only moves it around, which is exactly my point with: #8439
When you change this function:
function(zephyr_library_link_libraries item)
from:
target_link_libraries(${ZEPHYR_CURRENT_LIBRARY} ${item} ${ARGN})

to always do:
target_link_libraries(${ZEPHYR_CURRENT_LIBRARY} PUBLIC ${item} ${ARGN})

then you can not specify, e.g. anymore:
zephyr_library_link_libraries(PRIVATE <item>)
or
zephyr_library_link_libraries(INTERFACE <item>)

instead you end up having to create even more wrapper functions.

@SebastianBoe
Copy link
Collaborator

Ah, my mistake, I thought this was a bug-report.

e.g. I thought you were reporting that

target_link_libraries(mylib INTERFACE )

was not possible.

If this is a feature-request, could you rephrase from:

"cmake: Zephyr wrapped functions does not allow keywords on zephyr_link_libraries"

to

"cmake: Add zephyr_library_* wrapper support for interface and private linking of libraries"

Unless this is a bugreport, e.g. it is trying to report that

"cmake: The zephyr_library_* wrapper does not scale"

@nashif nashif added the bug The issue is a bug, or the PR is fixing a bug label Jul 3, 2018
@tejlmand
Copy link
Collaborator Author

tejlmand commented Jul 4, 2018

Well, I think this is a minor bug.

As part of: #8445 the flag _ConfigAbsSyms should be used when linking to libzephyr.a
but as it is a link only flags, i.e. should not be used by the module itself, then the correct fix would be to write:
zephyr_library_link_libraries(INTERFACE -u_ConfigAbsSyms)
but as described in this issue this fails.

Your solution only targets the addition of PUBLIC / PRIVATE keywords to wrapped CMake functions.
It doesn't add the possibility of specifying the INTERFACE keyword to:
zephyr_library_link_libraries()

@nashif nashif added the priority: low Low impact/importance bug label Jul 31, 2018
@SebastianBoe
Copy link
Collaborator

Hi,

I believe that the title and/or the issue description is out-of-date.

E.g. it is stated in the description:

During work on: #8445 I discovered that the wrapping macro: zephyr_library_named()
break the possibility of later using PUBLIC / PRIVATE / INTERFACE keywords together with
[...]
using plain cmake:
target_link_libraries(myLib INTERFACE <linking_flag>)

but after #9309 was merged this is no longer the case.

Could you either update it, or permit me to update it as I understand it?

@SebastianBoe
Copy link
Collaborator

Closing due to the reporter not responding to the assignee.

@tejlmand : Feel free to re-open after addressing the comment from August.

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