Path: ...!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Bart <bc@freeuk.com>
Newsgroups: comp.lang.c
Subject: Build Systems
Date: Sun, 13 Aug 2023 14:53:47 +0100
Organization: A noiseless patient Spider
Lines: 167
Message-ID: <uban99$1rnpb$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 13 Aug 2023 13:53:45 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="504c96876f9fd3dcf0f1cd3ca02e563f";
	logging-data="1957675"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX198HGxKiMF+Yk6ofX5ahJTksFrckoYmoJ0="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.14.0
Cancel-Lock: sha1:0i+5A8JgwH6UXHnSLdSl2fpjWr4=
Bytes: 7121

Bart:
 >> Suppose you dispensed with all that dependency stuff; how long would
 >> it take to build such a project? Say compared with just compiling one
 >> module.
 >>

David Brown:

 > That particular project takes a minute and a half to compile on my
 > laptop (it's faster on my main machine).  It's 373 compilations, perhaps
 > 40% of it C++.  Too long for convenience.

OK. I'm surprised (since you say you work on embedded systems) that 
software for those can be so elaborate.

I've worked with some restricted machines, and my program builds, which 
were also done ON those machines (no cross-compiler on a bigger 
machine!) has never taken anywhere near as long as that.

But I thought, should I give 'make' one more chance? I tried some 
smallish projects:

-----------------------------
Pico C interpreter: This has a makefile, but it was for Linux. A Windows 
build requires MSVC and VS (or whatever is needed to deal with .sln 
files), so no thanks.

Yet, I have built this project in the past without make or VS, once I'd 
extracted the necessary info.

-------------------------------------------------

Lua Interpreter: This had a makefile, but gave errors. A closer look 
revealed things like "-DLINUX...". I know this builds on Windows, but 
there was no info as to how that I could see.

----------------------
8cc C compiler: Linux only (although this wasn't mentioned; unistd.h in 
the sources gave a clue).

------------------------

SubC C Compiler: this uses a makefile file, but also has WINBUILD.BAT 
for Windows. I guess make was not quite flexible enough for Windows, or 
had too many Linux dependencies.

But WINBUILD didn't quite work. Maybe it was to do with some errors 
unpacking 2-3 .tgz/.tar files: 'Cannot create symbolic link: a required 
privilege...'.

--------------

So, maybe 'make' can work under Windows, if only I can find a suitable 
project where that actually happens!

What I did find was build systems that are chaotic; the above are 
typical unfortunately.

'make' is only part of the problem. Yet these projects are quite 
small-scale, with dozens of source files, compared with gcc 13.2 which 
had 75,000 source files, and that was described by two people here as 
being simple to build.

DB:
 > Computers are good at tedious work.  They are good at tracking this kind
 > of small detail.  Why not let the computer do the work here?

Exactly. But I'm not seeing that in these projects. Somebody has to go 
to a lot of trouble to create those build scripts, or get additional 
sofware's help to create them. Which in the end did not result in my 
being able to do an effortless, trouble-free build.

 >All it takes is a little googling and a willingness to learn - 
makefiles have a somewhat cryptic syntax,

And here you confirm what I said!

 >Longer does not mean better.  Often it means set in your ways, and 
unwilling to look at alternatives.

On the contrary. Alternatives are EXACTLY what I have always worked on, 
especially over the last decade.

Maybe it's /you/ who's unwilling to looked at alternatives, but are too 
locked in to existing languages, compilers, OSes and support tools. Such 
a critical mass has been created that there is no easy way out; just 
piling on more stuff, finding creative ways to make things faster.

My C compiler project is roughly on the same scale as the above 
examples. Somebody sitting at my desk right now wanting to build my C 
compiler would type this from inside the project folder:

    C:\cx>mm cc

The project is 71 source and support files, spread this plus two further 
nested folders (these contain my compiler's standard headers and 
reflects their structure).

The folders contain other stuff not necessary for the build; it doesn't 
matter. /Some/ might be junk, a lot is needed for development.

If you wanted to build this product, I could supply a ZIP with a clean 
set of files. It would also contain mm.exe, the compiler needed. (Oh 
yes, my C compiler is not written in C.)

However, what I would probably do instead is this:

    C:\cx>mm -ma cc

This creates an amalgamated file cc.ma. Now I just email you mm.exe and 
cc.ma, and you just type:

    Anywhere> mm cc.ma                # .ma is optional if no clashes

Maybe you'd rather compile C source code instead? OK, I would then do:

    C:\cx>mc -c cc                    # Transpile to single C file

And email you just the cc.c file. You can build it on Windows like this 
(add your own options to taste):

    Anywhere> gcc cc.c                # (tcc needs extra options)

This builds a self-contained C compiler called a.exe. Does it work? I'll 
try it:

   C:\cx>a cc
   Compiling cc.c to cc.exe

But, maybe you want to use Linux? OK, let's see what I can do. I can try 
this instead:

    C:\cx>mc -c -linux cc m           # C file Linux-specific portions

Then, on Linux, you'd need to build it like this demo on WSL:

    root@DESKTOP:/mnt/c/cx# gcc cc.c -lm -ldl -fno-builtin -obcc

However, there are limitations, since my C compilers target Win64 ABI, 
not Linux. You can do this:

    root@DESKTOP:/mnt/c/cx# ./bcc -c sql
    Compiling sql.c to sql.obj

    root@DESKTOP:/mnt/c/cx# ./bcc -S sql
    Compiling sql.c to sql.asm

But you can't create sql.exe (that needs to access msvcrt.dll). And even 
those .obj/.asm files contain Windows-specific native code.

-------------------------------

So, what do think of my alternatives? No build system in sight, whether 
makefiles, SLN files or batch files.

In each case there was a simple one-line command involving one compiler 
and one named source file, even if that line got longer the further we 
got from my language, and from Windows.

For an actual multi-file, original C project, I've demonstrated 
elsewhere the -auto option of my C compiler. But for use with existing 
compilers for other people to use from the command line I would provide 
@ or .bat files.

Of course, most of my actual development, not command line work, is from 
from my mini-IDE, currently a 75KB program. I can use that for C too but 
only bcc is supported.