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

Remove boost as install dependency #1081

Open
SimeonEhrig opened this issue Jul 14, 2020 · 12 comments
Open

Remove boost as install dependency #1081

SimeonEhrig opened this issue Jul 14, 2020 · 12 comments
Labels
Type:Install installation & packaging

Comments

@SimeonEhrig
Copy link
Member

If you install alpaka via make install, boost should not be a dependency. Boost should only be a dependency when compiling an application with alpaka. It should not be a problem because nothing is compiled when you install alpaka. Without a boost dependency, it is much easier to deploy a Spack and Conda package.

Related to: #962 and #1019

@SimeonEhrig SimeonEhrig changed the title Remove boost as install depency Remove boost as install dependency Jul 14, 2020
@ax3l ax3l added the Type:Install installation & packaging label Jul 16, 2020
@ax3l
Copy link
Member

ax3l commented Jul 16, 2020

Hm, you could only search for Boost with the alpakaConfig.cmake package.. Could be okay... But you have to search for it if alpaka is used via add_subdirectory.
But not exposing the direct dependency in Spack and relying on users to side-channel our transitive dependency is wrong. Spack has high dependency control, "re-install"ing alpaka's headers is fine.

I rather vote to get rid of Boost for variants of Alpaka that do not depend on Boost.Fiber: #481

@psychocoderHPC
Copy link
Member

Removing boost should be possible for alpaka if we reimplement the compiler detection by our own. As I know this is the only part we require from boost.

@BenjaminW3
Copy link
Member

See #481 for removing the boost dependency. There is not much left.

@SimeonEhrig
Copy link
Member Author

Removing boost should be possible for alpaka if we reimplement the compiler detection by our own. As I know this is the only part we require from boost.

My intention was that we only need a boost at build time, so it is not necessary to have a boost installation when we run make install. Removing boosts in general is a different matter.

Hm, you could only search for Boost with the alpakaConfig.cmake package.. Could be okay... But you have to search for it if alpaka is used via add_subdirectory.

Sounds good. I don't think we need to support add_subdirectory anymore since we have make install.

But not exposing the direct dependency in Spack and relying on users to side-channel our transitive dependency is wrong. Spack has high dependency control, "re-install"ing alpaka's headers is fine.

I thought it was possible to define dependencies in Spack independently of real dependencies, didn't I? I think this should solve the dependency problem in Spack, but keep freedom for other building systems.

@j-stephan
Copy link
Member

Sounds good. I don't think we need to support add_subdirectory anymore since we have make install.

Some projects (PIConGPU, cupla) use alpaka in this way I believe. CC @psychocoderHPC

@psychocoderHPC
Copy link
Member

Sounds good. I don't think we need to support add_subdirectory anymore since we have make install.

make install requires to install the library, this is one possible workflow. The other workflow is to work directly with the source tree, somewhere on the disk or as subtree/submodule. This is a native feature of CMake and should be supported.

@SimeonEhrig
Copy link
Member Author

Sounds good. I don't think we need to support add_subdirectory anymore since we have make install.

make install requires to install the library, this is one possible workflow. The other workflow is to work directly with the source tree, somewhere on the disk or as subtree/submodule. This is a native feature of CMake and should be supported.

Okay, then we need to take care of this.

@psychocoderHPC
Copy link
Member

btw: If we remove boost in alpaka we need to handle all the boost workarounds in our user code 😢

@j-stephan
Copy link
Member

btw: If we remove boost in alpaka we need to handle all the boost workarounds in our user code

Couldn't we do compiler detection in CMake? Or are there other parts of Boost that we are using?

@psychocoderHPC
Copy link
Member

Open parts are listed in #481.

Couldn't we do compiler detection in CMake? Or are there other parts of Boost that we are using?

We can not move compiler detection to CMake because we need to handle the Standalone Header too.
Compiler detection will be not so hard. In boost the compiler detection code is small the most code is activating workaround defines for the internal boost implementations.

@ax3l
Copy link
Member

ax3l commented Jul 25, 2020

all the boost workarounds

Not sure what you exactly mean, but I think those are less then you fear :) If we don't use boost we also do not need the work-around for internal boost quirks anymore ;)

Yes, if PMacc/PIConGPU continues to use Boost then there we have to keep the quirks. But they are already controlled from CMake anyway, so we just move them back. (And at some point those code bases might become boost-free too... ;-) )

@bernhardmgruber
Copy link
Member

I ran into this again today because I tried to switch LLAMA to vcpkg manifests, so Boost will be setup for LLAMA, but not for alpaka, which I install as a separate step in the CI. Would be great to be able to run make install on an alpaka clone with examples and tests disabled.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type:Install installation & packaging
Projects
None yet
Development

No branches or pull requests

6 participants