Trinkle23897
commented
2 years ago Previously, we were seriously considering using cmake instead of bazel to build the open-source version of envpool. A fun fact is that the first internal version of envpool is built with cmake. However, after spending some time developing envpool in c++, we finally realized it's a huge benefit to use bazel instead of cmake for other integration. Here are the reasons:
- It's easier to integrate new envs with bazel than cmake. #141 is a great example (though it hasn't been merged yet, it works). You only need to find all source code's name list, and create a BUILD file, and that's done. I wrote a detailed tutorial to explain how it works: https://envpool.readthedocs.io/en/latest/content/build.html
- Bazel can support partial unit test can cache previous build/test result. This can save a lot of time for CI. Another example is ray. They also use bazel to build and test, even in rllib -- a pure python library. Bazel can easily discover the dependency of a specific test, while cmake can't.
Overall, in our opinion, bazel can do what cmake can do, and can also do what cmake can't do. So that's why we choose bazel for the open-source release instead of continuing using cmake. We are also using C++, and we don't think it's a sacrifice for C++ user experience -- otherwise, why Google uses bazel instead of cmake in all its product?
walkacross
Motivation
thanks for this nice library, which is trying to provide is a general solution for various kinds of speeding-up RL environment parallelization. Currently, envpool treats the python users are first class citizens, ignoring and sacrificing the c++ user experience.
Solution
add cmake build method, make it easier for adding envpool as a third-party dependency in c++ environment, where users are not familiar with bazel or in condition which make the use of bazel infeasible.