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

Add host prefix to NVCC_PREPEND_FLAGS when using conda-build #19

Merged
merged 11 commits into from
Jun 7, 2023

Conversation

carterbox
Copy link
Member

@carterbox carterbox commented Jun 2, 2023

Adds the host requirements prefix include-paths and linking-search-paths to the NVCC_PREPEND_FLAGS for conda-build (because those two prefixes are separate) by using an activation script only when conda-build is active.

Outside of the conda-build context, these paths are not needed because nvcc would share a prefix with all the cuda libs.

I didn't do anything for Windows because it's skipped.

Checklist

  • Used a personal fork of the feedstock to propose changes
  • Bumped the build number (if the version is unchanged)
  • Reset the build number to 0 (if the version changed)
  • Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
  • Ensured the license file is being packaged.

Closes #18
Closes conda-forge/libcublas-feedstock#11
Requires conda-forge/cuda-nvcc-impl-feedstock#2

@carterbox carterbox requested a review from adibbley as a code owner June 2, 2023 16:32
@conda-forge-webservices
Copy link
Contributor

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@carterbox
Copy link
Member Author

@conda-forge-admin, please rerender

@@ -27,6 +27,7 @@ export CFLAGS="${CFLAGS} ${CUDA_CFLAGS} ${CUDA_LDFLAGS}"
export CPPFLAGS="${CPPFLAGS} ${CUDA_CFLAGS} ${CUDA_LDFLAGS}"
export CXXFLAGS="${CXXFLAGS} ${CUDA_CFLAGS} ${CUDA_LDFLAGS}"
export LDFLAGS="${LDFLAGS} ${CUDA_LDFLAGS}"
export CUDAFLAGS="${CUDAFLAGS} ${CUDA_CFLAGS}"
Copy link
Member

Choose a reason for hiding this comment

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

Do we want the LDFLAGS too or just CFLAGS?

Suggested change
export CUDAFLAGS="${CUDAFLAGS} ${CUDA_CFLAGS}"
export CUDAFLAGS="${CUDAFLAGS} ${CUDA_CFLAGS} ${CUDA_LDFLAGS}"

Copy link
Member Author

Choose a reason for hiding this comment

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

I don't think the library paths are needed because NVCC isn't being used as a linker? For example, the libmagma feedstock (which has separable compilation off for linux) uses GCC to link all of the generated object files as the last step, not NVCC. The library paths are only needed at link-time, the headers are only needed at compile time?

Copy link
Member Author

@carterbox carterbox Jun 2, 2023

Choose a reason for hiding this comment

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

I'm not sure if people ever use the NVCC CLI for linking or whether NVCC accepts / passes these args down to the host compiler.

Copy link
Member

Choose a reason for hiding this comment

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

CUDA_LDFLAGS should only be in LDFLAGS. I don't know why CUDA_LDFLAGS was added to CXXFLAGS and friends. That's clearly wrong.

Copy link
Member

Choose a reason for hiding this comment

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

Maybe this should go in a separate issue or PR? Doesn't seem related to Daniel's initial request

Copy link
Member Author

Choose a reason for hiding this comment

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

Restored this part of the PR to match upstream. Some else can fix the LDFLAGS issue if they feel strongly about it.

@jakirkham
Copy link
Member

Thanks Daniel! 🙏

Had a question above 🙂

Copy link
Member

@jakirkham jakirkham left a comment

Choose a reason for hiding this comment

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

Think it would be reasonable to handle the LDFLAGS changes in a separate PR as that was not part of the original changes here

That said, if the OP wants to include them here, the CUDA_* variables likely need other updates (to include library search paths)

recipe/meta.yaml Outdated Show resolved Hide resolved
@@ -27,6 +27,7 @@ export CFLAGS="${CFLAGS} ${CUDA_CFLAGS} ${CUDA_LDFLAGS}"
export CPPFLAGS="${CPPFLAGS} ${CUDA_CFLAGS} ${CUDA_LDFLAGS}"
export CXXFLAGS="${CXXFLAGS} ${CUDA_CFLAGS} ${CUDA_LDFLAGS}"
export LDFLAGS="${LDFLAGS} ${CUDA_LDFLAGS}"
export CUDAFLAGS="${CUDAFLAGS} ${CUDA_CFLAGS}"
Copy link
Member

Choose a reason for hiding this comment

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

Maybe this should go in a separate issue or PR? Doesn't seem related to Daniel's initial request

recipe/activate.sh Outdated Show resolved Hide resolved
carterbox added a commit to carterbox/cuda-nvcc-impl-feedstock that referenced this pull request Jun 6, 2023
@isuruf
Copy link
Member

isuruf commented Jun 6, 2023

I don't think we should introduce new env variables into the mix. Better to use NVCC_PREPEND_FLAGS.

@carterbox carterbox changed the title Add CUDAFLAGS to activate script Add host prefix to NVCC_PREPEND_ARGS when using conda-build Jun 6, 2023
@carterbox carterbox changed the title Add host prefix to NVCC_PREPEND_ARGS when using conda-build Add host prefix to NVCC_PREPEND_FLAGS when using conda-build Jun 6, 2023
@carterbox
Copy link
Member Author

I tested this on a local build of the magma-feedstock. It seems to work, but silently. i.e. The args don't appear in the build logs.

Copy link
Member

@jakirkham jakirkham left a comment

Choose a reason for hiding this comment

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

Thanks Daniel! 🙏

This seems reasonable. Had a couple follow up questions

recipe/activate.sh Outdated Show resolved Hide resolved
recipe/activate.sh Outdated Show resolved Hide resolved
@jakirkham
Copy link
Member

The args don't appear in the build logs.

Maybe we should considering adding set -x at the top and set +x at the end (since it is sourced)?

Copy link
Contributor

@bdice bdice left a comment

Choose a reason for hiding this comment

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

I tested these changes locally and can confirm it fixes the issues I saw in the conda build process for nvcc in the build environment to search the host environment.

@carterbox
Copy link
Member Author

This is the one, people. Let's get this patch out before the CUDA 12 migration is too far along. 😆

Copy link
Member

@jakirkham jakirkham left a comment

Choose a reason for hiding this comment

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

Thanks Daniel! 🙏

If it's ok, would set -ccbin first (included a suggestion)

Otherwise agree. Let's merge after that 🙂

recipe/activate.sh Outdated Show resolved Hide resolved
recipe/activate.sh Outdated Show resolved Hide resolved
@jakirkham jakirkham merged commit f602ed9 into conda-forge:main Jun 7, 2023
@jakirkham
Copy link
Member

Thanks Daniel for the PR and everyone for reviewing! 🙏

Let's get this change out. We can follow up on anything else separately

@robertmaynard
Copy link
Contributor

I don't think we should introduce new env variables into the mix. Better to use NVCC_PREPEND_FLAGS.

I wanted to use a different env variable and inject into nvcc.profile so that CMake would be able to use these include and link directories as they would be in the INCLUDES and LIBRARIES output of nvcc ( https://gitlab.kitware.com/cmake/cmake/-/issues/24915 ). By using NVCC_PREPEND_FLAGS those directories will not be considered by CMake as that is a user flag and not part of the compiler implicit information.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
5 participants