>Is that so? I can kind of see where you are coming from, but this is
not the right way to solve it. It creates unnecessary dependency bloat,
and even a lot >more headache for anybody willing to take time and read
though that. If you want I can send you my custom amalgamated version of
TCC which is >literally 1 c file, does not depend on tcclib, because it
has it in it's source already, all the assembly routines for stuff like
alloca, are written in extended >asm syntax and they work. There is no
need to run make to compile, just gcc tinycc.c and some platform flags
is enough. You also don't need to worry >about header files, because you
can always make your own, just write extern printf(...) bla bla and it
will work. That's basically how I use tcc, it's so much >easier to work
with and maintain especially now that i have wrote a special version of
tcc which can correctly amalgamate any C source code just like >compiler
sees it, no assumptions because tcc implements complete preprocessor spec.
That sounds really cool Kyryl. I'd be interested to see it. Can you
please share your special version of tcc that's able to amalgamate any C
source code?
On 24/12/2020 15:38, Kyryl Melekhin wrote:
>I figured a lot of people would like, that >libtcc can hold a virtual
read-only file >system, so that you don't actually need to >have an
include, lib and libtcc directory for >a project to use libtcc.
Is that so? I can kind of see where you are coming from, but this is
not the right way to solve it. It creates unnecessary dependency
bloat, and even a lot more headache for anybody willing to take time
and read though that. If you want I can send you my custom amalgamated
version of TCC which is literally 1 c file, does not depend on tcclib,
because it has it in it's source already, all the assembly routines
for stuff like alloca, are written in extended asm syntax and they
work. There is no need to run make to compile, just gcc tinycc.c and
some platform flags is enough. You also don't need to worry about
header files, because you can always make your own, just write extern
printf(...) bla bla and it will work. That's basically how I use tcc,
it's so much easier to work with and maintain especially now that i
have wrote a special version of tcc which can correctly amalgamate any
C source code just like compiler sees it, no assumptions because tcc
implements complete preprocessor spec.
On Thu, Dec 24, 2020, 06:29 Joshua Scholar <[email protected]
<mailto:[email protected]>> wrote:
If anyone who knows this project better than me can help it would
be wonderful.
I decided to add a feature I figured a lot of people would like,
that libtcc can hold a virtual read-only file system, so that you
don't actually need to have an include, lib and libtcc directory
for a project to use libtcc.
Warning, I'm a windows user, so I'm probably doing this on a
different system than most of you.
Now that I think about it, my choice to do it by embedding a zip
file and linking miniunzip and libz in was probably a poor one for
efficiency. Those parts are working, so I'll leave it alone until
I get the bugs I caused out, unzipping, buffering the unzipped
data every time, allocating and deallocating the memory for those
buffers and putting a global lock on the miniunzip calls waste
time, and if people want to use libtcc as something like a jit,
they probably would prefer the speed to the memory.
Also, and even more convincing, embedding libz and the latest
version of minizip (which has forked off from libz) into the
project and making it work on every platform would be a nightmare.
But never mind that for now, my current state is:
tcc works for making .o files and .a files and the results are
byte equivalent the previous version - and it doesn't need the
directories to exist to do it.
But libtcc_test silently fails, and I can't get this version of
tcc to make exe files and -run doesn't work.
But since I didn't make a visual studio solution file, I'm just
working off the command line, I haven't been able to use a
debugger and I'm lost for why everything compiles without
complaint and runs without complaint, but not everything works.
To get help from the compiler I replaced the int type for posix
handles with a struct type for a wrapped handle that can read from
this virtual file system. Since the types can't be substituted
without error, I should have caught all the spots where I need to
change things.
Joshua Scholar
_______________________________________________
Tinycc-devel mailing list
[email protected] <mailto:[email protected]>
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
<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
