That code is not as clever as you might think. It just highlights anything coming out of stderr as red.

oooh...
Is there any plan/toughs on what to do for this? Not terminal output, I'm fine if we detect build errors/warnings and show it in a different way, but I'm clueless about all of this...

The build panel (on the right) tries to extract GCC warnings at least using a regex (similar to how Vim does it). But due to inconsistent output from build systems and paths from GCC, it can be difficult to extract the correct file paths.

(In reply to Christian Hergert from comment #3)
> The build panel (on the right) tries to extract GCC warnings at least using
> a regex (similar to how Vim does it). But due to inconsistent output from
> build systems and paths from GCC, it can be difficult to extract the correct
> file paths.

oh I didn't know about this, this is more than enough for the use case I had in mind. Thanks!

(although the bug it's not fixed...true)

For other languages like Vala, not extracted to build panel, is important to show output colors in order to help detect errors and warnings at build time.

While build panel don't detect Vala's error and warnings messages, is really useful to have this colored output.

As a side note, build panel and build output should be bring up when build is initiated.

This issue keeps me using terminal for build Vala projects, but edition inside Builder.

(In reply to Daniel Espinosa from comment #5)
> For other languages like Vala, not extracted to build panel, is important to
> show output colors in order to help detect errors and warnings at build time.

There isn't really a simple solution to this today. The only way to get the correct color output is to use a TTY and a shell so that we can handle the color escape sequences. This is problematic because we might have multiple things that want to log to the build output, and they aren't all subprocesses.

It should be possible to do this with vte_terminal_feed(), but it's not clear to me that we can do it safely/correctly.

> While build panel don't detect Vala's error and warnings messages, is really
> useful to have this colored output.

Writing the regex to extract them should not be terribly difficult. It should look something like this if you want to try it out.

  https://git.gnome.org/browse/gnome-builder/tree/plugins/gcc/gbp-gcc-build-result-addin.c#n26

> As a side note, build panel and build output should be bring up when build
> is initiated.

We won't be doing this until we have transient panels. As it is today you would have to dismiss the panel every time you build.

transient panels are coming, they are in my local spellchecker branch

Created attachment 343275 [details] [review]
BuildResultAddin for Vala patch

I have started to develop a BuildResultAddin for Vala.

I haven't tested it yet, due to problems with Builder to run itself and jhbuild to build gtksourceview master.

I don't know if this is a feature or a bug, but if you use Builder to develop itself, you can't run a development version of it, while your main editor is open, limiting you to get out of Builder before to run it in, for example, jhbuild.

(In reply to Daniel Espinosa from comment #8)
> I have started to develop a BuildResultAddin for Vala.

As it were, BuildResultAddin will go away once I land the new build pipeline. The main thing is that we get the regex we need, and I'll port it to the pipeline.

> I haven't tested it yet, due to problems with Builder to run itself and
> jhbuild to build gtksourceview master.

You don't need gtksourceview master, you need `jhbuild buildone gtksourceview-3`.

> I don't know if this is a feature or a bug, but if you use Builder to
> develop itself, you can't run a development version of it, while your main
> editor is open, limiting you to get out of Builder before to run it in, for
> example, jhbuild.

You can, use `make run` which uses the --standalone option.

May this is not place to report this but there is a missing file:

include $(top_srcdir)/libidemm/compile-binding.am

As defined at

https://git.gnome.org/browse/gnome-builder/tree/libidemm/idemm/Makefile.am

This prevent me to compile Builder, in order to test my patch.

Try installing `mm-common` and re-run autogen.sh. We are not very good today at making the developer workflow not require glibmm.

I have installed mm-common already, but build fail:

No rule to build 'application.cc', needed by 'application.lo'

By checking libiedmm autotools build, I found libidemm/compile-binding.am file doesn't exist.

And no rule to create appliation.cc from application.ccg, and other ccg and hg files in libiedmm/src directory.


I've tried to disable libiedmm, using --enable-iedmm=no, but that doesn't work.

I've uninstalled gtkmm, in order to run autogen.sh and get disable iedmm automatically.

Now I'm testing my patch.

I found my addinn is loaded, but never used by Builder. May I need to register Vala build messages any other place? Without this I can't see if regex are correct or not.

Assuming you're on the master branch, you should just need to implement Ide.BuildResultAddin and register it in vala-pack-plugin.vala.

That said, if you can hold out a week or so, just send me the regex and I can port it to the pipeline branch like I've done for the GCC plugin.

Created attachment 344368 [details] [review]
Fixed version of Vala Build Result Addin

This patch now includes an implementation and regular expressions for Vala messages.

It has references to:

.buildconfig
build/autotools/ax_cxx_compile_stdcxx.m4

Files I don't know why exists in repository, because: first one is a local configuration and last is autogenerated (I think).

Please review and I can push to master.

Many thanks for your support.

Review of attachment 344368 [details] [review]:

Looks good, but I think I'll hold off merging this to master so that it can be done as part of the IdeBuildPipeline merge. It will reduce the patchset into just the regex definition.

Thanks for your comments and support. Hope IdeBuildPipeline comes up shortly.

I would like to see this work backported to 3.22, because it will be used by lot of Debian Stable users.

Are you Ok to backport?

I just noticed that this seems to use the same regex as the GCC error format, which is probably not what you want?

I'm not keen on the idea of backporting, because I wan't people using the flatpak version of Builder. The code-base still moves so quickly that trying to triage code that is ~30,000 LOC different already is not a good use of our resources and time.

Created attachment 346998 [details] [review]
vala: add error regex for vala build errors

This is (what i hope) a someone reasonable regex for matching vala errors
from the console output.

It does expose another error, though, which is that we only get short names
from the valac compiler (main.vala, etc), and we are not translating that
to the proper source directly properly.

That means that when opening the file, we are likely going to get the wrong
path right now ($builddir/main.vala) instead of ($srcdir/main.vala).

This at least fixes the plumbing required to get the vala diagnostics. We still
need to fix some $builddir vs $srcdir stuff though. But that is a separate,
more generic issue to be solved with IdeBuildPipeline.

Attachment 346998 [details] pushed as 895726f - vala: add error regex for vala build errors