Adding support for linux and also fixing the stability on builds for osx #30
Conversation
Favour a resource dir passed in over one baked in via cmake if the user needs to overwrite it
…and removing some merge markers left in
…a hit to the FS on other systems
|
To me it looks like this is overcomplicating things. I also patched hyde to make it usable on Linux and wanted to the changes after some cleanup. You can compare the changes here. I don't know what Apple Clang does, but at least open source LLVM and Clang install a CMake config, so all that needs to be done is to |
|
That doesn’t come along with clang on OS X. The defacto package manager on
OS X is homebrew it doesn’t install it in anywhere that cmake can find by
default. That’s the extra code in the cmake file, just telling cmake where
to look for clang with find_package.
I had a chat to the llvm team on irc and they recommended the resource dir
going forward, but I’ll take a look at your patch and see if works on both
OS X and Linux. We won’t be able to avoid the extra include path change
though. Clang by default looks in /usr/include but from 10.14 onwards OS X
doesn’t install its headers into there anymore.
…On Tue, 22 Jan 2019 at 11:08 pm, Morris Hafner ***@***.***> wrote:
To me it looks like this is overcomplicating things. I also patched hyde
to make it usable on Linux and wanted to submit them after some cleanup.
You can compare the changes here
<master...mmha:4b24d04fae8fa31b47934c188b64ef38261ca764>
.
I don't know what Apple Clang does, but at least open source LLVM and
Clang install a CMake config, so all that needs to be done is to
find_package(Clang).
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#30 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AASId9jn6XabDZMmHmn6TxgiT0VunP4Fks5vFv89gaJpZM4aKQBH>
.
|
|
Right. As you might have guessed I don't use Apple, so I can't test it there. But it looks like you can simplify the code by doing this instead: if(APPLE)
list(APPEND CMAKE_PREFIX_PATH "/usr/local/Cellar/llvm/" "/usr/local/Cellar/boost/" "/usr/local/Cellar/yaml-cpp/")
endif()
find_package(Clang)
find_package(Boost)
find_package(yaml-cpp)and the rest would stay the same as with my patch. Although the |
|
This doesn't won't work as LLVM installs into "/usr/local/Cellar/llvm/{version}/" and doesn't symlink into I just tried your branch out on osx and after I make the edits to be able to locate the clang package. I can't build hyde on OSX it can't locate a bunch of llvm/clang headers :( I'll see if I can get it to work on osx. I am liking your approach with the configuration files so at a minimum I might ask that we can borrow that idea. |
|
That's unfortunate, but yeah, there's no other way then. You can take what you need from my branch. I wanted to create a PR with that anyways (followed by another PR to enable porting existing Doxygen comments) :) |
|
Yup. I may try upstream the a change to create the symlink ala boost in clang/llvm this should really simplify the cmake file. There will still be the ugly mac only include stuff though. It seems apples clang includes the path by default, where as the open source clang doesn't. |
This sets the resource_dir that is available in later version of clang. This makes finding system headers much easier.
This also includes the location of /usr/include so that newer versions that include it in /Library can find it.
This also updates the way that cmake finds the homebrew version of llvm since it is versioned and not symlinked in like other libs.
There are also changes to generate_test_files so that it goes looking for hyde depending on how you generate your project. It will also use verbose by default to help in debugging.