On Mon, Oct 26, 2015 at 05:05:49PM +0100, Andrea Bolognani wrote:
On Mon, 2015-10-26 at 16:25 +0100, Michal Privoznik wrote:
On 26.10.2015 16:03, Andrea Bolognani wrote:
Generate the HACKING file at dist time like we're already doing for NEWS, AUTHORS and ChangeLog.
The file shouldn't be tracked by git as it's not a source file but rather a generated one; because of this, it should also be generated in $(builddir) as opposed to $(top_srcdir).
Cheers.
Andrea Bolognani (4): HACKING: Generate inside the build directory HACKING: Remove generated copy HACKING: Add to ignore file HACKING: Include in EXTRA_DIST
.gitignore | 1 + HACKING | 1008 ----------------------------------------------- ------------ Makefile.am | 3 +- cfg.mk | 3 +- 4 files changed, 4 insertions(+), 1011 deletions(-) delete mode 100644 HACKING
Frankly, I'd like to keep HACKING in the git. I know it's a generated file, but the reasoning should be that a new contributor, who is about to make his first contribution will clone the repo and the first thing they should search for is Readme and HACKING files. I know that dealing with the file which is then again generated from another file, keeping them both in git may be counterintuitive, but I'd like to keep the file there.
We also have README-hacking which contains information that is arguably more vital to a first-time contributor, eg. how to bootstrap the development environment.
Successfully building libvirt (which should generate HACKING) is a prerequisite for making any changes to it anyway (except for translations). A large part of 'HACKING' is currently dealing with whitespace and brace rules, which are enforced by syntax-check. Moving them to a separate file (CodingStyle) or deleting them completely and pointing new contributors to running 'make syntax-check' with cppi installed would reduce the length of the file, thus making it more likely to be read completely.
Other possible ways to approach the problem:
* include a note in README-hacking telling the user to run 'make HACKING' to build the contributor guidelines
I vote for this option. Let's keep the essential information in README-hacking, and the information needed for larger patches and second-time contributors in HACKING. Jan