How about Devel::TCC for the bindings/interface/control part and Alien::TCC (of course) for the detection and installation?
--Chris On Thu, Aug 15, 2013 at 8:57 AM, David Mertens <dcmertens.p...@gmail.com> wrote: > 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. 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
