GNU bug report logs - #13002
directory variables in VALAFLAGS are expanded after cd

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 13002 in the body.
You can then email your comments to 13002 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Daiki Ueno <ueno <at> unixuser.org>
To: bug-automake <at> gnu.org
Subject: directory variables in VALAFLAGS are expanded after cd
Date: Mon, 26 Nov 2012 20:03:38 +0900

Hi,

I see quite a few Vala projects setting VALAFLAGS as follows:

libfolks_eds_la_VALAFLAGS = \
        --vapidir=. \
        --vapidir=$(top_srcdir)/folks \
        ...

This is referred by the generated rule in Makefile.in as:

$(AM_V_VALAC)$(am__cd) $(srcdir) && $(VALAC) $(libfolks_eds_la_VALAFLAGS) $(VALAFLAGS) -C $(libfolks_eds_la_SOURCES)

Here, if $(srcdir) != $(builddir) and $(top_srcdir) is a relative path
from $(builddir), the --vapidir option will point to a wrong location.

Though this could be worked around by using $(abs_top_srcdir) instead of
$(top_srcdir), it looks to me a bit unintuitive.  It would be nice that
automake handles this case nicely.

Regards,
-- 
Daiki Ueno

Message #8 received at 13002 <at> debbugs.gnu.org (full text, mbox):

From: Daniel Espinosa <esodan <at> gmail.com>
To: 13002 <at> debbugs.gnu.org
Subject: Fwd: Bug fix patch
Date: Thu, 28 Jul 2016 10:18:05 -0500

[Message part 1 (text/plain, inline)]

Sorry this is the correct but this patch belongs to.

---------- Forwarded message ----------
From: Daniel Espinosa <esodan <at> gmail.com>
Date: 2016-07-28 10:16 GMT-05:00
Subject: Bug fix patch
To: 16341 <at> debbugs.gnu.org


Attached you'll find a patch for this bug, including some improvements to
Vala support.

-- 
This electronic message may contain privileged and confidential information
intended only for the use of the addressees named above.  If you are not
the intended recipient of this email, we kindly ask you to delete this
message and any attachment. You are hereby notified that any use,
dissemination, distribution, reproduction of this email is prohibited.  If
you have received this email in error, please notify sender immediately.

Any document, image or any other form of electronic representation of any
work attached to this email, is suitable to be protected by copyright
enforcement by applicable law in your or sender's Country's and
International Legislation

Trabajar, la mejor arma para tu superación
"de grano en grano, se hace la arena" (R) (en trámite, pero para los
cuates: LIBRE)



-- 
This electronic message may contain privileged and confidential information
intended only for the use of the addressees named above.  If you are not
the intended recipient of this email, we kindly ask you to delete this
message and any attachment. You are hereby notified that any use,
dissemination, distribution, reproduction of this email is prohibited.  If
you have received this email in error, please notify sender immediately.

Any document, image or any other form of electronic representation of any
work attached to this email, is suitable to be protected by copyright
enforcement by applicable law in your or sender's Country's and
International Legislation

Trabajar, la mejor arma para tu superación
"de grano en grano, se hace la arena" (R) (en trámite, pero para los
cuates: LIBRE)

[Message part 2 (text/html, inline)]

[0001-Vala-support:improvementsbugfixes.patch (text/x-patch, attachment)]

Message #11 received at 13002 <at> debbugs.gnu.org (full text, mbox):

From: Karl Berry <karl <at> freefriends.org>
To: esodan <at> gmail.com
Cc: 13002 <at> debbugs.gnu.org
Subject: Re: bug#13002: Fwd: Bug fix patch
Date: Sat, 18 Jul 2020 19:34:04 -0600

[Message part 1 (text/plain, inline)]

Hi Daniel,

    Attached you'll find a patch for this bug, including some improvements to
    Vala support.

Thanks again for this patch and the copyright assignment.

