[Top][All Lists]

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

Re: revision control info in generated files

From: Peter Johansson
Subject: Re: revision control info in generated files
Date: Tue, 13 Apr 2010 15:58:17 -0400
User-agent: Thunderbird (X11/20090105)

Seems like something went wrong with my previous post so here is another attempt.

Jef Driesen wrote:
On 13/04/10 11:33, Steffen Dettmer wrote:
I think including the generated source in the tarball is wrong
and can break things. First thing that will break is that you
will have one version.h in srcdir (from the tarball) and
optionally a second one in builddir (from config.status/make).

Sure, good point. That's why the make rule for distributed files should always be written in such a way that the file is re-generated in srcdir. See, for example, how the rules are for, configure, etc.
(config.h also isn't included in the tarball.)
Yeah, sure. Distributing files that depend on the system or on how configure is invoked would be simply wrong.

Good point. Although I don't understand why some generated files are distributed in my project, and others are not. See below.


Do you want to support the compiler CL.EXE (which is not needing
an msvc project file but can be run via make) or do you want to
support the integrated development environment Visual Studio
instead of using make?


I support the Visual Studio IDE, not the cl.exe compiler.

I'm well aware that there are limitations in what the IDE can do, but for many (most?) windows developers compiling is equivalent to loading the project into the IDE and compile the code from there. Even my own experience with the msvc compiler is limited to using the IDE :-(

What I want to avoid is that windows developers have to install msys (and similar tools) to be able to generate some files first. Anyone using msys is more likely to use the mingw anyway. I'm sure a mixed msys/msvc environment has it use, but I think it's more typical to have either msys/mingw or a pure msvc setup.

I just checked, and for a resource file (*.rc) in my project
that is generated from, both the and .rc
file are included in the tarball when I run make distcheck.

An AC_CONFIG_FILES([]) does not lead to inclusion of
either nor xxx.rc (and how could it, maybe is
automatically generated from or whatever :)).
This is confusing.

I suppose you mean AC_CONFIG_FILES([xxx.rc]) and that will result in `' being distributed.

Another note is that if you try to generate an input file for AC_CONFIG_FILE you must generate it early on, because autoconf check the existence of the file and if it doesn't exist at autoconf time it will complain with required file `' not found

which meansyou have to generate `' at latest at autoconf time.

Usually, you'd add to EXTRA_DIST (and xxx.rc to
BUILT_SOURCES). Then you'd get in src dist but xxx.rc
generated by configure and updated by make, working correctly
thanks to autoconf/automake.

This is strange. I generate both a resource file (xxx.rc) and pkg-config file (xxx.pc) from And the tarball contains both the and xxx.rc file, but only the file.

It seems that the is always distributed, even if I remove it from EXTRA_DIST. According to your explanation, it shouldn't be distributed in that case, but I have no idea why it's does go into the tarball.

"Also, files that are read by configure (i.e. the source files corresponding to the files specified in various Autoconf macros such as |AC_CONFIG_FILES| and siblings) are automatically distributed."

For the xxx.rc file, maybe the reason why it's distributed is because I have xxx_la_SOURCES += xxx.rc in my

exactly, so you could use 'nodist_xxx_la_SOURCES += xxx.rc'


Peter Johansson

svndigest maintainer,
yat maintainer,

reply via email to

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