Many people complain about many build (and packaging) systems. This repo tries to collect the annoyances in a similar fashion to awesome lists.
To contribute, send pull requests. The Licence for this repo is CC0.
- Looks like Make with XML syntax
- Can not have external dependencies
- Can not have external dependencies
- Assumes build machine is networked; no obvious way to pre-download dependencies and have them be used
- Custom language
- Lacking documentation
- "so huge and bloated, compilation takes longer than compiling GCC (!). It’s not even possible to create freestanding Makefiles, since the generated Makefiles call back into the cmake binary itself." source
- Changes to
build.gradle
do not implicitly trigger rebuilds - If you do not know Groovy the syntax can be confusing
- JSON syntax with condition code as strings
- Recursive Make Considered Harmful
- Changes to the Makefile do not implicitly trigger rebuilds
- Dependencies on directories is not really possible
- Lots of output by default
- Rules with multiple output files are not really possible
- can't handle spaces in pathnames
- Uses a POSIX/bash shell, which hurts portability
- Obscure m4 macro language
- Posix-only
- Hard to debug because of generated code
- Configure does many unnecessary checks
- Restricting build lifecycle concept
- Throws Null Pointer Exceptions and gives a stack trace for simple errors such as missing parameters
- Verbose logs
- Uses XML (possibly annoying), does not support XML attributes (annoying)
- Very low-level
- All goals are treated as files (no equivalent to Make's PHONY)
npm install
can be dangerous- Replicates transitive dependencies
- No way to specify test-only, build-only, debug-only, or CI-only dependencies (source)
- Native add-ons make artifacts non-portable
- Can not have external dependencies
- No Windows support
- The
requirements.txt
can either contain the (small) set of direct dependencies or the set of all (transitive) requirements for better repeatability.
- build rules spread across many files
- Very slow
- Builds a directory tree on startup. If SBT is started in the
/
directory it runs out of memory - Uses a hard to understand multilayered mutable execution model "The problems I discussed in this post are deep. These aren't things you can 'just send a PR' or 'just help them fix it'. They are fundamental to what SBT is."
- Too slow for larger projects (source)
- VariantDir is confusing
- Requires Haskell (GHC)
- Hard to port
- Hard to parallelize (thus slow)
- Can not have external dependencies
Yocto builds Linux distributions by invoking other build systems. It has many unique features:
- To use it, you must source a shellscript, breaking Fish compatibility.
- Officially supported distros are whitelisted: Its fakeroot implementation routinely breaks because Glibc is too new. Therefore, it must often be used in Docker or other containerization on unsupported distributions.
- Compiling the wrong code: There is a setting of whether to compile the local or remote copy of each repository, but changing the setting is not in all cases respected before a clean build is made.
- Flimsy developer essentials that regularly stop working: Yocto has a concept of a devshell: This opens a terminal (of all things) with the build environment set up in the build directory of a particular repository (for building only that one). Getting this working through Docker or other containerization really depends (if you're not careful, it may attempt to start X in your container, which will hang your existing X). As if its interactions with your Linux desktop isn't surprising enough as it is: You may be working in Konsole in an X session … but the devshell window that pops up is a Gnome-terminal in Weston in a different VT.
- If you try to work outside devshell: Pulling dependencies while building is a sure way to distract your edit-compile-debug cycle with unrelated breakages from elsewhere, as well as the occasional big change that takes ages to rebuild.
- Bitbake recipes:
- Look like shellscripts with improper quoting. Disgust.
- Have their own variables that look like shell variables. Confusing & error prone.
- Use magically named flat variables instead of structured data. Requires disciplined adherence to documented best practices.