Transforming paths in compilation output (containerized builds)

Transforming paths in compilation output (containerized builds)

[Björn Bidar]

Hello,

I'm looking how to transform the output in the compilation buffer or
just make Emacs open the correct paths inside builds happen inside
containerized builds.

The output of the programs ran inside these environments relates
to the environment they are build in e.g. container in
/var/tmp/build-root/<name> and output as if /var/tmp/build-root/<name>
is /.

I'm having this situation when building with osc build which sets up a
linux environment generated according to the settings of the repository,
e.g. a Debian system debbuild or openSUSE system with rpmbuild with
the dependencies required to build a package. For context osc is the
commandline client to the Open Build Service also known as openSUSE build service.

The builds can be inside a change root, a container or a vm.

The second example would be builds in Scratchbox2, a cross compiling
environment.
There the paths are also relative to the environment, a Scratchbox2
target or if they don't exist in the target simply relative to the host.

E.g. /usr/include/foo.h -> target
~/project/foo.c -> host

I did some research, I found other modes such as ppcompile which uses
compilation-finish-functions.
For remote environments I know that tramp uses file-name-handler-alist.
Is it possible to register temporary file-name handler for this context
or are there better methods to achieve what I want to do?

Have a great weekend,

Björn

Re: Transforming paths in compilation output (containerized builds)

[Eli Zaretskii]

> From: Björn Bidar <bjorn.bidar@thaodan.de>
> Date: Sat, 07 Dec 2024 21:58:36 +0200
> 
> I'm looking how to transform the output in the compilation buffer or
> just make Emacs open the correct paths inside builds happen inside
> containerized builds.

Is compilation-transform-file-match-alist what you are looking for?

Re: Transforming paths in compilation output (containerized builds)

[Björn Bidar]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Björn Bidar <bjorn.bidar@thaodan.de>
>> Date: Sat, 07 Dec 2024 21:58:36 +0200
>> 
>> I'm looking how to transform the output in the compilation buffer or
>> just make Emacs open the correct paths inside builds happen inside
>> containerized builds.
>
> Is compilation-transform-file-match-alist what you are looking for?

The variable talks only about errors. Does it apply to all messages not just
the errors?

Re: Transforming paths in compilation output (containerized builds)

[Eli Zaretskii]

> From: Björn Bidar <bjorn.bidar@thaodan.de>
> Cc: help-gnu-emacs@gnu.org
> Date: Sat, 07 Dec 2024 23:17:28 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Björn Bidar <bjorn.bidar@thaodan.de>
> >> Date: Sat, 07 Dec 2024 21:58:36 +0200
> >> 
> >> I'm looking how to transform the output in the compilation buffer or
> >> just make Emacs open the correct paths inside builds happen inside
> >> containerized builds.
> >
> > Is compilation-transform-file-match-alist what you are looking for?
> 
> The variable talks only about errors. Does it apply to all messages not just
> the errors?

It is applied to all messages.

Re: Transforming paths in compilation output (containerized builds)

[Yuri Khan]

On Sun, 8 Dec 2024 at 02:59, Björn Bidar <bjorn.bidar@thaodan.de> wrote:

> I'm looking how to transform the output in the compilation buffer or
> just make Emacs open the correct paths inside builds happen inside
> containerized builds.
>
> The output of the programs ran inside these environments relates
> to the environment they are build in e.g. container in
> /var/tmp/build-root/<name> and output as if /var/tmp/build-root/<name>
> is /.

I’m using this for containerized builds.

    (defvar yk-compilation-filter-alist nil
      "List of (REGEXP REPLACEMENT) to apply to compilation messages.")

    (defun yk-compilation-filter ()
      "Apply replacements to compilation messages."
      (save-excursion
        (pcase-dolist (`(,regexp ,replacement) yk-compilation-filter-alist)
          (goto-char compilation-filter-start)
          (beginning-of-line)
          (while (re-search-forward regexp nil t)
            (replace-match replacement nil nil)))))

The variable is set directory-locally on the project root:

    ((nil . ((yk-compilation-filter-alist
              . (("/my/container/root/" "/home/myself/project/"))))))

The filter function is permanently added to the
‘compilation-filter-hook’ variable.

I may have had to work around the bug where a ‘compilation-mode’
buffer that is not visiting a file does not pick up directory-local
variables, by adding ‘hack-local-variables’ to
‘compilation-mode-hook’. I did not file a proper bug report at the
time.

Re: Transforming paths in compilation output (containerized builds)

[Yuri Khan]

On Sun, 8 Dec 2024 at 12:43, Eli Zaretskii <eliz@gnu.org> wrote:

> > > Is compilation-transform-file-match-alist what you are looking for?
> >
> > The variable talks only about errors. Does it apply to all messages not just
> > the errors?
>
> It is applied to all messages.

In my experience, it is not applied to messages as such. It is
consulted when building text properties while fontifying the messages
so that the user can jump to error locations; but the actual visible
text in the buffer remains unmodified.

Re: Transforming paths in compilation output (containerized builds)

[Eli Zaretskii]

> From: Yuri Khan <yuri.v.khan@gmail.com>
> Date: Sun, 8 Dec 2024 13:32:27 +0700
> Cc: help-gnu-emacs@gnu.org
> 
> On Sun, 8 Dec 2024 at 12:43, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > > > Is compilation-transform-file-match-alist what you are looking for?
> > >
> > > The variable talks only about errors. Does it apply to all messages not just
> > > the errors?
> >
> > It is applied to all messages.
> 
> In my experience, it is not applied to messages as such. It is
> consulted when building text properties while fontifying the messages
> so that the user can jump to error locations; but the actual visible
> text in the buffer remains unmodified.

Yes.  As its doc string says.

Re: Transforming paths in compilation output (containerized builds)

[Björn Bidar]

Yuri Khan <yuri.v.khan@gmail.com> writes:

> On Sun, 8 Dec 2024 at 12:43, Eli Zaretskii <eliz@gnu.org> wrote:
>
>> > > Is compilation-transform-file-match-alist what you are looking for?
>> >
>> > The variable talks only about errors. Does it apply to all messages not just
>> > the errors?
>>
>> It is applied to all messages.
>
> In my experience, it is not applied to messages as such. It is
> consulted when building text properties while fontifying the messages
> so that the user can jump to error locations; but the actual visible
> text in the buffer remains unmodified.

That the actual text remains unmodified is good, it's actually better
since it doesn't reveal any private information/makes the output depend on the
users machine.

As long as it applies to all messages it's good. Maybe the description
or the name of the variable should be changed then.

I looked at the integration for the other container engines for
inspiration on how to solve this issue.
None of them handle this issue or are affected.

Re: Transforming paths in compilation output (containerized builds)

[Eli Zaretskii]

> From: Björn Bidar <bjorn.bidar@thaodan.de>
> Cc: Eli Zaretskii <eliz@gnu.org>,  help-gnu-emacs@gnu.org
> Date: Sun, 08 Dec 2024 21:45:15 +0200
> 
> Yuri Khan <yuri.v.khan@gmail.com> writes:
> 
> > On Sun, 8 Dec 2024 at 12:43, Eli Zaretskii <eliz@gnu.org> wrote:
> >
> >> > > Is compilation-transform-file-match-alist what you are looking for?
> >> >
> >> > The variable talks only about errors. Does it apply to all messages not just
> >> > the errors?
> >>
> >> It is applied to all messages.
> >
> > In my experience, it is not applied to messages as such. It is
> > consulted when building text properties while fontifying the messages
> > so that the user can jump to error locations; but the actual visible
> > text in the buffer remains unmodified.
> 
> That the actual text remains unmodified is good, it's actually better
> since it doesn't reveal any private information/makes the output depend on the
> users machine.
> 
> As long as it applies to all messages it's good. Maybe the description
> or the name of the variable should be changed then.

Already done.