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

Move -install project chaining to a more common place (fixes latest) #556

Merged
merged 2 commits into from
Jun 8, 2017

Conversation

eile
Copy link
Member

@eile eile commented Jun 7, 2017

No description provided.

Copy link

@rdumusc rdumusc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't get it, I need some time to understand what the problem is and what may have changed. CommonFindPackage should not have to manipulate install targets. There is one -install target per project, created by Common.cmake. So it seems to make perfect sense that add_subproject() adds this project-to-project dependency...

@eile
Copy link
Member Author

eile commented Jun 7, 2017

The issue is with optional dependencies which are not add_subproject()... Concretely in https://github.com/Eyescale/Equalizer/blob/master/examples/eqPly/CMakeLists.txt#L14, I could also add the dependency Equalizer-install ZeroEQ-install ZeroBuf-install here, or make Zero* subprojects in Equalizer. Without at least one of the three options, the smoke test fails since libZeroEQ is missing.

@rdumusc
Copy link

rdumusc commented Jun 7, 2017

Ah of course! There can't be an install dependency on a library for which you don't add the sources...

I found more other issues with the uxmal change:
common_find_package(ZeroEQ)
common_find_package(ZeroBuf)
are hidden in examples/CMakeLists.txt instead of being in the top-level CMakeLists.txt, which happens after common_find_package_post().

And I wonder why uxmal has a private dependency on ZeroEq? and a non-PUBLIC one on ZeroBuf?
set(UXMAL_LINK_LIBRARIES ZeroBuf ZeroEQ)

And what are CULLBUG_HEADERS? A grep on viz/stable gave me no results:
set(UXMAL_PUBLIC_HEADERS ${CULLBUG_HEADERS})

@eile
Copy link
Member Author

eile commented Jun 7, 2017

install dependency on a library for which you don't add the sources

In latest we can! ;)

Let's see tomorrow. I wanted to avoid bloating Eq dependencies, maybe it's time to move uxmal to a separate project.

@eile eile force-pushed the master branch 4 times, most recently from 6631b8b to 18443f5 Compare June 8, 2017 10:20
@tribal-tec
Copy link
Member

+1

Copy link

@rdumusc rdumusc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good idea overall

EXCLUDE_FROM_DEFAULT_BUILD ON)
endif()

# redo dependency chaining each time: a new common_find_package might have been called
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the first inclusion of this file will be in Common.cmake, before any common_find_package() call. So this will only work if users include DoxygenRule.cmake at the end... A solution I can think of is to make this a function to be called from common_find_package_post() instead.

Copy link
Member Author

@eile eile Jun 8, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

? See doc: to be included by every module depending on ${PROJECT_NAME}-install.

# doxygen and smoke tests. CMake does not provide this, so this is a workaround.
# install naturally depends on all, which depends on all common_library and
# common_application targets. Furthermore, ${PROJECT_NAME}-install depends on
# all subprojects which have a install rule, so that all necessary artefacts in
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

an install rule

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

# install naturally depends on all, which depends on all common_library and
# common_application targets. Furthermore, ${PROJECT_NAME}-install depends on
# all subprojects which have a install rule, so that all necessary artefacts in
# a superproject build are installed.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

document ${PROJECT_NAME}_FIND_PACKAGES_FOUND as input variable filled by common_find_package()

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

@@ -64,6 +64,7 @@ if(NOT TARGET ${PROJECT_NAME}-all)
endif()

include(CommonDate)
include(CommonInstallProject)
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

\n

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There was no newline before, but if it makes you happy.

@rdumusc
Copy link

rdumusc commented Jun 8, 2017

On second thought, I still think that the real problem is Equalizer trying to hide its subproject dependencies. This workaround is for a use case we should not support, because the hidden dependencies bypass the CI checks but may fail later in the super-project case. CommonFindPackage does not have anything to do with -install targets, which are project-to-project relationships for the Subprojects use case.

@eile
Copy link
Member Author

eile commented Jun 8, 2017

No, the real problem is that CMake does not provide a Target-install target which installs the target fully. I'm happy to explain the details in person.

eile pushed a commit to eile/CMake that referenced this pull request Jun 8, 2017
@eile
Copy link
Member Author

eile commented Jun 8, 2017

ping

endif()

function(COMMON_ADD_INSTALL_DEPENDENCIES)
# redo dependency chaining each time: a new common_find_package might have been called
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can be removed now

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done


function(COMMON_ADD_INSTALL_DEPENDENCIES)
# redo dependency chaining each time: a new common_find_package might have been called
string(REPLACE " " ";" __deps "${ARGN}") # string-to-list
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No longer needed I think, CMake expends the list when calling the function

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It won't. I tested.

@eile eile merged commit f139d9f into Eyescale:master Jun 8, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants