|
From: | Jef Driesen |
Subject: | Re: revision control info in generated files |
Date: | Wed, 28 Apr 2010 12:05:56 +0200 |
User-agent: | Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 |
On 12/04/2010 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 it's very useful that it gets distributed. Imagine someone downloads a tarball and wants to built it with the msvc compiler (which I support for my project). Since no files can be generated in that (non autotools) environment, that works fine *if* the generated files are distributed.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?
In case anyone is interested, I found how to avoid distribution of generated header and source files. Just prefix them with nodist_
nodist_foobar_HEADERS = version.h nodist_foobar_SOURCES = version.cOf course that will break my msvc project files, as I mentioned in one of my previous posts. But what if I could distribute these generated files under a different name? For instance distribute the generated "version.h" file as a "version.h.win32" file. That shouldn't cause any problems in an autotools setup, and for my msvc project file, I can provide a custom build rule to copy it back to a "version.h" file.
Is there a better way to do that compared to this: version.h.win32: version.h cp $< $@ EXTRA_DIST = version.h.win32
[Prev in Thread] | Current Thread | [Next in Thread] |