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

[question] Handling OpenMP in recipes #1012

Open
Morwenn opened this issue Mar 2, 2020 · 6 comments
Open

[question] Handling OpenMP in recipes #1012

Morwenn opened this issue Mar 2, 2020 · 6 comments
Labels
question Further information is requested

Comments

@Morwenn
Copy link
Contributor

Morwenn commented Mar 2, 2020

Several libraries optionally handles OpenMP and generally require specific compiler and linker options in order to do so, including when one needs to link against them. What would be the best way to handle such packages in CII?

@Morwenn Morwenn added the question Further information is requested label Mar 2, 2020
@danimtb
Copy link
Member

danimtb commented Mar 2, 2020

if the OpenMP support is done with an already supported compiler in CCI, I'd say that adding a recipe option and the required flags will be enough to enable openmp support in the recipes

@Morwenn
Copy link
Contributor Author

Morwenn commented Mar 2, 2020

Most recipes I've seen add the following flags unconditionally to package_info:

self.cpp_info.cppflags = ["-fopenmp"]
self.cpp_info.sharedlinkflags = ["-fopenmp"]

However it fails with some configurations and I learnt recently that cpp_info.cppflags is going away, even very soon for the future users of CONAN_V2_MODE.

@danimtb
Copy link
Member

danimtb commented Mar 3, 2020

self.cpp_info.cppflags is deprecated in favor of self.cpp_info.cxxflags that is already available. So you can still use that possibility.

Should OpenMP be a "system requirement recipe" like the ones discussed in #641 or is it just a compiler optimization?

@jasal82
Copy link

jasal82 commented Aug 20, 2020

I think that -fopenmp is a special case because it does multiple things and it's not even consistent across the platforms. Usually it will enable linkage against libgomp and omp pragma processing during compilation. So it's actually both, a system requirement and a compiler optimization, dependent on one another. The cxxflags/sharedlinkflags approach is a good start but one might want to add an option for it to enable/disable it.

@philsuess
Copy link

Stumbling on this when porting to conan v2. What is the conanical (see what I did there?) way in conan 2?

@valgur
Copy link
Contributor

valgur commented Oct 30, 2024

Basically this:

def requirements(self):
    if self.options.with_openmp and self.settings.compiler in ["clang", "apple-clang"]:
        self.requires("llvm-openmp/17.0.6", transitive_headers=True, transitive_libs=True)

@property
def _openmp_flags(self):
    if self.settings.compiler == "clang":
        return ["-fopenmp=libomp"]
    elif self.settings.compiler == "apple-clang":
        return ["-Xclang", "-fopenmp"]
    elif self.settings.compiler == "gcc":
        return ["-fopenmp"]
    elif self.settings.compiler == "intel-cc":
        return ["-Qopenmp"]
    elif self.settings.compiler == "sun-cc":
        return ["-xopenmp"]
    elif is_msvc(self):
        return ["-openmp"]
    return None

def package_info(self):
    ...
    if self.options.with_openmp:
        if self.settings.compiler in ["clang", "apple-clang"]:
            self.cpp_info.requires.append("llvm-openmp::llvm-openmp")
        openmp_flags = self._openmp_flags
        self.cpp_info.cflags = openmp_flags
        self.cpp_info.cxxflags = openmp_flags
        self.cpp_info.sharedlinkflags = openmp_flags
        self.cpp_info.exelinkflags = openmp_flags

Only set the cflags and cxxflags if #pragma omp is used somewhere in the public headers of the library.

For more details about OpenMP and Conan/CCI see:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

5 participants