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

Previous Next

Full log

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)]

Previous Next

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