You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be beneficial to split the compiler_gym package into multiple packages. Currently, everything is built and installed together with the core runtime stuff + the environments. The environments should be installed separately per user's choice.
Motivation
I don't know if there is a goal for proliferation of environments and where they will be hosted, but the facilities for creating new environments should be available in a library form. This can mostly include the C++ stuff from compiler_gym/service and compiler_gym/util. Currently you could not easily reuse this code if the environment is not a part of the CompilerGym build.
The introduction of the MLIR environment #652 encountered the problem with conflicting multiple versions of LLVM. This is due to CMake's legacy how find_package works #568 (comment). This problem will be automatically solved if there is no mono build and each environment is built as a separate package.
Pitch
Split the compiler_gym package into packages each with a separate build.
compiler_gym # runtime
compiler_gym[dev] # development
compiler_gym[gcc]
compiler_gym[llvm]
compiler_gym[loop_tool]
compiler_gym[mlir]
The text was updated successfully, but these errors were encountered:
I think splitting the cmake build into separate packages is great for solving the problem of conflicting version of LLVM, and for making it possible to develop a new environment without needing to fork the main CompilerGym repo.
One clarification is that I think this split should only apply to the build system. The Python wheel (as installed by pip install compiler_gym) should include all of the GCC/LLVM/MLIR/loop_tool environments. I don't think there's any need to split the compiler_gym wheel unless the number of environments grows so large that it becomes prohibitively expensive to ship a single wheel, which I think is a long way off 🙂
Do you think we should add the C++ development library for the gRPC service to the python package?
The other option is the user to build it from source and install it through CMake directly.
If I understand the question properly, I think the C++ development libraries should be kept separate from the python wheel. So in C++ / CMake land you can do:
🚀 Feature
It would be beneficial to split the
compiler_gym
package into multiple packages. Currently, everything is built and installed together with the core runtime stuff + the environments. The environments should be installed separately per user's choice.Motivation
I don't know if there is a goal for proliferation of environments and where they will be hosted, but the facilities for creating new environments should be available in a library form. This can mostly include the C++ stuff from
compiler_gym/service
andcompiler_gym/util
. Currently you could not easily reuse this code if the environment is not a part of the CompilerGym build.The introduction of the MLIR environment #652 encountered the problem with conflicting multiple versions of LLVM. This is due to CMake's legacy how
find_package
works #568 (comment). This problem will be automatically solved if there is no mono build and each environment is built as a separate package.Pitch
Split the
compiler_gym
package into packages each with a separate build.The text was updated successfully, but these errors were encountered: