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

Checks for llvm versions break on minor version update of llvm #573

Closed
dvzrv opened this issue Apr 16, 2021 · 7 comments
Closed

Checks for llvm versions break on minor version update of llvm #573

dvzrv opened this issue Apr 16, 2021 · 7 comments

Comments

@dvzrv
Copy link
Contributor

dvzrv commented Apr 16, 2021

Hi! When building faust 2.30.5 I used llvm 11.0.0.
After an upgrade to llvm 11.1.0 a (re)build breaks, because some files rely on overly explicit preprocessor macros: https://github.com/grame-cncm/faust/search?q=LLVM_110

llvm 11.1.0 exposes LLVM_111 instead of LLVM_110 and the build breaks.
Maybe this can be somehow improved by relying on "greater than" comparison or by utilizing the LLVM_VERSION, which exposes the complete version string?

@sletz
Copy link
Member

sletz commented Apr 16, 2021

This has been fixed in 5fbe042

archlinux-github pushed a commit to archlinux/svntogit-community that referenced this issue Apr 16, 2021
Fix preprocessor conditionals that are too specific:
grame-cncm/faust#573
Change ruby optdepends to ruby-rexml:
grame-cncm/faust#572

git-svn-id: file:///srv/repos/svn-community/svn@919521 9fca08f4-af9d-4005-b8df-a31f2cc04f65
archlinux-github pushed a commit to archlinux/svntogit-community that referenced this issue Apr 16, 2021
Fix preprocessor conditionals that are too specific:
grame-cncm/faust#573
Change ruby optdepends to ruby-rexml:
grame-cncm/faust#572

git-svn-id: file:///srv/repos/svn-community/svn@919521 9fca08f4-af9d-4005-b8df-a31f2cc04f65
@dvzrv
Copy link
Contributor Author

dvzrv commented Apr 16, 2021

I don't think so. The above search link still shows e.g. the remaining explicit matches against LLVM_110 (but not LLVM_111).

@sletz
Copy link
Member

sletz commented Apr 16, 2021

Build on macOS gives this kind of log: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -DCPP_BUILD -DCSHARP_BUILD -DC_BUILD -DDLANG_BUILD -DFIR_BUILD -DINTERP_BUILD -DJAVA_BUILD -DLIBDIR=\"lib\" -DLLVM_110 -DLLVM_BUILD -DLLVM_VERSION=\"11.1.0\" -DOCPP_BUILD -DRUST_BUILD -DSOUL_BUILD -DWASM_BUILD

Building with macports: https://ports.macports.org/port/llvm-11/summary

@dvzrv
Copy link
Contributor Author

dvzrv commented Apr 16, 2021

Hm, looking at our build script for llvm, I don't see anything that would suggest our distribution build deliberately choosing LLVM_111 over LLVM_110.

Given that macports applies many more patches than us, it's more likely that exposing LLVM_110 when using llvm 11.1.0 is a bug (but I am not an llvm expert ;-) ).

Besides that, do you think that there's a way of doing conditional checks against the version string in the remaining locations, that do not rely on LLVM_*?

@sletz
Copy link
Member

sletz commented Apr 16, 2021

Besides that, do you think that there's a way of doing conditional checks against the version string in the remaining locations, that do not rely on LLVM_*?

What do you mean?

@dvzrv
Copy link
Contributor Author

dvzrv commented Apr 16, 2021

To do what is described in the initial ticket text and not rely on LLVM_* (https://github.com/grame-cncm/faust/search?q=LLVM_110) but to make use of LLVM_VERSION instead.

@dvzrv
Copy link
Contributor Author

dvzrv commented Apr 16, 2021

@sletz argh, nevermind. I just now realized what that change you mentioned actually does! 🙄

Nevermind the noise!

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

No branches or pull requests

2 participants