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