|
| From: | Joshua Scholar |
| Subject: | Re: [Tinycc-devel] Almost added a feature, but I broke things |
| Date: | Thu, 24 Dec 2020 18:13:44 -0800 |
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 <joshuascholar@gmail.com> 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 <k.melekhin@gmail.com> 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
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
| [Prev in Thread] | Current Thread | [Next in Thread] |