3 ms·
Nobody said it had to be good build tooling, just functional. You use a 1000 line shell script to do a bunch of shit, that's fine, there's no requirement in th
by snuxoll 10y ago
Nobody said it had to be good build tooling, just functional.
You use a 1000 line shell script to do a bunch of shit, that's fine, there's no requirement in the GPL that it has to be "./configure && make && make install" - just that you provide the accompanying scripts used to build the software.
This shouldn't be hard, you shouldn't make it hard on yourself or developers working on your project to create a local build. I honestly don't even see the issue.
- geofft 10y agoMy employer uses a single, giant script to build everything, including third-party software. My impression is that this is pretty common for large companies; see http://danluu.com/monorepo/ http://danluu.com/monorepo/ and its link to https://news.ycombinator.com/item?id=10604168 https://news.ycombinator.com/item?id=10604168 Releasing this script would involve releasing a ton of metadata about everything anyone at the company works on. I have my differences of opinions with our build infrastructure rather frequently, as it happens, but I think it makes it easier to create a local build; you don't have to learn n different build systems for n different upstream projects. But it's a local build designed for developers who are my co-workers, not for the general public.
- snuxoll 10y agoIf you want one script that can build a whole stack then fine, but that doesn't mean you can't keep the tooling separate enough to build each component individually. You use RethinkDB with a bunch of patches? Keep that part in it's own script that gets called by your big one, problem solved. Again, this isn't hard.