search

jeremy-rifkin / cpptrace

Simple, portable, and self-contained stacktrace library for C++11 and newer
MIT License
621 stars 64 forks source link

Support for Bazel Build System #139

Closed WSUFan closed 2 weeks ago

WSUFan commented 2 months ago

Are you interested in supporting Bazel as an additional build system for this project? Bazel is a powerful build tool that offers many advantages, such as fast incremental builds, a flexible build language, and support for large-scale projects. More details can be found here. I can create a PR to provide an initial implementation. Please let me know your thoughts. Thanks

jeremy-rifkin commented 2 months ago

Thanks for opening this, in general I'd be happy to support anything people would find useful. The CMake setup for this library does a ton of heavy lifting to figure out what is supported on a given system and find an ideal configuration for back-ends. My main concern with trying to add support for another build system is duplicating all that logic and then ultimately having to maintain both.

To help me understand context, would your goal be simply to allow the library to be included in a Bazel project or does Bazel have some way of easily including other Bazel projects similar to CMake's FetchContent?

WSUFan commented 2 months ago

Thank you for your thoughtful response. My primary goal is to allow the library to be included in a Bazel project. This can be done through bzlmod. Similar to how CMake's FetchContent works, Bazel can use following syntax to include other Bazel project: image

Compared to CMake, these are how Bazel determines system capabilities: Bazel typically relies on toolchains to provide the necessary configuration and environment settings for a build. Toolchains in Bazel are defined in BUILD and WORKSPACE files, which specify the compiler, linker, and other tools required for building the project. Unlike CMake, Bazel does not dynamically test system capabilities during the configuration phase. Instead, it relies on predefined toolchains that are set up to match the target environment. This approach ensures consistency and reproducibility across different environments. In most cases, toolchains are predefined by Bazel officially.

Some advantages of using Bazel over CMake include: Speed: Bazel can build large codebases quickly and efficiently by leveraging parallel execution and remote caching. Incremental Builds: Bazel is designed for fast incremental builds, only rebuilding what is necessary. Hermetic Builds: Bazel ensures that builds are reproducible by isolating them from the host system's environment. Scalability: Bazel is capable of handling very large projects with complex dependencies, which makes it suitable for monorepos.

WSUFan commented 2 months ago

In my initial implementation with Bazel, building cpptrace takes 8 seconds (including fetching third-party dependencies), whereas using CMake takes 15 seconds.

jeremy-rifkin commented 2 months ago

I see why bazel can be appealing. One feature of this library that has been important to me is being as close to zero configuration as possible, which cmake handles currently. It sounds to me like a toolchain-based approach would require some manual configuration, e.g. for whether _dl_find_object is supported vs dladdr1 vs dladdr. However I'm not familiar with bazel's implementation so I'm just making uneducated guesses in my mind about what it'd look like.

If you would like to make a PR to add a bazel implementation alongside the normal cmake implementation I'd be happy to merge, though I likely can't maintain the bazel implementation.

WSUFan commented 4 weeks ago

One possible implementaion: https://github.com/jeremy-rifkin/cpptrace/pull/153 I only enable Linux build