Hey everyone - In short, I have written a set of bindings for the library underlying the Tiny C Compiler and I want to know what package name I should use. I would prefer a top-level TCC package, in particular because I envision a large set of derived modules. Thoughts?
David *Motivation and features* The Tiny C Compiler is a C compiler that can compile code for ARM and x86 processors. It was written to compile code very, very quickly, and compiles code roughly 7x faster than gcc -O0, roughly 40x faster than gcc -O3. In exchange for quick compile times, you get machine code that isn't as highly optimized. But it's still machine code. One of the coolest features of TCC is that if provides libtcc, which can take a string of C code and compile it to machine code without writing anything to disk. That's right, it's a *true C jit compiler*, just waiting for some nice Perl goodness to wrap it up. I've written bindings that expose the compiler's basic capabilities, such as defining preprocessor symbols, linking to other libraries, adding symbols to the symbol table, compiling the code, and retrieving compiled symbols (i.e. functions). I've also created an extension framework for module authors to wrap all of this into reusable pieces. For example, I've already written extensions that (1) expose croak() to your compile context, (2) provide a simple but useful data structure called StretchyBuffer, and (3) allow you to write C functions that you can call directly from your Perl code. I hope to some day wrap various C libraries with similar extensions. For example, I would like to wrap GSL such that a programmer can pull the GSL headers and symbols into their compiler context with a single Perl command. *Similar Projects* The first module/namespace that comes to mind is Inline::C. Certainly, it would be possible to create an Inline::TCC. However, Inline operates under the assumption that compiling code is a relatively costly enterprise, whereas my approach to TCC assumes that it is relatively cheap. When you decide that compiling code is cheap, a whole set of possibilities open up that you don't have otherwise. The whole extension system is perfect for TCC, but would be particular to the TCC system, and would not apply generally to the Inline system. As such, I don't think it's a very good fit for the Inline family or namespace. A second module/namespace is evident when you realize that a very primitive set of TCC bindings already exist under C::TCC<https://metacpan.org/module/C::TCC>. Unfortunately, that project does not provide any extension mechanism, or even a way for the underlying main() function to communicate with Perl. Also, I have tried to contact the author with no success. -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." -- Brian Kernighan