Unfortunately, after locally applying the patch, several of
your new tests fail with make (dist)check, as well as some of the
existing vala tests.
    FAIL: t/vala-headers.sh
    FAIL: t/vala-libs-distcheck.sh
    FAIL: t/vala-non-recursive-setup.sh
    FAIL: t/vala-parallel.sh
    FAIL: t/vala-recursive-setup.sh
    FAIL: t/vala-vpath.sh

Looking at the logs, for instance for vala-vpath.sh, the
  test -f ../foo_vala.stamp
from the build/ subdir does not find the file, since the stamp files are
also in the build/ subdir. Which seems correct, but I am not sure what's
intentional and what's erroneous.

Any chance you can look into this? I will attach the patch as I have it
locally now. (This is the output from git diff --staged; if it's easier
for you work with format-patch output, just let me know.)

There were a couple other vala-related changes made between now and when
you submitted the patch, but I don't think they affect your work. Here
are their ChangeLog entries:

2020-06-06  Karl Berry  <karl <at> freefriends.org>

	This change fixes https://bugs.gnu.org/41726.
	* t/vala-mix2.sh: extern in .h, initialization in .c.
	GCC 10 defaults to -fno-common.

2020-04-05  Colomban Wendling  <lists.ban <at> herbesfolles.org>

	This change fixes https://bugs.gnu.org/18734.
	* bin/automake.in (lang_vala_finish_target): anchor option regexp
	so that, e.g., an argument "vapi" does not match the option --vapi.

[vala-vpath.diff (application/octet-stream, attachment)]

Message #14 received at 13002 <at> debbugs.gnu.org (full text, mbox):

From: Reuben Thomas <rrt <at> sc3d.org>
To: 13002 <at> debbugs.gnu.org
Subject: Dealing with C intermediate files
Date: Sat, 24 Oct 2020 00:14:48 +0100

[Message part 1 (text/plain, inline)]

I've had a look at the patch now, and found and fixed one bug.

However, an issue comes up for VPATH builds that needs a more thorough fix:
C files generated from Vala sources are shipped by "make dist" and hence
end up in srcdir, but in a VPATH build with a Vala compiler, they will be
in builddir. Unlike include files, you can't simply tell cc to look in two
places for the file it is to compile, so some other solution is needed.

There are various other cases in which I'm aware of generated sources being
shipped in tarballs, but they're all different sorts of special cases. For
example, configure is shipped, but it's always in srcdir. Other files, e.g.
man pages generated by help2man, have special rules to avoid regeneration,
but are not themselves used to generate further files. So, I couldn't see a
model to follow.

I can see a couple of options:

1. Treat valac-generated files as normal intermediate files, don't ship
them in make dist, and require a Vala compiler to build Vala sources. This
is not a huge deal, as almost all Vala programs will require the same
libraries as Vala itself, i.e. glib (and gio?).

2. Add build-aux/valac, a "missing" script that just copies a C file from
srcdir to builddir if it is newer than the corresponding Vala file, and
otherwise gives an error. Using the "missing" mechanism to add limited
functionality seems a fairly autotools-y thing to do.

Any other ideas?

-- 
https://rrt.sc3d.org

[Message part 2 (text/html, inline)]

Message #17 received at 13002 <at> debbugs.gnu.org (full text, mbox):

From: Hans-Bernhard Bröker <HBBroeker <at> t-online.de>
To: 13002 <at> debbugs.gnu.org
Subject: Re: bug#13002: Dealing with C intermediate files
Date: Sat, 24 Oct 2020 17:22:58 +0200

Am 24.10.2020 um 01:14 schrieb Reuben Thomas via Bug reports for Automake:
> Unlike include files, you can't simply tell cc to 
> look in two places for the file it is to compile, so some other solution 
> is needed.

Actually the traditional VPATH mechanism does not distinguish types of 
files at all.  C source files can be vpath-searched quite fine.

> So, I couldn't see a model to follow.

The obvious canonical examples would have to be lex and yacc.  They 
generate .c and .h files into the blddir, and automake has built-in 
mechanisms to include the generated sources into the tarball.

