GNU bug report logs - #12540
Usage of srcdir when valac is generating a header file

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 12540 in the body.
You can then email your comments to 12540 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: Vivien Malerba <vmalerba <at> gmail.com>
To: bug-automake <at> gnu.org
Subject: Usage of srcdir when valac is generating a header file
Date: Sat, 29 Sep 2012 19:32:11 +0200

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

Hi!

I'm working on the Libgda project, which includes Vala source code. I use
the Autotools to generate the Makefiles and I've noticed that during the
conversion of vala code to C an H code a .stamp file is generated (from
what I understand, that timestamped file is then a dependency for all the
Vala files' conversion). The Automake's code to make that happen is:
foreach my $vala_file (@vala_sources)
    {
      my $c_file = $vala_file;
      if ($c_file =~ s/(.*)\.vala$/$1.c/)
        {
          $c_file = "\$(srcdir)/$c_file";
          $output_rules .= "$c_file: \$(srcdir)/${derived}_vala.stamp\n"
            . "\t\@if test -f \$@; then :; else rm -f
\$(srcdir)/${derived}_vala.stamp; fi\n"
            . "\t\@if test -f \$@; then :; else \\\n"
            . "\t  \$(MAKE) \$(AM_MAKEFLAGS)
\$(srcdir)/${derived}_vala.stamp; \\\n"
            . "\tfi\n";
          $clean_files{$c_file} = MAINTAINER_CLEAN;
        }
    }

You can see that the .stamp file is generated in the $(srcdir) directory
instead of $(builddir), which breaks the rule when building out of sources.
My suggestion is to replace $(srcdir) with $(builddir) (this timestamp file
is also a build dependency for each vala file, so there is more code
impacted than the snippet above).

Best regards,

Vivien

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

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

From: Nick Bowler <nbowler <at> elliptictech.com>
To: Vivien Malerba <vmalerba <at> gmail.com>
Cc: 12540 <at> debbugs.gnu.org
Subject: Re: bug#12540: Usage of srcdir when valac is generating a header file
Date: Mon, 1 Oct 2012 09:41:21 -0400

On 2012-09-29 19:32 +0200, Vivien Malerba wrote:
> I'm working on the Libgda project, which includes Vala source code. I use
> the Autotools to generate the Makefiles and I've noticed that during the
> conversion of vala code to C an H code a .stamp file is generated (from
> what I understand, that timestamped file is then a dependency for all the
> Vala files' conversion). The Automake's code to make that happen is:
> foreach my $vala_file (@vala_sources)
[...]
> You can see that the .stamp file is generated in the $(srcdir) directory
> instead of $(builddir), which breaks the rule when building out of sources.
> My suggestion is to replace $(srcdir) with $(builddir) (this timestamp file
> is also a build dependency for each vala file, so there is more code
> impacted than the snippet above).

Disclaimer: I have never used Vala.

I think these generated files are intended to be included in the
distribution.  Automake takes the approach of putting generated and
distributed files in srcdir.  The reason for this is that things can
get really hairy when generated files are built in builddir, essentially
because of the following scenario (for the following, we will say that
foo.h is distributed and generated from foo.vala):

 (1) user unpacks tarball, foo.h is unpacked to srcdir.
 (2) user does a VPATH build of the package.
 (3) user edits foo.vala, causing the foo.h in srcdir to be out of date.
 (4) user does an incremental VPATH build of the package, generating
     foo.h in the builddir.

Now, we have an environment with an up-to-date version of foo.h in the
builddir and an out-of-date foo.h in the srcdir.  This is not per se a
problem, but it is very tricky to get right and a bunch of Automake's
built-in behaviours (such as its automatic dependency tracking for C
programs) get it wrong.

This particular problem can be avoided by putting such generated files
in the srcdir, so that distributed versions get overwritten.  This is
the approach taken by Automake.

Cheers,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

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

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Nick Bowler <nbowler <at> elliptictech.com>
Cc: 12540 <at> debbugs.gnu.org, Vivien Malerba <vmalerba <at> gmail.com>
Subject: Re: bug#12540: Usage of srcdir when valac is generating a header file
Date: Tue, 02 Oct 2012 16:24:40 +0200

Thanks Nick for chiming in.  Your explanation is basically right:
Automake ought to place generated-but-distributed files in the
source directory rather than in the build directory, for two major
reasons:

  1. as you've noted, putting such files in builddir could cause
     inconsistencies in general, and sometimes weird bugs in the
     automatic dependency tracking; see also a report from Akim:
     <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10852>

  2. the distributed files should not be modified nor regenerated
     by a "make all" issued from the builddir of an extracted
     tarball (otherwise, what is the point of distributing them
     in the first place?); having such files in the srcdir allows
     "make distcheck" to catch and report such an inconsistency
     (because the distcheck runs with the srcdir set to readonly,
     so that any attempt to modify files in there will lead to a
     error).

Thus I'm closing this ticket as "Won't Fix".  Anyone who has doubts,
questions or objections is however free (actually encouraged!) to
continue the discussion here.

Regards,
  Stefano

Previous Next

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