This find module will have to locate the Bazel-produced artifacts and replicate upstream ccd's interface, including variable and target naming. It also includes packaging (cpack), which makes it relatively easy to produce packages for Linux distributions and Windows. Write your own Findccd.cmake find module, setting the cache variable CMAKE_MODULE_PATH in fcl's build to whichever directory in your source tree contains it. It is open source, very powerful, cross-platform, the de-facto standard for C++.Use CMake to build ccd to get it to generate the correct package configuration files.Otherwise cmake is the one that is most commonly used and works well enough, while I never came across one of the two others. But since you went through Bazel, that file will not exist. ago If make is sufficient and you only target unix, there is no problem with using it. If you had that file, I would suggest setting the cache variable ccd_ROOT to whichever local prefix into which you have installed ccd. You have shot yourself in the foot, here.įcl's find_package statement is going to search for a file called ccd-config.cmake, using the search procedure documented here: How can I get the find_package statement to find the package that I build? This seems fairly brittle as well.I build that package as well, but just using cc_library. My only other thought would be to make a dummy binary target that depends on toplevel_target and then use the resulting params file (which is generated for the final link command) for my own purposes. CMake is also able to generate Ninja files among other formats, check CMake generators documentation for more information. Any better ideas? Pointers to similar work? Being able to use bazel with other build systems is probably something that someone else has done in the past? Ideally, I would be able to write a skylark rule which does this for me, otherwise I'm stuck doing what I describe above. This seems pretty brittle though - bazel should already have all of this information when it's performing the build (and of course bazel utilizes this information when it tries to link a binary or. Naively, I can use cquery to find my transitive dependencies, munge through bazel-bin to find the appropriate files, then stuff them all into the archiver (or something). Somehow we need to gather up all of the artifacts from the transitive dependencies and either pass them to cmake or somehow stuff them all into a single. When you need imperative logic, you can write supporting functions in separate. WORKSPACE files are likewise a nice declarative way of describing your dependencies. BUILD files are high level, mostly declarative, and generally easy on the eyes. It also has a more robust of out-of-the-box support for a lot of external dependencies and/or lots of online examples. CMake is great for IDE integration or if you want to use Ninja. If I misunderstood your question 'Can I identify if the cmake fails', please let me know. Bazel/Buck are also better if you have a multi-lingual project (Java, C++, python etc) as CMake has limited/poor support for that. Otherwise the script will not fail when cmake fails. a file that we can just link against (I have tried this approach when the library doesn't have any dependencies and it works fine). Why convert Bazel to CMake Bazel BUILD files are a nice way to write build systems. If you call out to a shell script in your 'cmd' attribute that then actually runs the cmake commands, make sure to put 'set -e -o pipefail' in the first line of your script yourself. All of these artifacts are needed to make the final build product work. The above bazel invocation actually produces *many* artifacts, not just toplevel_target because it has dependencies.
$ bazel build //somedir/subdir:toplevel_targetĪnd let's say that toplevel_target looks like this:
#BAZEL VS CMAKE CODE#
Some code editors like Microsoft Visual Studio have their own built in build. Here's what Foo's bazel invocation looks like: Popular C/C++ alternative build systems are SCons, CMake, Bazel, and Ninja. Naively, we can use a custom cmake rule (add_custom_target or ExternalProject_Add) to invoke bazel build for Bar however we want, produce Bar's build artifacts, declare that the custom cmake rule produces Bar's artifacts, then use them in Foo's cmake.
Project Foo uses cmake for its build system project Bar uses bazel. We have project Foo which needs to use some code in project Bar. Finally, Bazel is discussed in details and compared to other build tools. Next, the most used build tool at this time, namely Make, is discussed in more details, together with CMake. We recommend LibHunt CMake for discovery and comparisons of trending CMake projects. This, and a broad comparison of characteristics of build systems, will be explained in the first chapter.
#BAZEL VS CMAKE SOFTWARE#
I have a question about using build artifacts from bazel in another build system (cmake). Bazel is a tool that automates software builds and tests. I may post this to stack overflow as well, but I'll try here first.
0 kommentar(er)