Message #20 received at 13002 <at> debbugs.gnu.org (full text, mbox):

From: Karl Berry <karl <at> freefriends.org>
To: HBBroeker <at> t-online.de
Cc: 13002 <at> debbugs.gnu.org
Subject: Re: bug#13002: Dealing with C intermediate files
Date: Sat, 24 Oct 2020 09:53:25 -0600

    The obvious canonical examples would have to be lex and yacc.  They 
    generate .c and .h files into the blddir, and automake has built-in 
    mechanisms to include the generated sources into the tarball.

No argument there, but vala is so much newer than lex and yacc,
especially in terms of Automake support. I don't see the need to create
in these latter days yet another special case for treating intermediate
files non-intermediately.

Reuben's option 1 seems simplest to me: just treat the vala intermediate
files as intermediate. Not in make dist.

Jim/Paul/anyone, wdyt?

Message #23 received at 13002 <at> debbugs.gnu.org (full text, mbox):

From: Hans-Bernhard Bröker <HBBroeker <at> t-online.de>
To: Karl Berry <karl <at> freefriends.org>
Cc: 13002 <at> debbugs.gnu.org
Subject: Re: bug#13002: Dealing with C intermediate files
Date: Sat, 24 Oct 2020 18:31:04 +0200

Am 24.10.2020 um 17:53 schrieb Karl Berry:
>      The obvious canonical examples would have to be lex and yacc.  They
>      generate .c and .h files into the blddir, and automake has built-in
>      mechanisms to include the generated sources into the tarball.
> 
> No argument there, but vala is so much newer than lex and yacc,
> especially in terms of Automake support. I don't see the need to create
> in these latter days yet another special case for treating intermediate
> files non-intermediately.

Well, so how about un-special-casing the existing machinery a bit?  It's 
quite exactly the same job that needs to be done, so at the very least, 
the existing yacc/lex handling code could serve as a template.  With a 
bit of good look, the end result might be that yacc, lex and vala are 
all just triggering a single, shared implementation, which can also be 
made available for generic usage by other source-code generating tools.

Message #26 received at 13002 <at> debbugs.gnu.org (full text, mbox):

From: Karl Berry <karl <at> freefriends.org>
To: HBBroeker <at> t-online.de
Cc: 13002 <at> debbugs.gnu.org
Subject: Re: bug#13002: Dealing with C intermediate files
Date: Sat, 24 Oct 2020 15:24:41 -0600

    quite exactly the same job that needs to be done

It's the same job, but lex and yacc are not at all the "same" as vala.
They are fundamental Unix utilities that have been around
forever. Whereas vala is a relatively recent invention, far less
ubiquitous. So I see no reason to treat them the same way.

Also, the point of having the lex/yacc .c files in make dist in the
first place is to reduce interdependencies among packages. But merely
distributing the .c files for vala does not seem likely tome to be enough
to actually eliminate the need for vala in practice.

Even if it is, looking to the future, it seems to me it would be better
to treat intermediate files as intermediate, and not distribute them in
make dist.  lex/yacc (and .info, etc.) have to be grandfathered in, but
creating new such special cases feels like a mistake to me. Every one of
the cases is a hassle in the code and causes plenty of confusion for
users. Let's not compound the problems. -k

Message #29 received at 13002 <at> debbugs.gnu.org (full text, mbox):

From: Reuben Thomas <rrt <at> sc3d.org>
To: 13002 <at> debbugs.gnu.org
Subject: Updated, fixed patch
Date: Wed, 28 Oct 2020 17:30:56 +0000

[Message part 1 (text/plain, inline)]

I have taken Daniel Espinosa's patch and improved it so that it fixes all
the test failures. Some of the failures were actually left-over changes to
the tests required by Daniel's patch, which (correctly) considers the
primary location of C files generated by valac to be builddir, not srcdir.

