←back to thread

“You should never build a CMS”

(www.sanity.io)
140 points handfuloflight | 4 comments | 14 Dec 25 05:38 UTC | HN request time: 0.073s | source
Show context
larusso ◴[14 Dec 25 08:19 UTC] No.46261608[source]▶
This story reminds me of a similar issue people love to solve with the same idea. Software builds. The can’t we have a simple make file or worse just a shell script to build.

And just like described in the post it starts the same. Simple script wrapper. No tasks no tasks dependencies. Then over time you need to built now a library which contains the core part of the software to share between different other projects. You need to publish to different platforms. Shell scripts become harder to use on windows all of a sudden. You need to built for different architectures and have to integrate platform specific libraries. You can built your simple make / shell file around all that. But it ain’t so simple anymore.

replies(1): >>46261715 #
1. kstenerud ◴[14 Dec 25 08:49 UTC] No.46261715[source]▶
The idea is to have an 80/20 build system:

For the 80% of use cases, you have homogeneous build commands that are the same across projects (such as a makefile with build, clean, test, etc). This calls the real (complex) build system underneath to actually perform the action. You shouldn't need to type more than 15 keys to make it do common things (and you CERTAINLY shouldn't need to use ANY command line switches).

Then for the other 20% of (complex) use cases, you call the underlying build system directly, and have a document describing how the build system works and how to set up the dev environment (preferably with "make dev-env"). Maybe for self-bootstrapping systems like rust or go this isn't such a big deal, but for C/C++ or Python or node or Java or Mono it quickly becomes too bespoke and fiddly.

Then you include tests for those makefile level commands to make sure they actually work.

There's nothing worse than having to figure out (or remember) the magical incantation necessary to build/run some project among the 500 repos in 15 languages at a company, waiting for the repo owner to get back to you on why "./gradlew compileAndRun" and "/.gradlew buildAndRun" and "./gradlew devbuild" don't work - only to have them say "Oh, you just use ./gradlew -Pjava.version=11 -Dconfig.file=config/dev-use-this-one-instead.conf -Dskipdeploy buildAndDeploy - oh and make sure ImageMagick and Pandoc are installed. They're only used by the reports generator, but buildAndDeploy will error out without them". Wastes a ton of time.

replies(2): >>46261745 #>>46263934 #
2. 01HNNWZ0MV43FF ◴[14 Dec 25 08:56 UTC] No.46261745[source]▶
Having Make shell out to the real build system is a nice compromise. Then you can stick your tests and stuff in there too
3. larusso ◴[14 Dec 25 15:53 UTC] No.46263934[source]▶
Yes. In the example of gradle I setup all specifics to the well know lifecycle tasks: check, assemble and in some cases publish. Some projects are more complicated specifically when you can really use the rule of: 1 project one assembly. See android with apk vs bundle. Here you may need more specific tasks. But I try to bind CI (be it Jenkins or GitHub actions) to only know the basic interface. But I meant specifically the believe that build systems and tooling around is too complicated and unnecessary.
replies(1): >>46264351 #
4. kstenerud ◴[14 Dec 25 16:42 UTC] No.46264351[source]▶
Ah yes. Unfortunately the complexity is necessary in modern codebases. There are usually ways to simplify, but only to a point - after that all you're doing is smearing the complexity around rather than containing it.