2009/1/24 Enrico Tröger
<enrico.troeger@uvena.de>
On Tue, 20 Jan 2009 17:23:42 +1100, "Lex Trotman" <elextr@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