Path: csiph.com!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.lang.c
Subject: Re: Experimental C Build System
Date: Tue, 30 Jan 2024 16:46:56 -0800
Organization: A noiseless patient Spider
Lines: 52
Message-ID: <86eddyba7z.fsf@linuxsc.com>
References: <up8i91$h6iu$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: dont-email.me; posting-host="fb4244b8d2c04d3d864a981f3fa61ba0"; logging-data="1286976"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/DdYn5Ra2wKUkmqwOAtyem4qgwUSfxkJQ="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:PdIqw6AmxuliZDsCFLqdmEIAIfE= sha1:ZnUCgKb5C2Ko3alCv2z+ewWgr/A=
Xref: csiph.com comp.lang.c:381297

bart <bc@freeuk.com> writes:

> [description of a rudimentary C build system]

What was described is what I might call the easiest and
least important part of a build system.

Looking over one of my current projects (modest in size,
a few thousand lines of C source, plus some auxiliary
files adding perhaps another thousand or two), here are
some characteristics essential for my workflow (given
in no particular order):

  * have multiple outputs (some outputs the result of
    C compiles, others the result of other tools)

  * use different flag settings for different translation
    units

  * be able to express dependency information

  * produece generated source files, sometimes based
    on other source files

  * be able to invoke arbitrary commands, including
    user-written scripts or other programs

  * build or rebuild some outputs only when necessary

  * condition some processing steps on successful
    completion of other processing steps

  * deliver partially built as well as fully built
    program units

  * automate regression testing and project archival
    (in both cases depending on completion status)

  * produce sets of review locations for things like
    program errors or TBD items

  * express different ways of combining compiler
    outputs (such as .o files) depending on what
    is being combined and what output is being
    produced (sometimes a particular set of inputs
    will be combined in several different ways to
    produce several different outputs)

Indeed it is the case that producing a complete program is one
part of my overall build process.  But it is only one step out
of many, and it is easy to express without needing any special
considerations from the build system.