Heh, people told me I was crazy to make my chess engine a single file. On Thu, Dec 24, 2020 at 5:00 PM Kyryl Melekhin <[email protected]> wrote:
> This isn't a build system you are misunderstanding a lot of things, it's a > special tool that can save you a lot of time if you ever need to correctly > combine C source or libraries into one file. The best build system is > having no build system at all. Also files are annoying to a lot of people > and hurt your understanding of the code as a whole. Thats why single header > libraries are so popular. Sometimes the best way to read the source code of > some C project is to combine everything into one file and explore the code > in its entirety without wasting your time memorizing where every function > is located, what file and subfolders. Sometimes to gain complete > understanding of complex system it's better to strip it down to the > "suckless" level. Also if your editor can't handle large files, it's better > to reconsider your tools or write your own that suck less. There is always > some kind of missing data and indirection between the original software > authors and you, what made sense to them when building a project will not > be something you will be able to understand on your own. Most of the time > developers split code into files for no reason whatsoever and cryptic names > dont help. I don't recall ever having filename help me in understanding the > code of example. It's just for esthetic organizational purposes only, but > they are useless when it comes to being productive. Also dont even tell me > about multicore builds, those are sucky too, most of the time you will be > hit by O(n) slow linker, which makes whole thing even slower in some cases. > That's why I use Tcc, compiler should be fast enough to handle massive > codebases without a chug. If tcc compiles 200K loc of code in less than a > second, I don't think any reasonable user land applications should have any > justifications for using build systems because such a compiler exists. > > Anyway, I was actually replying to the person who asked me about the > amalgamation, but I figured might as well tell you bit about my philosophy > that I've come to form over the years. > > On Thu, Dec 24, 2020, 19:19 Joshua Scholar <[email protected]> > wrote: > >> I guess I misunderstood, I thought that your file was all of the header >> files and the runtime placed into one source file so that you could have >> tcc or libtcc be part of a project and make the product/or tcc be a single >> executable that doesn't need directories. >> ie. without needing link files for the run time and without needing a >> directory tree of include files, (or the same for a program using libtcc >> internally). >> >> But this is just another way of BUILDING tcc. >> >> I wanted a project that USES libtcc without needing a directory of >> standard includes and without needing lib files - ie a single file >> product. I wanted to USE libtcc, I didn't want a project that that BUILDS >> tcc. >> >> And since your file starts with a number of standard includes, your file >> doesn't even stop people from needing all of directories of includes, it >> just saves them from needing make? Or this is so that people can use the >> equivalent of libtcc without knowing how to link a library into their own >> program? >> >> So this isn't for making products that use lib tcc, it's for developers >> who hate make and for some strange reason don't want to link? >> >> I don't get it, what sort of meta-product needs to compile tcc over and >> over? >> >> Is this just to save time on running make on your personal project that >> changes tcc? And the cost of that is that tcc is one huge file? That >> still doesn't tell me why you smashed tcc's headers into it since you need >> to include tcc compatible versions of the header files anyway. You don't >> want people to need make, but they'll still need gnu C for the headers? >> >> >> >> Anyway I GOT MY ADDON WORKING, there were just a bunch of typos. >> >> But I'm gonna rewrite it. Instead of making the embedded directory a zip >> file and adding a bunch of libraries to handle zip files, I'm gonna make it >> a tar file (uncompressed), write a program that converts a tar file into a >> .c file (so my program won't need an external tar file) and just write c >> code that can make an index into a tar file in memory. >> >> And I'll keep my change to libtcc so that it searches my virtual file >> first. >> >> That will mean that the feature needs minimal changes to the project and >> it will make a compiler that's much faster than a version that reads from a >> compressed archive. >> >> Just add a flag to the make (I have it as -s on the windows bat file >> make) and it will build versions of tcc and libtcc that don't need >> directories of include and libraries. >> There are some things that won't work. You can't load a dynamic link >> library out of an archive. >> >> But my idea of using libtcc as a jit needs work on exporting the run >> time, I think. Though I noticed libtcc reading a file called "msvcrt.def", >> so maybe it's doing something clever and reusing the runtime library of >> embedded program? >> >> On Thu, Dec 24, 2020 at 3:22 PM Kyryl Melekhin <[email protected]> >> wrote: >> >>> https://raw.githubusercontent.com/kyx0r/klec/master/utils/tinycc.c >>> >>> on x86_64 linux compile like so gcc tinycc.c -ldl -lpthread >>> then you can use it like so: >>> >>> if the project already has something resembling a unity build: >>> a.out -E file1.c > file2.c >>> >>> if the project does incremental build: >>> use cat on every C file in correct order ignore the headers. >>> cat *.c > file1.c >>> a.out -E file1.c > file2.c >>> >>> >>> To better understand how it works I recommend to try it on tcc >>> code base first. Tcc code actually is layed out in an easy format >>> despite make forcing the incremental build. >>> a.out -E tcc.c > tinycc.c >>> This current version the result should amount to approx 87K loc >>> >>> Some comments: >>> 1. If the headers in C source are not guarded properly >>> it will not work, but so will your project not compile also. So >>> this does not happen. Header exclusion works the same way a compiler >>> would exclude it. >>> 2. Problem of amalgamation is not as trivial as you think it might be, >>> because of the nature of how C works your header might be guarded but >>> you can also have code outside of that guard, in any case my program will >>> exclude the code properly. Especially that #endif is used to terminate >>> any kind >>> of preprocessing expression. >>> 3. By default headers with <> (system headers) are not amalgamated. >>> You can enable that, just read the source code in tcc_preprocess. >>> This program is powered by strategically placing printfs inside tcc >>> and some compiler logic changes of the default option -E, so don't try >>> to use this tcc for anything except what is meant to be. >>> 4. While in most cases the resulting file will compile, some projects >>> might be >>> weird and still require some manual tweaks and edits. Also you might need >>> to spend some time to clean the code from extra newlines that might get >>> created. >>> 5. You can also configure it in source code to instead of processing >>> everything >>> actually do the preprocess and exclude all the unnecessary junk, so for >>> example >>> with that tcc source for x64 linux will be about ~35K instead of 87K. >>> >>> _______________________________________________ >>> Tinycc-devel mailing list >>> [email protected] >>> https://lists.nongnu.org/mailman/listinfo/tinycc-devel >>> >> _______________________________________________ >> Tinycc-devel mailing list >> [email protected] >> https://lists.nongnu.org/mailman/listinfo/tinycc-devel >> > _______________________________________________ > Tinycc-devel mailing list > [email protected] > https://lists.nongnu.org/mailman/listinfo/tinycc-devel >
_______________________________________________ Tinycc-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/tinycc-devel
