[Geany-devel] Update to build support

[Lex Trotman]

Hi Enrico,


2009/1/24 Enrico Tröger <enrico.troeger at uvena.de>

> On Tue, 20 Jan 2009 17:23:42 +1100, "Lex Trotman" <elextr at gmail.com>
> wrote:
>
> Hey Lex,
>
> >Sorry for the long silence, I had a family health problem which had me
> >away from home and with only access to email, no upload or download.
>
> Hope things will get better soon.
>

They are now thanks.

>
>
> >The C++ work I have done in the meantime has re-inforced my desire to
> >be able to at least compile C++ headers by themselves to get out the
> >syntax typos because they tend to cause a lot of "flow on" errors in
> >the .cpp file and C++ generates such enormous error messages (see
> >http://www.parashift.com/c++-faq-lite/templates.html#faq-35.17 for an
> >example).  Also I have noticed that Geany 0.15 is very slow when there
> >are lots of errors, maybe the regex parse is a bit slow, anyway that
>
> Unless you set custom regexps in filetypes.cpp yourself, Geany won't
> use them by default (for C/C++), instead it parses the output by
> cutting the error message string using C/Glib string functions. Anyway,
> I think the snowiness comes more from adding the error message string
> to the compiler messages window.
> Though I don't think this is a big issue, we could maybe execute the
> build command (g_spawn_async_with_pipes()) in another thread including
> the parsing, and then write the result into a temporary buffer which is
> read by the main thread and fills the compiler messages window.
> This could work in theory thus needs a lot work and code re-organising
> plus carefully writing the separate thread as there can't be any GTK
> code.
> Additionally, single core machines probably won't benefit from this
> separation. So, if we want to do this, we should do this afterwards.
>

I'm not using any custom regexes so I guess it is just the GTK stuff.  I
wasn't suggesting that a lot of effort be expended on this, and as you noted
single core wouldn't benefit anyway, it is just an observation that it can
be an impact on slower machines.

>
>
> >The question seems to be how we handle having different commands for
> >the header files (different to the .cpp files that is) without
> >creating new filetypes for them.
>
> I still don't know why compiling header files can't be done using with
> one of the configurable filetype commands you are about to implement.
> Users who want compile headers simply add a third command for it (or we
> add it by default, doesn't matter).
>

It would certainly work having .hpp and .cpp compile commands in the same
menu, the only issue was that choosing the wrong command could have
unexpected effects, such as g++ overwriting a .o file with a pre-compiled
header.  Thats the behaviour of the default .cpp compile command applied to
a header so I was looking at how to remove the risk.

Perhaps a simpler option is to make compiling headers a preference item, off
by default so it is safe for beginners, and let anyone who enables it be
carefull!!  Then they can define any spare filetype compile command for
themselves.

This would be enough for me, although I am sure I will swear about you every
time I use the wrong command ;-)


>
>
> >My last proposal was for a "variant" of the filetype which allowed
> >different commands.  The variant was identified by a subset of the
> >filetypes extensions.  This is a slightly general solution
> >configurable in the filetypes or preferences files, or another option
> >is something hard coded specifically for header files, not my
> >favourite :(.
>
> IIRC we decided to not go this way, but I might be wrong.


Last I heard Nick was going to look at the code changes but I have heard
nothing since then.


> And
> currently, I don't have the time to deeply get into this discussion
> again since there are so many other problems and discussions around
> here at the moment plus we are heavily going to the next release (mid
> February maybe).


 I wouldn't expect to get the build-system into a mid Feb release, not
enough testing time for such a big change. Which brings up a point, I will
update the build-system branch to trunk so merges will be simpler, what is
the  best trunk version to use, latest or a specific one?

>
>
> Regards,
> Enrico
>


Cheers
Lex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geany.org/pipermail/devel/attachments/20090125/2f9eb32b/attachment.html>