One change in particular is quite awkward, and could do with other eyes, to
see if it's correct, and even if so, whether it could be simplified: the
additional check in line 5737 of automake.in which checks whether there's a
pre-built .c file in srcdir, and, if srcdir != builddir, copies the file
there if it is newer than the corresponding .vala file.

Having worked on this patch, I do wonder whether the hacks involved are
worth it. It seems to me there are two sensible options:

1. Add more support to automake for files that can be either generated or
distributed. (Have I overlooked support for this?)

2. Remove the support for distributing Vala projects as C files that do not
require a Vala compiler. The Vala compiler is portable and has much the
same dependencies as most Vala projects (that is, a C compiler and glib).

Without one of these, bugs and fragility in Vala support are likely to
continue.

-- 
https://rrt.sc3d.org

[Message part 2 (text/html, inline)]

[0001-Improve-Vala-support-closes-13002.patch (text/x-patch, attachment)]

Message #32 received at 13002 <at> debbugs.gnu.org (full text, mbox):

From: Karl Berry <karl <at> freefriends.org>
To: rrt <at> sc3d.org
Cc: 13002 <at> debbugs.gnu.org
Subject: Re: bug#13002: Updated, fixed patch
Date: Wed, 28 Oct 2020 14:37:46 -0600

Hi Reuben - thanks for all your work on this.
(And again to Daniel for the initial patch.)

    2. Remove the support for distributing Vala projects as C files that do not
    require a Vala compiler. The Vala compiler is portable and has much the
    same dependencies as most Vala projects (that is, a C compiler and glib).

As I wrote before, I strongly support this approach. Since the C file is
derived, don't distribute it. Would that simplify the patch?

Jim or Paul or anyone, if you object (?!), please speak ... --thanks, karl.

Message #35 received at 13002 <at> debbugs.gnu.org (full text, mbox):

From: Reuben Thomas <rrt <at> sc3d.org>
To: Karl Berry <karl <at> freefriends.org>
Cc: 13002 <at> debbugs.gnu.org
Subject: Re: bug#13002: Updated, fixed patch
Date: Wed, 28 Oct 2020 22:56:13 +0000

[Message part 1 (text/plain, inline)]

On Wed, 28 Oct 2020 at 20:37, Karl Berry <karl <at> freefriends.org> wrote:

>
> As I wrote before, I strongly support this approach. Since the C file is
> derived, don't distribute it. Would that simplify the patch?
>

A patch to re-do Vala support would be a larger patch at this stage, though
overall it would certainly streamline Vala support in automake.

Also, being frank, removing "Vala-generated-C" support is the only way I
would offer to have anything to do with making such a patch, as (as far as
I can see) that route would be much simpler than retaining the current
support (even in deprecated form) while also putting in "normal" Vala
compiler support.

I also sympathise with the maintainers if they would rather not simply
remove the existing C-from-Vala support. I would offer the following
observation, though: as far as I can tell, most Vala developers are
migrating away from autotools (if they used it) to meson, along with the
rest of the GNOME ecosystem. Also, it's fairly straightforward to get old
versions of automake where needed. This could be used to argue in either
direction: on the one hand, replacing the current Vala support with
"normal" support would annoy a small proportion (committed automake users)
of a small user group (Vala programmers). On the other, it would benefit
few users.

It might be best then to make the decision based on automake's other users?
I for one would not be terribly happy as an automake maintainer at having
to keep Vala support working long-term, and to be honest, the patch I have
submitted, while fixing bugs in Vala support, will slightly add to the
maintenance burden.

My own use case is that I've rewritten GNU Zile (a small Emacs clone) in
Vala. Users building it will have to install glib anyway, and so while it
feels nice that they don't need a Vala compiler, as I said before, I don't
think in practice it's a big deal (even for a Zile user who doesn't care
about Vala, they're likely to be able to install valac easily using
whatever package manager they have).

-- 
https://rrt.sc3d.org

[Message part 2 (text/html, inline)]

Message #38 received at 13002 <at> debbugs.gnu.org (full text, mbox):

