On 2018-03-30 08:53, Dmitry Olshansky wrote:
With the frame of mind prevalent in our Industry I really want to have
compiler includibg codegen as a bunch of library components.
Then there is no problem innovating while people argue over things
“allowed” for a compiler, or a linker, or a build tool. None of these
actually have to be apps talking via files.
If I look closely every program I see is a graph database, with nodes
sometimes being code, types, sometimes data, other meta-data such as ABI
attributes or conditional compilation flags, documentation, external
tools, specs and databases are also part of this. Code that produces
code is also part of such graph, and CTFE/macroses would just be finer
grained approach.
Why process graphs piece-wise in a frentic dance of command-line tools
that try to fit all to a tree of files (multiple ones, in many location,
and part in some CMS) and then have editors/IDEs integrate? Was easier I
believe + inertia, easy != simple though.
I completely agree. I was quite surprised when I started to use libclang
and the only way to pass options to the library (which are usually
command line flags) was to pass it as an array of command line options.
This is the C API, the C++ API is more advanced.
--
/Jacob Carlborg
