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
Codegen requires contributors to install an additional dependency (Perl). For people who are not doing direct structures work (which is far less frequent now that we get bay12 headers), this is just extra steps and extra trouble.
Moreover, codegen takes significant time to complete in Windows CI builds (where file access is much slower due to multiple layers of emulation).
These two benefits could reasonably justify checking generated code into source control (which is a perennially hotly debated topic), as long as it doesn't unduly impact developer velocity.
We might be able to push the header generation process to an independent build step. One that can be executed outside of the context of the main dfhack build. However, we should still keep the option to generate code as part of the build to facilitate actual xml development.
One idea is to put codegen behind a CMake option (BUILD_CODEGEN) and run that as part of CI in the main repo whenever the structures ref is updated. Generated header files would be checked directly into the main repo (that is, the .gitignore file in library/include/df would be removed). Developers who are editing the xml files would keep exactly the same flow as before for local builds, and could choose to do a PR to update the generated header files or just submit the xml changes and let CI handle the header updates automatically.
Manual process:
edit xml files in df-structures
do a build (with BUILD_CODEGEN=1)
merge xml files in df-structures
in same commit, update the xml ref and commit the updated header files in the main repo
merge main repo changes
Automated process:
edit xml files in df-structures
merge xml files to df-structures
CI automatically updates xml ref, runs build with BUILD_CODEGEN=1, and autoupdates the headers in the main repo (all this is done in the same workflow to ensure atomic updates)
Then, non-structures developers and all other CI builds (test, package, github-release, steam-release, etc.) can build with BUILD_CODEGEN=0.
The text was updated successfully, but these errors were encountered:
myk002
changed the title
move codegen step out of the DFHack build
Make codegen step optional for the DFHack build
Dec 25, 2024
Codegen requires contributors to install an additional dependency (Perl). For people who are not doing direct structures work (which is far less frequent now that we get bay12 headers), this is just extra steps and extra trouble.
Moreover, codegen takes significant time to complete in Windows CI builds (where file access is much slower due to multiple layers of emulation).
These two benefits could reasonably justify checking generated code into source control (which is a perennially hotly debated topic), as long as it doesn't unduly impact developer velocity.
We might be able to push the header generation process to an independent build step. One that can be executed outside of the context of the main dfhack build. However, we should still keep the option to generate code as part of the build to facilitate actual xml development.
One idea is to put codegen behind a CMake option (
BUILD_CODEGEN
) and run that as part of CI in the main repo whenever the structures ref is updated. Generated header files would be checked directly into the main repo (that is, the.gitignore
file inlibrary/include/df
would be removed). Developers who are editing the xml files would keep exactly the same flow as before for local builds, and could choose to do a PR to update the generated header files or just submit the xml changes and let CI handle the header updates automatically.Manual process:
BUILD_CODEGEN=1
)Automated process:
BUILD_CODEGEN=1
, and autoupdates the headers in the main repo (all this is done in the same workflow to ensure atomic updates)Then, non-structures developers and all other CI builds (test, package, github-release, steam-release, etc.) can build with
BUILD_CODEGEN=0
.The text was updated successfully, but these errors were encountered: