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 bolt #22204

Open
wants to merge 30 commits into
base: main
Choose a base branch
from
Open

add bolt #22204

wants to merge 30 commits into from

Conversation

h-vetinari
Copy link
Member

Fixes conda-forge/llvmdev-feedstock#147

Towards #13019

Checklist

  • Title of this PR is meaningful: e.g. "Adding my_nifty_package", not "updated meta.yaml".
  • License file is packaged (see here for an example).
  • Source is from official source.
  • Package does not vendor other packages. (If a package uses the source of another package, they should be separate packages or the licenses of all packages need to be packaged).
  • If static libraries are linked in, the license of the static library is packaged.
  • Package does not ship static libraries. If static libraries are needed, follow CFEP-18.
  • Build number is 0.
  • A tarball (url) rather than a repo (e.g. git_url) is used in your recipe (see here for more details).
  • GitHub users listed in the maintainer section have posted a comment confirming they are willing to be listed there.
  • When in trouble, please check our knowledge base documentation before pinging a team.

@conda-forge-webservices
Copy link

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

I wanted to let you know that I linted all conda-recipes in your PR (recipes/bolt) and found some lint.

Here's what I've got...

For recipes/bolt:

  • requirements: build: clangdev == 15.0.7 should not contain a space between relational operator and the version, i.e. clangdev ==15.0.7
  • requirements: host: clangdev == 15.0.7 should not contain a space between relational operator and the version, i.e. clangdev ==15.0.7

For recipes/bolt:

  • Recipe with the same name exists in bioconda: please discuss with @conda-forge/bioconda-recipes.

@conda-forge-webservices
Copy link

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 (recipes/bolt) and found it was in an excellent condition.

I do have some suggestions for making it better though...

For recipes/bolt:

  • Recipe with the same name exists in bioconda: please discuss with @conda-forge/bioconda-recipes.

@conda-forge-webservices
Copy link

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 (recipes/bolt) and found it was in an excellent condition.

@h-vetinari
Copy link
Member Author

Looks like the pyston people have been packaging bolt for their conda channel already, but in the full build variant (i.e. using -DLLVM_ENABLE_PROJECTS=...), not against existing llvm & clang.

@h-vetinari
Copy link
Member Author

I don't really understand why X86CommonTableGen can't be found in llvmdev, where it's built. Perhaps we're not installing whatever public_tablegen_target means correctly?

Copy link

stale bot commented Dec 31, 2023

Hi friend!

We really, really, really appreciate that you have taken the time to make a PR on conda-forge/staged-recipes! conda-forge only exists because people like you donate their time to build and maintain conda recipes for use by the community.

In an effort to maintain this repository and increase the signal-to-noise for open PRs, the maintainers of staged-recipes close excessively old PRs after six months. This PR will remain open for another month, and then will be closed.

If you'd like to keep it open, please comment/push and we will be happy to oblige! Note that very old PRs will likely need to be rebased on main so that they can be rebuilt with the most recent CI scripts. If you have any trouble, or we missed reviewing this PR in the first place (sorry!), feel free to ping the team using a special command in a comment on the PR to get the attention of the staged-recipes team.

Cheers and thank you for contributing to this community effort!

@stale stale bot added the stale will be closed in 30 days label Dec 31, 2023
@h-vetinari
Copy link
Member Author

not stale

@stale stale bot removed the stale will be closed in 30 days label Jan 2, 2024
@conda-forge-webservices
Copy link

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 (recipes/bolt/meta.yaml) and found it was in an excellent condition.

@h-vetinari
Copy link
Member Author

Updated based on discussion in conda-forge/llvmdev-feedstock#276; essentially using the state from conda-forge/llvmdev-feedstock#279, minus obviously the bits that package llvmdev

@h-vetinari
Copy link
Member Author

This will fail on windows due to some missing components in the azure images; on the llvmdev feedstock we're working around this with conda-forge/llvmdev-feedstock@221c9f3 (and I can do the same for bolt once this is merged). If the situation persists, I guess we'll have to teach smithy how to do that.

@h-vetinari
Copy link
Member Author

@isuruf, would you like to review? It should be a pretty simple recipe now. Another advantage of splitting this off is that we won't miss any other files that bolt might install (and I did miss one binary - merge-fdata).

recipes/bolt/meta.yaml Outdated Show resolved Hide resolved
{% endfor %}
# only on linux-64
- test -f $PREFIX/lib/libbolt_rt_hugify.a # [linux64]
- test -f $PREFIX/lib/libbolt_rt_instr.a # [linux64]
Copy link
Member

Choose a reason for hiding this comment

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

Also check that the cmake files are here

Copy link
Member Author

Choose a reason for hiding this comment

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

Only way to do that currently is to clobber

lib/cmake/llvm/LLVM-Config.cmake
lib/cmake/llvm/LLVMConfig.cmake
lib/cmake/llvm/LLVMConfigVersion.cmake
lib/cmake/llvm/LLVMExports-release.cmake
lib/cmake/llvm/LLVMExports.cmake

from llvmdev, unfortunately. But I guess better than nothing.

Copy link
Member

Choose a reason for hiding this comment

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

bolt doesn't have different cmake files?

Copy link
Member Author

Choose a reason for hiding this comment

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

nope, it's built as part of llvm. I guess we could ask for separate CMake files in the "standalone" upstream PR...

Copy link
Member Author

Choose a reason for hiding this comment

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

Does this change your opinion somehow, or are you fine with the always_include_files: (0e96961)?

Copy link
Member Author

Choose a reason for hiding this comment

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

