Re: revision control info in generated files

[Steffen Dettmer]

On Mon, Apr 12, 2010 at 4:16 PM, Jef Driesen <address@hidden> wrote:
>
> On 12/04/10 15:58, Peter Johansson wrote:
> >
> > Jef Driesen wrote:
> > >
> > > On 12/04/10 14:59, Peter Johansson wrote:
> > > >
> > > > Also, I would try avoid distributing `version.h', but not
> > > > sure how to do that from top of my head.
> > >
> > > Why would you not distribute it?
> > >
> > Well, it's a matter of taste, but I see no real reason to
> > include it in the tarball.

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).
(config.h also isn't included in the tarball.)

> > Yeah, but you don't need autotools to generate `version.h'. You only
> > need make, `version.h.in', and `version' of which the two latter are
> > already included in the distribution, right?
>
> True, but make, sed, etc are usually also not available in a
> msvc environment.

What is `your' MSVC environment?
(`ours' does have make, sed etc, for example, because cygwin or
MSYS is needed)

Do you mean you want to build with the MSVC IDE, i.e. not using
make but the built-in magic?
Then you still need some sed or alike to generate the .DSP files
(if you distribute them as well instead of the rules to generate
them, no one can add files or change compiler options, because
they are included in the DSP files).
I think this is in deep contrast to the intention of an automake
src dist (possible, but not recommended, complex and inviting
issues).

> I maintain an msvc project file as a convenience for windows
> developers (I use a mingw cross compiler myself), and there the
> generated files are referenced directly. So if they are missing
> building fails.

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?

> Generating files in a msvc is possible with custom build rules,
> but it's tricky.

our packages build with make calling CL.EXE (needing MSYS) and
beside generating the autogen source and the binary files, DSP
files are generated, thus afterwards allowing to use the IDE e.g.
for debugging. Even recompilation works (because CFLAGS and
friends are written to DSP files),
BUT
there are limitations and surprises, so I'd not recommend to do
so. make with CL.EXE works fine, but IDE not. You already
mentioned issues with fulfilling the depenencies of autogen
sources (IMHO not well [or not at all] supported by MSVC).
In short, all this is a not really working hack generating an
illusion that MSVC would work, but in fact there are just parts
that `accidently' work.

You do not need IDE, DSP files and IDE complilation because of
debugging; MSVC debugger works both when CL.EXE was called from
MSVC but also when called from make (here, we often compile under
linux with CL.EXE, because this is fast when you have a lot of
autogen sources, but then debug on native windows, because it is
much faster to run MSVC on win). You may have to manually browse
for the first source file (the others are found automatically by
the compiled-in relative path names).

> 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 :)).
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.

oki,

Steffen