Linux distro packaging about adaptivecpp HOT 6 OPEN

syclcc.json likely needs to customizable by every user, from /etc/hipSYCL to ~/.hipSYCL/

Why? syclcc.json only provides defaults for the compiler toolchain configuration. Why would users have to modify that? If they want to add additional backends or similar, they will need to rebuild AdaptiveCpp anyway.

ex/ HIP is not found at the prefix is /opt/ROCm/.. is its /usr

There is a cmake variable to change the ROCm path.

no rpath usage

This was already discussed. I believe most of the rpath usage we do is in compliance with Fedora guidelines as internal libraries. #1014 (comment)

lib -> lib64

Why not just install AdaptiveCpp to /opt/AdaptiveCpp? This is far better tested, and you will have a much easier time with this.

EDIT: Instead of a single monolithic package, IMHO A better way to package it is to split it up into a core package, and optional backend-specific packages which provide support for particular backends.. This allows containing backend-specific dependencies like CUDA or ROCm to the backend packages that actually need them. Users can then install the components they actually need for their system.
This works because backend plugins are discovered at runtime. When building, currently you'd need a full build with everything enabled, and then only include those files in the package that are neded for that component.

from adaptivecpp.

A user specific config may be necessary because the user may not be using the default compiler or some other knob syclcc.json controls. A user will not have write access to /etc and if they did would interfere with other users use of the shared file.

Why not /opt/AdaptiveCpp is same as why not /opt/ROCm ?
We have moved ROCm from /opt/ROCm to well known system locations /usr/include, /usr/lib64 etc.
This allows other packages and users to not have to know a per-package install location.
I expect the same to be required for AdaptiveCpp and there will be similar testing issues.

Splitting the package into subpackages is the likely path.
Because ROCm is in Fedora we can build against it and it will be a backend.
CUDA is not in Fedora so we can not build against it so will not be a backend.

from adaptivecpp.

A user specific config may be necessary because the user may not be using the default compiler or some other knob syclcc.json controls

I'm not sure this makes sense. syclcc.json contains a lot of internal stuff. Its main purpose is to relay information from cmake build time to acpp. The vast majority of our compilation flows are clang-based, and use additional clang/LLVM passes. You cannot just change the underlying clang as you likely would have to rebuild AdaptiveCpp due to ABI incompatibility between various LLVM versions.
If you want to change something about the configuration, I think you can already do this. Almost everything that is in syclcc.json can be overriden using environment variables or compiler flags. If a user really knows what they are doing (most will not) they can already just set some environment variables and put that into their shell configuration or similar. Or just pass the appropriate flag to acpp. There is no user-relevant knob that can only be controlled via syclcc.json.

Splitting the package into subpackages is the likely path.
Because ROCm is in Fedora we can build against it and it will be a backend.
CUDA is not in Fedora so we can not build against it so will not be a backend.

There is a lot of software with CUDA support. How does Fedora handle this dependency for other software?

from adaptivecpp.

CUDA is not open source, it can not be packaged, so it can not be used to build other packages. This will not prevent an user from building their own.

Because ROCm is packaged on Fedora, we can use it to build other packages, like yours. The ROCm we build against is Fedora's ROCm, not AMD's. So the install location for ROCm is the standard unix locations /usr not the /opt/ROCm location.

I would like to have an adaptivecpp-rocm package as part of Fedora, but it will have to install to the expected, for fedora, standard locations. As ROCm is being added to other distros, I would expect the other distros would also want to package adaptivecpp and would need it conform to their standard locations.

from adaptivecpp.

I'm open to making the lib-prefix configurable, but I'm not yet convinced of the need for the other changes you have proposed. E.g. as I said, all our rpath usage is for internal libraries.

from adaptivecpp.

CMake's GNUInstallDirs module seems to be a good solution here, but the acpp wrapper would also need to be modified to use the correct path for libraries (and, optionally, includes). Would it be acceptable to make it CMake-generatable (i.e., acpp.py.in + file(CONFIGURE ...))?

from adaptivecpp.