[HN Gopher] Small Project Build Systems (2021)
___________________________________________________________________
Small Project Build Systems (2021)
Author : akkartik
Score : 28 points
Date : 2023-04-01 17:43 UTC (2 days ago)
(HTM) web link (neilmitchell.blogspot.com)
(TXT) w3m dump (neilmitchell.blogspot.com)
| substation13 wrote:
| Good post. I am still hopeful that a large scale "backwards"
| build-system can be made ergonomic enough to be used on even
| small projects.
|
| If Bazel didn't have so many gotchas, it could be the one:
| cc_library( hdrs = [ "app.h" ], srcs = [
| "app.cc" ], )
| WickedSmoke wrote:
| Yes, that declarative style makes more sense to me than a
| forwards build statement of steps.
|
| I developed my own tool for building C/C++ projects which
| follows this style. It automatically handles things like Qt moc
| and scans the source files for headers, so in your example even
| the hdrs line can be omitted.
| wocram wrote:
| The problem with bazel here is that every project, no matter
| how small, ends up needing some beefy WORKSPACE and bazelrc,
| especially when you start bringing in this party dependencies.
|
| How do we streamline this? bzlmod and bcr are steps in this
| direction, but it still seems far away to me.
| Teknoman117 wrote:
| I've honestly become so used to CMake at this point I just use it
| for everything C/C++ related.
|
| I do still use Makefiles directly when there isn't an environment
| to search for - namely AVR projects where there are no libs to
| find.
| properparity wrote:
| My findings as a spartan C programmer:
|
| I've been using a simple unity-build ad-hoc build.bat/build.sh
| "system" for years now, works wonders.
|
| YAGNI will serve you well, 99.99999(repeating)% of everyone's
| code will only be built and run on 1, maybe 2 platforms, why
| bother with these insane monstrosities that we call 'build
| systems"?
|
| The few times I've needed to build for a new platform I just
| wrote that build script then and there, took a few minutes and
| that was it.
|
| Modern machines can churn through a tens if not hundreds of K
| lines of C code in less than a second, so incremental builds
| aren't needed either (and if anything, with too many translation
| units you end up with linking being a bottleneck).
|
| Single TU benefits:
|
| - Global optimizations "for free".
|
| - Make all functions static (except main) and you get --gc-
| sections "for free".
|
| - Linking is blazingly fast.
|
| - Don't have to bother with header files.
|
| - No one has to download anything to built my code, I make it
| work on a default msvc/gcc/clang install (i.e if you have gcc, cl
| or clang in your path when running build.bat/build.sh, it will
| build).
| cout wrote:
| I'm a fan of using two translation units:
|
| * one TU with code that is fast to compile and modified often
|
| * another TU with code that is slow to compile but modified
| rarely
|
| I still use header files, but the fast-to-compile and modified-
| often code goes directly into headers, so I can still organize
| my code into separate files.
| waynesonfire wrote:
| after all these years in the industry, chatgpt has enabled me to
| be productive in gnu make. both are such wonderful tools.
|
| really like gnu make now. i know it can solve the problems i
| have, and chatgpt helped me get there. when dependencies are
| setup properly, it's quite amazing to see it work.
| john-tells-all wrote:
| I'm a big fan of the "backwards" build system Make. It's very
| concise, portable enough, and not language-specific. I use it on
| literally 100% of my projects to hold small scripts. Example:
| "setup Python virtualenv" or "do a fast feedback loop with Lint"
| or "do a slower high quality feedback loop with Pylint and the
| full test suite".
|
| I'm thrilled people are developing other options, building a
| project "forwards".
|
| FYI "strace" on Linux makes it doable to trace build
| dependencies. Alas it doesn't work on macOS, and I haven't found
| an easy equivalent.
| nrclark wrote:
| I use Make the exact same way. Basically, it's a very concise
| way to express "here are some tasks with dependencies on each
| other. Abort if any of them fail" and sometimes "some of these
| tasks can be skipped if the inputs haven't changed". You also
| get free tab-completion on 99% of desktop Linux systems.
|
| If I'm working on a complex software project, I'll probably use
| an appropriate build system. Maybe Bazel, CMake, sometimes even
| Autotools.
|
| But I'll probably also keep a Makefile somewhere, and use it to
| automate the process of running that shiny build system.
| cout wrote:
| I agree. While I like the idea of tup (https://gittup.org/tup/
| -- the first "forward" build system I remember hearing of),
| writing a makefile is easy enough that thinking about the
| problem upside-down doesn't offer a compelling reason to
| switch.
|
| Ptrace is one option for tracing dependencies, but it comes
| with a performance hit. A low-level alternative would be ftrace
| (https://lwn.net/Articles/608497/) or dtrace
| (https://en.wikipedia.org/wiki/DTrace).
|
| Tup uses LD_PRELOAD to intercept calls to C file i/o functions.
| On OSX it looks DYLD_INSERT_LIBRARIES would be the equivalent.
___________________________________________________________________
(page generated 2023-04-03 23:02 UTC)