Alternative to compiler-plugins (Re: [A-a-p-user] linking C++ object files)

(x-post between aap and vim MLs, fu2 on [email protected])

* On Mon, Nov 29, 2004 at 05:23:17PM +0100, Bram Moolenaar <[email protected]> wrote:
> > > > > > BTW, is there an AAP compiler-plugin for vim somewhere ?
> > > > [...]
> > > > but I was wondering if a more complete solution already exist.
> > > 
> > > It could be useful, I suppose.  If you can write a first version
> > > of an Aap compiler plugin I can include it with Vim.
> > 
> > I've started working on something. But it cannot be a plain aap
> > compiler-plugin.
> > The problem is we sometimes need to apply different filters on the
> > output of :make. For instance: a filter for aap (or (g)make, or
> > bjam, or scons, or ant, or ...), a filter for GCC (because the link
> > errors are not displayed), a filter for the test unit framework
> > used, a filter for cygwin, a filter for doxygen, ...

> The 'errorformat' option is able to handle several error formats at
> the same time.  You can put very strict formats first, then less
> strict ones.  The first one that matches is used.

'errorformat' is not the problem. As long as I don't want to have
options (/various levels) like what we have with LaTeXSuite.

The main problem is with 'makeprg'. I do not know why, but I must
explicitly use aap.bat, and the outputs must be filtered with an
external script (initially sed, now a perl script). And there are other
tools out there that I plan to use, like the one that decrypt error
messages involving C++'s STL.

> > What is the real `current_compiler' ? It is quite impossible to
> > tell.  With the cygwin compiler-plugin I'm maintaining, I've tried
> > to answer this question. But the answer is not very good, and not
> > really "scalable". Moreover, when we load a compiler-plugin that
> > reset current_compiler, we need to reload compiler/cygwin.vim. It is
> > not very handy.
> 
> It would get complicated if we make compiler-plugin-addons. 

Not really with the framework I am working on.
For instance, I have the add-ons into {rtp}/compiler/BTW/.
And I load them with:
    :BTW set aap      " can be done at any time
    :BTW add gcc      " order may matter, because of the external filters
    :BTW add boost-TU " order may matter ...
    :BTW add cygwin   " order may matter ...

I plan to add priorities, add `remove', be able to change the options
for gcc (without reloading the other definitions), enhance the support
for buffer-local filters (when working with several projects using
different tools)

> You probably need a way to use the existing compiler plugins and
> combine the results.  Since the method to combine them depends on the
> ordering, there is no generic solution.

I am thinking about a way to extract meaningful information from
pre-existing compiler-plugins ; i.e. 'errorformat' and 'makeprg'.

> I suppose you could make an "aap with cygwin and doxygen" compiler
> plugin that loads the cygwin and doxygen compiler plugins and combines
> the pieces.  You still need to make a plugin for every combination you
> use.

That is what I find not scalable. I'd rather have policies (filters)
that I can load and unload independently.

Moreover there would have two different kinds of compiler-plugins. The
core ones, made for one specific tool, and the ones used on specific
projects. Unfortunatelly, the core-ones tend to use some kind of
anti-reinclusion guards, making difficult to mix let's say fortran and
C error messages.

-- 
Luc Hermitte