MELT, a GCC Compiler Plugin Framework, Reaches 1.0
karijes writes with news that the Middle End Lisp Translator extension for GCC has hit 1.0: "MELT is a high-level domain specific language for extending, customizing and exploring the GNU Compiler Collection. It targets advanced GCC users, giving them ability to hook on almost any GCC stage during compilation or interpretation phases. This release brings a lot of new things."
New features include defmacro and changes to the antiquote operator.
In other News, MetaMELT's v0.3 was released this last weekend.
"MetaMELT a meta-level tool for the customization of MELT's dynamic pattern matching paradigm, allowing the refinement of the GCC's internal data management during the pre-hooking phase."
Your hipster hardcore developer friends might want to read the GCC license some day which has an explicit exception allowing the runtime code to be incorporated in closed source software without imposing the terms of the GPL.
I am becoming gerund, destroyer of verbs.
I am not sure of your assessment. Most Linux distributions are currently compiled with GCC, and a lot of embedded systems (or software) are also compiled with GCC. I agree that LLVM/Clang is a healthy competitor, but I won't say that GCC is dead.
The problem is, in part, Lisp's syntax. Most people don't want to read code written in lisp, because (+ (* 3 4) 5) is a big pain. You might look into http://readable.sourceforge.net/ - it extends Lisp s-expressions with additional abbreviations, making it much easier to read.
- David A. Wheeler (see my Secure Programming HOWTO)
That's a very strange definition of great. Virtually everyone relates that word to features, intuitiveness, absence of annoying bugs, etc. That is, to properties of the IDE.
And no, that's not a question of mileage, that's a question of proper use of the language.
The Tao of math: The numbers you can count are not the real numbers.
As I recall, Stallman has specifically stated that GCC is not extensible this way out of the box, because he didn't want the dirty proprietary plugins piggybacking on top of the GPL'd frontend & backend. He said it's why the entire protocol between front-end and back-end is deliberately not standardized. It's also why the license specifically excludes the intermediate output from the usual "output is not covered by GPL" exemption:
"Target Code" refers to output from any compiler for a real or virtual
target processor architecture, in executable form or suitable for
input to an assembler, loader, linker and/or execution
phase. Notwithstanding that, Target Code does not include data in any
format that is used as a compiler intermediate representation, or used
for producing a compiler intermediate representation.
The "Compilation Process" transforms code entirely represented in
non-intermediate languages designed for human-written code, and/or in
Java Virtual Machine byte code, into Target Code. Thus, for example,
use of source code generators and preprocessors need not be considered
part of the Compilation Process, since the Compilation Process can be
understood as starting with the output of the generators or
preprocessors.
A Compilation Process is "Eligible" if it is done using GCC, alone or
with other GPL-compatible software, or if it is done without using any
work based on GCC. For example, using non-GPL-compatible Software to
optimize any GCC intermediate representations would not qualify as an
Eligible Compilation Process.
You have permission to propagate a work of Target Code formed by
combining the Runtime Library with Independent Modules, even if such
propagation would otherwise violate the terms of GPLv3, provided that
all Target Code was generated by Eligible Compilation Processes. You
may then convey such a combination under terms of your choice,
consistent with the licensing of the Independent Modules.