On Mon, Apr 12, 2010 at 4:16 PM, Jef Driesen <jefdrie...@hotmail.com> 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
