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.

Sign up for GitHub

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

Jump to bottom

CMake namespaces (and other modern cmake cleanup) #1924

Closed
jjwilke opened this issue Dec 4, 2018 · 5 comments
Closed

CMake namespaces (and other modern cmake cleanup) #1924

jjwilke opened this issue Dec 4, 2018 · 5 comments
Assignees
@jjwilke
Labels
Feature Request Create new capability; will potentially require voting
Projects
CMake Overhauls Milestone: Release 3.0

Comments

@jjwilke
Copy link

jjwilke commented Dec 4, 2018

Best practice (AFAIK) is to namespace targets so that CMake knows the name is intended to be a CMake target, generating getter error messages:

target_link_libraries(mylib Kokkos::kokkos)

This seems easy enough to add - but I suppose could break a lot of code that expect the target kokkos with no namespace. Is it worth exporting both the current un-namspaced target for (compatibility) and a namespaced-target (for good practice)?
@jjwilke
Copy link
Author

jjwilke commented Dec 4, 2018

Related to #674

@jjwilke jjwilke mentioned this issue Dec 4, 2018
Closed
@jjwilke jjwilke changed the title CMake namespaces CMake namespaces (and other modern cmake cleanup) Dec 6, 2018
@jjwilke
Copy link
Author

jjwilke commented Dec 6, 2018 •
edited

Separate libs builds did not work

LINK_TARGETS=kokkoscore

was the only thing set, leading to a bunch of undefined references on kokkos containers

jjwilke pushed a commit to jjwilke/kokkos that referenced this issue Dec 6, 2018
Major cmake overhaul including example and other fixes: kokkos#1924 k…
4a50aed 
…okkos#1928 kokkos#1930
jjwilke pushed a commit to jjwilke/kokkos that referenced this issue Dec 7, 2018
export updates to fix backwards compatibility: kokkos#1924 and kokkos…
d550208 
…#1930
jjwilke pushed a commit to jjwilke/kokkos that referenced this issue Dec 14, 2018
export gtest for dependent libs: Issue kokkos#1924
c9e3b67
jjwilke pushed a commit to jjwilke/kokkos that referenced this issue Dec 17, 2018
cleanup for supporting standalone and tribits: kokkos#1924
db1786a
@ndellingwood ndellingwood added the Feature Request Create new capability; will potentially require voting label Feb 1, 2019
@ndellingwood ndellingwood mentioned this issue Feb 6, 2019
Closed
6 tasks
@Char-Aznable
Copy link
Contributor

@jjwilke Is your branch cmake-1924 supposed to tackle the issue mentioned here and those in #674? If so, can you give a big picture of how it works?

@ndellingwood ndellingwood added this to the 2019 April milestone Feb 7, 2019
@crtrott crtrott removed this from the 2019 April milestone Aug 21, 2019
@jjwilke jjwilke added this to the 3.0 Release milestone Sep 4, 2019
@masterleinad masterleinad added this to To do in Milestone: Release 3.0 via automation Oct 3, 2019
@dalg24
Copy link
Member

dalg24 commented Oct 7, 2019

Separate libs builds did not work

@jjwilke Is that still an issue?

@jjwilke
Copy link
Author

jjwilke commented Oct 7, 2019

Not still an issue. Separate libs and single lib should still be working.

@masterleinad masterleinad moved this from To do to Done in Milestone: Release 3.0 Oct 7, 2019
@ndellingwood ndellingwood mentioned this issue Jan 28, 2020
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@jjwilke jjwilke

Labels
Feature Request Create new capability; will potentially require voting
Projects
No open projects
CMake Overhauls
Awaiting triage
Milestone: Release 3.0
  
Done
Milestone
No milestone
Development

No branches or pull requests
6 participants
@jjwilke @dalg24 @masterleinad @crtrott @ndellingwood @Char-Aznable