On Fri, Dec 4, 2009 at 1:07 PM, grischka <[email protected]> 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. >> > > Well, since several years ago we had some restructuring actually: > * 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.
_______________________________________________ Tinycc-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/tinycc-devel
