Path: csiph.com!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: Experimental C Build System Date: Sat, 03 Feb 2024 07:17:17 -0800 Organization: A noiseless patient Spider Lines: 34 Message-ID: <86plxd8tmq.fsf@linuxsc.com> References: <86eddyba7z.fsf@linuxsc.com> <86ttmp9aus.fsf@linuxsc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: dont-email.me; posting-host="86b83c500004563f07cda2ade1e7584b"; logging-data="3340502"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19bWdOGxUHfrGk6uAy3SExiyt5bzqfo/gw=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:PTKhrzmpRpYyixv8EYlCT5PoDyI= sha1:li51cPuSNrx/2dmulsCj8gIyCug= Xref: csiph.com comp.lang.c:381680 bart writes: > On 03/02/2024 09:05, Tim Rentsch wrote: > >> bart writes: >> >>>> 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. >>> >>> So, will a specific build of such a project produce a single >>> EXE/DLL//SO file? (The // includes the typical file extension of >>> Linux executables.) >> >> No, there are several outputs of this kind, including object >> files, static libraries, and dynamic libraries, and all for a C >> environment. (There are also other outputs but of a different >> kind than what you are asking about.) >> >> I have no expectation that you will incorporate these ideas or >> capabilities into a tool you are building for yourself. I gave >> the list in case other readers might have an interest. > > OK. You seem fairly level-headed and calm, so I'll try this > explanation. [...] You have no interest in what's important to me in a build system. I have no interest in what's important to you in a build system. And in any case the recent discussion of build systems has gone beyond the bounds of comp.lang.c and should be conducted in some other newsgroup, or perhaps some other venue.