Loading ...
Sorry, an error occurred while loading the content.

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

Expand Messages
  • Luc Hermitte
    (x-post between aap and vim MLs, fu2 on vim@vim.org) ... errorformat is not the problem. As long as I don t want to have options (/various levels) like what
    Message 1 of 1 , Nov 29, 2004
      (x-post between aap and vim MLs, fu2 on vim@...)

      * On Mon, Nov 29, 2004 at 05:23:17PM +0100, Bram Moolenaar <Bram@...> 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
    Your message has been successfully submitted and would be delivered to recipients shortly.