Hi, (note: I excluded the launchpad bug because this more of a general comment) On 13/02/12 00:26, Diego Biurrun wrote: > True, but you should also not rearrange things w/o need to do so. > I'll try to update HACKING this week, there's a bunch of stuff I > wanted to add in there. > .... >> > I didn't know there are other testing methods like 'make alltests' >> > and autobuilder, but before every commit I make sure the code pass >> > the 'make check'. from now on I will also check 'make alltests'. >> > Could you give some hints about how to use the autobuilder you >> > mentioned? > > Who is mentoring you over in Finland and why are they not giving you > appropriate hints? :) > > The autobuilder is the script tools/hipl_autobuild.sh, it should work > if you run it directly. > > You could also just read Makefile.am to find out about available targets. > You could also read the output of configure to see which options are > enabled or not. Also look at 'configure --help' for available options. actually, I mistakenly assumed that alltests and hipl_autobuild.sh were already. If you improve the HACKING document, a clear check list of things to check before commit would be highly appreciated (including a manual "bzr diff" inspection for extra sanity and checking that up-to-date hooks are in place). Things are a bit scattered now. Btw, hipl_autobuild.sh is still semi-automated and a bit tedious to set up. It is designed to be run from crontab rather than effortless execution from the command line. IMHO, the best way to improve would be to integrate this somehow into "make alltests". A better than nothing alternative is to document copy-paste-instructions to HACKING explaining "what do I need to execute from the command line" to get it working instead forcing all developers to read the source code of the script and set it up using the trial-and-error method.