Alpaka: Remove boost as install dependency

[SimeonEhrig]

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

[ax3l]

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]

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]

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

[SimeonEhrig]

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]

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]

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]

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]

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

[j-stephan]

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]

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]

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... ;-) )