undefined | Better HN

0 pointssnuxoll9y ago0 comments

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.

0 comments

2 comments · 1 top-level

geofft9y ago· 1 in thread

My 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/ and its link to 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.

snuxollOP9y ago

If 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.

j / k navigate · click thread line to collapse