From: Reuben Thomas <rrt <at> sc3d.org>
To: Karl Berry <karl <at> freefriends.org>
Cc: 13002 <at> debbugs.gnu.org
Subject: Re: bug#13002: Updated, fixed patch
Date: Wed, 28 Oct 2020 22:58:09 +0000

[Message part 1 (text/plain, inline)]

To follow up clearly: if it were up to me, I'd install an acceptable
version of my patch, as it improves the status quo, and include it in the
next release. Then I'd think about whether it's possible to redo the Vala
support entirely.

-- 
https://rrt.sc3d.org

[Message part 2 (text/html, inline)]

Message #41 received at 13002 <at> debbugs.gnu.org (full text, mbox):

From: Karl Berry <karl <at> freefriends.org>
To: rrt <at> sc3d.org
Cc: 13002 <at> debbugs.gnu.org
Subject: Re: bug#13002: Updated, fixed patch
Date: Thu, 29 Oct 2020 19:45:25 -0600

    install an acceptable version of my patch, as it improves the status
    quo, and include it in the next release. Then I'd think about
    whether it's possible to redo the Vala support entirely.

Sounds sensible.

I applied your change, but when running make distcheck (not make check) 
the new vala-libs-distcheck.sh test fails. Does that happen for you?

Most of the other vala tests are skipped, with the message:
vala-libs-vpath: skipped test: pkg-config m4 macros not found

I don't see anything especially different in vala-libs-distcheck than
the others. vala-libs-vpath has exactly the same list of required=
programs and it is skipped.

The failure output is:
./configure: line 4032: syntax error near unexpected token `0.22'
./configure: line 4032: `PKG_PROG_PKG_CONFIG(0.22)'
which is expected, but clearly it shouldn't be getting to that point if
it can't find pkg.m4. (I think make distcheck sets up an environment
where any system pkg.m4, among others, will not be found.) I note that
this is the only call to any PKG_ macro other than PKG_CHECK_MODULES,
although I don't see why that should matter.

I'll try to pursue further tomorrow/soon, but thought I'd report now and
see if you get the same ... --thanks, karl.

Message #44 received at 13002 <at> debbugs.gnu.org (full text, mbox):

From: Reuben Thomas <rrt <at> sc3d.org>
To: Karl Berry <karl <at> freefriends.org>
Cc: 13002 <at> debbugs.gnu.org
Subject: Re: bug#13002: Updated, fixed patch
Date: Sun, 1 Nov 2020 22:55:00 +0000

[Message part 1 (text/plain, inline)]

On Fri, 30 Oct 2020 at 01:45, Karl Berry <karl <at> freefriends.org> wrote:

>     install an acceptable version of my patch, as it improves the status
>     quo, and include it in the next release. Then I'd think about
>     whether it's possible to redo the Vala support entirely.
>
> Sounds sensible.
>
> I applied your change, but when running make distcheck (not make check)
> the new vala-libs-distcheck.sh test fails. Does that happen for you?
>

I get no errors.

Most of the other vala tests are skipped, with the message:
> vala-libs-vpath: skipped test: pkg-config m4 macros not found
>

I do not get these errors or skips: all the vala tests are run, and pass.

I confirm that I ran "make distcheck".

-- 
https://rrt.sc3d.org

[Message part 2 (text/html, inline)]

Message #47 received at 13002 <at> debbugs.gnu.org (full text, mbox):

From: Karl Berry <karl <at> freefriends.org>
To: rrt <at> sc3d.org
Cc: 13002 <at> debbugs.gnu.org
Subject: Re: bug#13002: Updated, fixed patch
Date: Sat, 7 Nov 2020 19:45:20 -0700

    I have taken Daniel Espinosa's patch and improved it so that it
    fixes all the test failures.

Reuben, thank you very much for dealing with everything, and thanks to
Daniel for the original work.

make check && make distcheck are working for me now.
I have pushed the changes (with fingers crossed)
and am closing this bug. -k

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.