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: Removed files used by nothing in the build system #548

Closed

Conversation

marcusmueller
Copy link
Member

No description provided.

@marcusmueller marcusmueller marked this pull request as draft December 21, 2021 12:13
Signed-off-by: Marcus Müller <marcus@hostalia.de>
Copy link
Contributor

@jdemel jdemel left a comment

Choose a reason for hiding this comment

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

LGTM. Thanks for this simplification!

At first, I thought about bumping the minimum Boost version. However, Boost is only required on old systems that lack compilers with std::filesystem support. A modern system comes with a modern compiler and doesn't require Boost at all.

Copy link
Contributor

@michaelld michaelld left a comment

Choose a reason for hiding this comment

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

1 required change before I'll accept this. Also a meta-discussion, thinking we want to update minimum Boost to something reasonably recent, like even 1.60.0. When was Boost::filesystem added? At issue here is that by keeping min version at 1.35, we still need the Boost_NOGO_VERSIONS stuff from VolkBOOST.cmake. So, either we leave this all alone or we bump the Boost version so-as to not need the NOGO stuff.

PUBLIC ${Boost_INCLUDE_DIRS}
)
target_link_libraries(volk_profile PRIVATE ${Boost_LIBRARIES})
target_link_libraries(volk_profile PRIVATE Boost::filesystem)
Copy link
Contributor

Choose a reason for hiding this comment

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

Still need to use the Boost_INCLUDE_DIRS for includes here

Copy link
Member Author

Choose a reason for hiding this comment

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

target_link_libraries with a config target does add the includes to the target, or am I mistaken?

For example, gnuradio/gr-uhd/lib/CMakeLists.txt: https://github.com/gnuradio/gnuradio/blob/master/gr-uhd/lib/CMakeLists.txt#L34

We target_link_library the gnuradio-uhd target against the UHD::UDH target, which publicly says "hey, include this", which leads to the target automagically gaining these include dependencies.

@marcusmueller
Copy link
Member Author

Re: boost bumping: yes, I'd say we should do that. 1.35 is positively ancient, pulling up with GNU Radio makes sense to me – chances are that non-GR projects that use VOLK have at least the same Boost versions as GR 3.8 could rely on

@marcusmueller marcusmueller marked this pull request as ready for review January 7, 2022 19:52
@jdemel
Copy link
Contributor

jdemel commented Jan 8, 2022

I'm OK to bump the minimum Boost version. I just don't see the need to do so. Say, we bump the minimum version to 1.65. In that case, we can assume a reasonable recent compiler to be available. This compiler will support std::filesystem and thus, we don't need Boost at all.

We removed the last CI case for Linux, when we dropped tests for Ubuntu 14.04.
AppVeyor CI is the only test where we still add Boost. And we can probably remove that too because these tests rely on ancient toolchains.

Long story short. Maybe it's time to have another look at #174 and go through with it.

@jdemel
Copy link
Contributor

jdemel commented Jan 20, 2022

If we decide to finally purge Boost, we would merge #557 and close #174 .
PR #557 supersedes this PR because it goes even further. However, we need to decide if it is time to purge Boost.

@michaelld
Copy link
Contributor

Boost is purged from #557 ... so, closing this PR as it has been superseded!

@michaelld michaelld closed this Feb 6, 2022
@michaelld
Copy link
Contributor

OK ... will be added ... soon. Closing this is safe :)

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.

None yet

3 participants