Path: ...!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Bart 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: 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.