I started this topic to seek clarification of segaloco's thoughts about including executable build tools in a version control system.
What's the usual way for the person running the build command to provide to the build system the paths to each downloaded build tool, such as asm6.exe, the image converter, and various compression tools? I'm aware that conventions for what PATH ought to contain differ on Windows vs. GNU/Linux, yet even GNU/LInux distributions don't put $HOME/.local/bin in the PATH by default. I've also been told that it's poor form to put a project's build tools in the PATH.
Is it worth the effort to cater to users who seek to build historical commits of a repository (those prior to the newest tag), such as for git bisecting a program misbehavior? In my experience across the NES and Game Boy scenes, I've run into projects that can no longer be built with the current version of the assembler and other tools because such tools have since had breaking changes to their syntax, semantics, or both.
Once the developer has added a submodule, the README must then explain not only how to build it but also how to even clone it. Is there a typical method of making a tarball or zipfile source release of a repository incorporating a submodule? And to what extent can a submodule cross repository hosts, such as a submodule in GitHub in a project hosted on GitLab or someone's Gogs instance?You've included an asm6.exe file. I'd be careful with that, git is for source control. Providing a specific object file may imply that there are modifications to that program required to build your repository, in other words, that it wouldn't work with someone's installed asm6. Providing the .exe is a nice bone to throw to users of Microsoft Windows on x86-family CPUs at this point, but if there are such modifications, a lack of distributed source code prevents anyone running on another operating system from using this properly. If you don't have modifications, I'd just drop asm6.exe, that's a binary object for one specific operating system and hardware architecture. If you do have modifications, I'd drop asm6.exe, fork asm6 on Github with your changes, and then add it as a submodule to this repository. That way you don't have vendor/architecture lockin for users who want to work with this and it's all tied to upstream, making someone merging your stuff with later upstream changes more likely.
What's the usual way for a game project hosted on GitLab or GitHub to provide the location of each build tool's executable to the build system? At least on GitHub, all binary releases must be associated with tags, which makes it less convenient to obtain build tools needed to build a nightly build if they have changed since the last release. It's possible to build build tools through GitHub Actions CI, but as I understand it, Actions build artifacts are available only to members of GitHub.Either way, BLOBs of utilities in source control is a bit of an oxymoron, source control is for source code, if you have to include a modification to a utility involved, that too should be provided as source code so the consumer actually knows what is changed. Otherwise the user should be directed towards upstream, that way too any problems they have are also directed upstream (you're not giving them asm6, they don't expect you to fix it for 'em.)
What's the usual way for the person running the build command to provide to the build system the paths to each downloaded build tool, such as asm6.exe, the image converter, and various compression tools? I'm aware that conventions for what PATH ought to contain differ on Windows vs. GNU/Linux, yet even GNU/LInux distributions don't put $HOME/.local/bin in the PATH by default. I've also been told that it's poor form to put a project's build tools in the PATH.
Is it worth the effort to cater to users who seek to build historical commits of a repository (those prior to the newest tag), such as for git bisecting a program misbehavior? In my experience across the NES and Game Boy scenes, I've run into projects that can no longer be built with the current version of the assembler and other tools because such tools have since had breaking changes to their syntax, semantics, or both.
- I ported my projects from Python 2 to Python 3 in 2016. Most GNU/Linux distributions have removed Python 2 from their repositories since upstream end of support in January 2020.
- I can remember two breaking changes in ca65 around 2014 or so. One is that providing a value outside of the range of the unsigned type with the appropriate size, such as a negative value for an immediate operand or .byte value, became a "range error." The other is that paths in .include changed from being relative to the parent file to being relative to the current working directory. (Paths in .incbin did not change.)
- One of my repositories (240p Test Suite) contains both Game Boy and NES versions of a single program. RGBASM has had four major versions' worth of breaking changes since I started gbdev in earnest circa 2019. This is because the syntax and semantics of RGBASM were an archaic mess when the current maintainer inherited the project.
Statistics: Posted by tepples — Sat Jan 06, 2024 8:46 am — Replies 0 — Views 68