ivan-aksamentov
commented
3 years ago Hey James @jameshadfield ,
Thanks so much. I don't have a mac handy so your help is very appreciated!
Error 1
realpath: command not found
Solution: instruct MacOS uses to install coreutils via homebrew
It's probably also true for Linux.
Alternatively, we might try to get rid of realpath. It's probably not that vital.
Error 2
Solution: instruct uses to add the bincrafters conan remote
Yes, sorry about that. For Linux it's currently in the conan installation script. Should totally tell users. Alternatively, we might use a local conan config somehow (stored in the repo) instead of the global one. The remotes are in ~/.conan/remotes.json.
Error 3
Detected a mismatch for the compiler version between your conan profile settings and CMake:
I think it might be similar but worse version of "Trobleshooting tip #1":
- I have a newer version of a compiler, but conan and cmake keep using the old one
Conan remembers things in a few places:
-
when creating global conan profile with
conan profile new default --detectThe profile is stored in
~/.conan/profiles. I think it remembers a compiler that is the first available inPATH(basicallywhich clangat THAT point in time) -
when running
conan installduring the dev script invocation, it prepares dependencies in the build directory (e.g..build/Debugfor dev mode), which are bound to a specific compiler
Cmake also remembers some things during build files generation, including the compiler in the build directory.
So, currently, switching compilers basically means wiping the build directories, removing the global conan profile, creating a new one and basically starting from scratch. It's as inconvenient as it sounds and a major pain and should be solved. The solution (or at least a part of it) that we need to implement is:
-
use a local conan profile (file or through command line) instead of the global one. In case of file-based profile, compiler field might or might not need to be adjusted when invoking conan.
-
possibly make different build directories for different compilers and compiler versions. That would require detecting compilers, e.g. from
clang --version,gcc--versionetc., which is fragile and no fun, but might work.
The other issue with the current build I don't like is that it's getting pretty complex and is based almost entirely on bash. Maybe we could leverage conanfile in Python format to make it look like something reasonable. But that would require quite a bit of work.
P.S. If users stumble upon this issue: The goal here is to setup a native macOS build (with prospect to further setup a CI and produce binaries), but if you just want to build and run Nextalign on Apple, you could use Docker dev build or a prebuilt images.
jameshadfield
@ivan-aksamentov here's my progress so far
OS: MacOS version 11.1 Bash: GNU bash, version 5.1.4(1)-release (x86_64-apple-darwin20.2.0) Conda 4.9.2
Error 1
realpathisn’t available on MacOS but can be installed viabrew install coreutilsSolution: instruct MacOS uses to install coreutils via homebrew
Error 2
And it appears that boost doesn’t exist in Conan using the default remote(s)?
I added the
bincraftersremote and this fixed itSolution: instruct uses to add the bincrafters conan remote
Error 3
This is a PATH issue - the default MacOS clang compiler is v12, but I installed a conda version of ~10~ 11, which comes first on PATH. Note that this is happening in the “Install dependencies” part of
build_locally.shsocmakeis being called byconan, not the script, and I can’t work out how to change the cmake options so that it looks at the correct compiler!Tried a few things without success:
export CC=/Users/enigma/miniconda3/envs/nextalign/bin/clangdidn’t work, same error.CMakeLists.txtchanged line 17 toset(CMAKE_C_COMPILER /Users/enigma/miniconda3/envs/nextalign/bin/clang)[env] -> PATH=[/Users/enigma/miniconda3/envs/nextalign/bin]to the default conan profile.