skvadrik
commented
1 year ago First of all, thanks for the PR!
However, after looking at it, I must say that it is too complex to maintain (as part of re2c).
It is a whole new build system with its own intricacies (a lot of non-trivial custom rules in the /bazel subdirectory) that duplicates build logic already duplicated in CMake and Autotools. It's hard enough to keep two existing build systems in sync, but keeping three of them in sync is not realistic at all. And having divergent build systems is not good for any project.
Even if we bring it on par with Autotools and CMake (which is not easy), it will require a whole new set of Github Actions to test all the added build logic. They will take time on the runners, and they will require maintenance as well.
For this reason I'd much prefer to have this in a separate repo, not as part of the re2c source code. The repo can use re2c as a subproject. And it can be referenced from re2c documentation and website, so that people will discover it. What do you think?
I'm also open to the minimal CMake subset of changes that will make plumbing easier for you.
If later Bazel conquers the world and many re2c users need it, we can reconsider merging it in the re2c repo.
Bazel can be used as a tool in foreign bazel projects. There is allso some (yet incomplete) support for developing re2c using bazel.
There are two modes of bazel integration:
1) Using
BUILD.bazelbuilds re2c using bazel's actual build support. This way supports toolchains and with that any compiler or cross compilation automatically. However, this version assumes some posix compliant functions and headers.2) Using the alternative
BUILD.cmake.bazelfile will build re2c using its cmake build support (https://github.com/bazelbuild/rules_foreign_cc). This option is slower and intended for cases with an existing toolchain.Limitations: