[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] automake: avoid harmful directory change before invoking val

From: Stefano Lattarini
Subject: Re: [PATCH] automake: avoid harmful directory change before invoking valac
Date: Tue, 23 Dec 2014 19:30:38 +0100

On 12/22/2014 01:36 PM, Yanko Kaneti wrote:
On Mon, 2014-12-22 at 12:05 +0100, Stefano Lattarini wrote:
On 12/22/2014 11:32 AM, Yanko Kaneti wrote:
On Fri, 2014-12-19 at 22:01 +0100, Stefano Lattarini wrote:
Hi, thanks for the patch, and sorry for the delay.

On 12/02/2014 02:22 PM, Yanko Kaneti wrote:
The current am__cd right before invoking valac invalidates
any relative flags setup done before that.
BTW, this was already reported as
So finally fixing it would likely be a good idea.

    bin/ | 3 ++-
    1 file changed, 2 insertions(+), 1 deletion(-)

Such a fix requires at least a new test case and a NEWS entry.
Care to take at stab at writing them?

I looked a bit in the t/ directory but my eyes glazed over.
Perhaps I am not the best person to attempt those.

It's OK if you can just post the snippets of relevant vala sources
and build options exposing the problem, and describe the steps to
reproduce such a problem.  I can synthesize a test case from there
myself then.

It was exposed by a builddir != srcdir problem in gsound in gnome
git (linked bugreport above)
where a test program (gsound-play.vala) needs the gsound vapis which
are also a build product.

The way to reproduce it is:

- autogen gsound with the workaround (4f8a78c) removed
- mkdir _build & cd _build
- ../configure
- notice how the gsound-play compile fails  in the _srcdir_ (because
of the the "am__cd")  but its arguments are trying to use ../gsound
instead of the builddir gsound

Hope that helps.

Since I know almost nothing about Vala, and I'm short of time these
days, I don't think I will go perusing into a third-party project
to find a test case; a minimal reproducer in form of Vala sources,
a fragment, and an high-level description of the expected
behavior) would be appreciated, and would help in speeding up the


reply via email to

[Prev in Thread] Current Thread [Next in Thread]