On Fri, Dec 4, 2009 at 1:07 PM, grischka
<address@hidden> wrote:
k1w1 wrote:
Hi,
I want to use tcc in a cross-platform project which primarily targets Windows. I have used tcc successfully a couple of years ago so I have some familiarity with the code. I find the code very difficult to work with because of the technique of including .c files. This prevents my IDE and debugger from working properly. Even with the IDE aside, it is pretty difficult to navigate the code when so much of it is in one file.
I would like to split the code into multiple files, and separate as much as possible the OS specific code so that improving the Windows support doesn't increase the spaghetti of #ifdefs. I am using the library API to tcc and it needs some improvement too so that all of the compiler options can be set through the API and so that multiple TCCState objects can exist at once.
* Original tcc.c of 11000 lines is split into:
tcc.h libtcc.c tccpp.c tccgen.c tcc.c
* Some changes allowing multiple TCCStates, although not for compilation
at the same time.
I would like to be able to maintain multiple sets of debug information in RAM for multiple separate programs, so it seems like I need to move the stabs sections into the TCCState structure to support this. I haven't started with this yet so I might be wrong.
Anyway, the bottom line is, if I do this, what are my chances of getting the changes accepted into the mainline? Does anyone else have any input on how they would like to see the code structured?
I don't know whether it makes sense to split the files once more, but
it would make sense to make them more self-contained, such as getting
rid of the all-in-one-included approach and allow separate compilation
into distinct objects, such as libtcc.o, tccpp.o, tccelf.o, tccasm.o ...
That would also help to make the thing more modular such that we can
for example plug in some other code generator, eventually.
In any case I think before we want your changes for the mainline
we'd like to know a little bit more what these changes are. ;)
On the other hand, if your plan sounds good, you could just as
well work on the mainline itself.
I am going to just dive in and make my changes. If they work out well then we can merge them in. I am going to work on a separate fork in the git repository. I am a git novice so I don't think I am ready to start messing with the mainline yet.
My main objective is not to have any #includes for .c files, and to have a .h file corresponding to each .c file. One implication of this will be that the makefile will need to be a bit more complex because the conditional including of code (like the -asm.c file to use) will need to be determined at build time. Though it looks like the makefile is already doing some conditional compilation so I don't think it will take much more.
Regards, K1w1.