@isuruf, could you let me know how you'd like to proceed with the CMake metadata here?

Copy link
Member

Choose a reason for hiding this comment

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

Let's make libbolt-devel depend on llvmdev

Copy link
Member Author

Choose a reason for hiding this comment

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

Thanks. I'm planning to merge this once CI passes (well, on unix at least; the rest I'll fix on the feedstock).

Copy link
Member

Choose a reason for hiding this comment

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

Please don't. We require reviews from everyone including core team.

Copy link
Member Author

Choose a reason for hiding this comment

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

Then please don't drip-feed change requests. If there's been two rounds of review and no more open comments are left, it's not unreasonable to think that things are wrapped up.

@h-vetinari
Copy link
Member Author

Ugh, I don't know why always_include_files: isn't working here

ERROR: Glob $PREFIX/lib/cmake/llvm/LLVM-Config.cmake did not match in root_dir $PREFIX
ERROR: Glob $PREFIX/lib/cmake/llvm/LLVMConfig.cmake did not match in root_dir $PREFIX
ERROR: Glob $PREFIX/lib/cmake/llvm/LLVMConfigVersion.cmake did not match in root_dir $PREFIX
ERROR: Glob $PREFIX/lib/cmake/llvm/LLVMExports-release.cmake did not match in root_dir $PREFIX
ERROR: Glob $PREFIX/lib/cmake/llvm/LLVMExports.cmake did not match in root_dir $PREFIX

I've double-checked the paths, and they're there

-- Installing: $SRC_DIR/temp_prefix/lib/cmake/llvm/LLVMExports.cmake
-- Installing: $SRC_DIR/temp_prefix/lib/cmake/llvm/LLVMExports-release.cmake
-- Installing: $SRC_DIR/temp_prefix/lib/cmake/llvm/LLVMConfig.cmake
-- Installing: $SRC_DIR/temp_prefix/lib/cmake/llvm/LLVMConfigVersion.cmake
-- Installing: $SRC_DIR/temp_prefix/lib/cmake/llvm/LLVM-Config.cmake
[...]
+ mkdir -p $PREFIX/lib/cmake/llvm
+ mv ./temp_prefix/lib/libLLVMBOLTCore.a ./temp_prefix/lib/libLLVMBOLTPasses.a ./temp_prefix/lib/libLLVMBOLTProfile.a ./temp_prefix/lib/libLLVMBOLTRewrite.a ./temp_prefix/lib/libLLVMBOLTRuntimeLibs.a ./temp_prefix/lib/libLLVMBOLTTargetAArch64.a ./temp_prefix/lib/libLLVMBOLTTargetX86.a ./temp_prefix/lib/libLLVMBOLTUtils.a $PREFIX/lib
+ mv ./temp_prefix/lib/libbolt_rt_hugify.a ./temp_prefix/lib/libbolt_rt_instr.a $PREFIX/lib
+ mv ./temp_prefix/lib/cmake/llvm $PREFIX/lib/cmake/llvm

recipes/bolt/bld.bat Outdated Show resolved Hide resolved
recipes/bolt/bld.bat Outdated Show resolved Hide resolved
mkdir %LIBRARY_LIB%\cmake\llvm
move .\temp_prefix\lib\LLVMBOLT*.lib %LIBRARY_LIB%
REM copy CMake metadata
move .\temp_prefix\lib\cmake\llvm %LIBRARY_LIB%\cmake\llvm
Copy link
Member

Choose a reason for hiding this comment

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

What about include files?

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 had been wondering about that too, but there's nothing I can find. The only occurrences of include/bolt in the logs (example) are during the build, not during installation. I've now done a regex-search (include/.*bolt) as well, and it only finds false positives

Copy link
Member Author

Choose a reason for hiding this comment

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

If there's anything that goes beyond what's in llvmdev, it's now being installed (4f17e53)

Copy link
Member

Choose a reason for hiding this comment

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

If there are no include files, then we might as well drop libbolt-devel as users can't use those libraries (not easily anyways).

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 know sufficiently well how bolt works, but it's conceivable to me that bolt the binary needs those libraries to actually transform a binary (perhaps embedding some symbols from the support libraries along the way).

It seemed natural to split off the libraries, but if you want, I can just stuff everything into bolt itself.

Comment on lines +86 to +87
- test -f $PREFIX/lib/libbolt_rt_hugify.a # [linux64]
- test -f $PREFIX/lib/libbolt_rt_instr.a # [linux64]
Copy link
Member

Choose a reason for hiding this comment

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

These two should be in bolt as they are used at runtime of bolt. The others are only needed if bolt is used as a library.

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'm not sure (between the two open threads) what you want me to do now. Here you say

The others are only needed if bolt is used as a library.

But in the other you say

If there are no include files, then we might as well drop libbolt-devel as users can't use those libraries

I understood that we'll move libbolt_rt_{hugify,instr} to bolt. But for the rest, do we want to:

  • ship them as libbolt-devel
  • ship them as part of bolt
  • not ship them at all until a use-case comes up

Copy link
Member

Choose a reason for hiding this comment

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

3 is preferred. 1 if not.

Copy link
Member Author

Choose a reason for hiding this comment

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

OK, I found the bolt headers: https://github.com/llvm/llvm-project/tree/main/bolt/include/bolt; no idea why they're not getting installed.

Copy link
Member Author

Choose a reason for hiding this comment

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

Also, I guess we can restrict this to linux until anything changes upstream w.r.t. llvm/llvm-project#72205

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

Successfully merging this pull request may close these issues.

create feedstock for bolt?
3 participants