>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]> 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] > https://lists.nongnu.org/mailman/listinfo/tinycc-devel >
_______________________________________________ Tinycc-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/tinycc-devel
