tinycc-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] Almost added a feature, but I broke things


From: Joshua Scholar
Subject: Re: [Tinycc-devel] Almost added a feature, but I broke things
Date: Thu, 24 Dec 2020 16:19:10 -0800

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]