Recently we have refactored build.rs and related machinery to make it easier to support alternative build systems, in particular Bazel and GN. The most recent changes include:
[ ] PR #1962 (thanks @illicitonion!)
[ ] PR #1963
[ ] PR #1965
[ ] PR #1968
[ ] PR #1971
[ ] PR #1975
The above are primarily intended to support the case where somebody has used cargo-vendor/Crate Universe/cargo-raze to bring in the assembly language source files pregenerated (and on Windows, preassembled) from PerlAsm, as done in mk/package.sh. With that in mind, I think the next step is to extend the pregeneration machinery to output Bazel BUILD and/or GN BUILD.gn files, in a way that minimizes the amount of manual BUILD file hacking by people after the fact, by building the generator for the build scripts in build.rs.
For Bazel, we could probably just generate BUILD during mk/package.sh and place it in the root, as I guess that's where people would need the BUILD file to be.
For GN, we could generate an BUILD.gn if an optional output path parameter to mk/package.sh is provided.
Recently we have refactored build.rs and related machinery to make it easier to support alternative build systems, in particular Bazel and GN. The most recent changes include:
The above are primarily intended to support the case where somebody has used cargo-vendor/Crate Universe/cargo-raze to bring in the assembly language source files pregenerated (and on Windows, preassembled) from PerlAsm, as done in mk/package.sh. With that in mind, I think the next step is to extend the pregeneration machinery to output Bazel BUILD and/or GN BUILD.gn files, in a way that minimizes the amount of manual BUILD file hacking by people after the fact, by building the generator for the build scripts in build.rs.
For Bazel, we could probably just generate BUILD during mk/package.sh and place it in the root, as I guess that's where people would need the BUILD file to be.
For GN, we could generate an BUILD.gn if an optional output path parameter to mk/package.sh is provided.