The requirement is to ship the source in the preferred form for making modifications. That doesn't include standardized external tools, but it surely includes the build instructions (with things like which versions of the tools to use) and test suite (and indeed git history - mjg59 has disagreed with me regarding that before, but I don't think he gave a rationale) - those are things you'd definitely want to have for making modifications.
Not having to add autotools to a BuildRequires is nice, but hardly the end of the world as a package maintainer. I agree though, the contents of the repository at a git tag is not necessarily a source DISTRIBUTION - which is what most people who are compiling your software would want - especially when many of them probably don't know the autotools incantations required to generate the configure script.
Oh hey, it's an actually good example of using an external buildroot tree. Often vendors will ship the whole of buildroot from about 4 years ago with their patches on top (of course, with no source control so you have to diff it yourself to extract their changes)
Presumably some kind of Makefile or similar build automation config file would be in the repo to define which versions of which tools to use to do the build.
Yup, the versions of the toolchain components required for a project to build should be specifiable at the project in an format actionable by the main build tool. Running a project should never require more than "git clone $project && $build-cmd".
It should never be Nix's business (or any other OS) to provide elements of a project's toolchain. Reciprocally, projects should go out of their way to not depend on OS installed toolchain components.
We have all deps in gits. A build tool takes care of everything. I get all necessary source gits checked out, configured (e.g. change prefix) and built. If I change something (which is my job), rebuilding is just a 'make' away; and rebuilds only the changed parts. Pretty frictionless and painless.
We use some external stuff like sqlite, qt,... but that's all versioned in our gits as well (-> easily reproducible builds). Since we sell a commercial product we can't just add random deps anyway. Plus, I think there is very little code that would benefit from being replaced by an external libs.
Relevant tools are on a global package list. We can get stuff added there on a short notice, and with little questions asked. Eg when I needed some lib for a FPGA dev kit that was a matter of minutes.
Uaaah, Firefox on Android is messing up the input again (can only append, not edit). I guess I should just hit that "reply" button then).
Maybe you don't want / you do not have the chance to have sources and build tools installed on your production server and you trust mtier to build the patched sources for you.
I find it very useful.
The biggest reason is in case the original source goes away (the author removes a particular version for example). A lesser reason is to make it easier for others to get up and running without needing the build tools.
I tend to leave them out if it's a personal, open-source project. For a commercial project I tend to check them in.
At a past job the team had a custom CLI tool to manage all sorts of dev tooling. Worked great, highly recommended.
The distribution mechanism was to build from source[]. Once compiled, all other dev tasks were handled by the tool.
If you compile it yourself you don't run into any of these issues. This approach is only viable for developer tools of course, but that's what the post is about.
[]: This was a Go project, so building from source was relatively straight forward.
You do have to build it from source, but the documentation for how to do so is luckily quite good, and there's a dedicated channel in the Discord server for helping people with build issues if you run into any problems.
You're obviously not obligated, but I'd encourage you to try building it if you're interested!
Yeah but those steps should be part of the normal build process. If you have to use weird tools (e.g. autotools) to generate your "real" source code, I'd say the problem is those tools. Also. Seriously. Autotools? In 2016?
reply