Re: revision control info in generated files

[Peter Johansson]

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 Makefile.in, 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 configure.ac, both the .rc.in and .rc
> > > file are included in the tarball when I run make distcheck.
> >
> > An AC_CONFIG_FILES([xxx.rc.in]) does not lead to inclusion of
> > either xxx.rc.in nor xxx.rc (and how could it, maybe xxx.rc.in is
> > automatically generated from xxx.rc.in.in or whatever :)).
This is confusing.

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

http://sources.redhat.com/automake/automake.html#Basics-of-Distribution

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

configure.ac:3: required file `xxx.rc.in' not found

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

> > Usually, you'd add xxx.rc.in to EXTRA_DIST (and xxx.rc to
> > BUILT_SOURCES). Then you'd get xxx.rc.in 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 configure.ac. And the tarball contains 
> both the xxx.rc.in and xxx.rc file, but only the xxx.pc.in file.
>
> It seems that the xxx.pc.in 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.
Because:

"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 Makefile.am?

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


Cheers,
Peter

--
Peter Johansson

svndigest maintainer, http://dev.thep.lu.se/svndigest
yat maintainer,       http://dev.thep.lu.se/yat