Re: fastest hack-build-run iteration
On Tue, 2012-02-21 at 13:59 +0100, Adam Borowski wrote:
> On Tue, Feb 21, 2012 at 09:58:45AM +0100, Joachim Wiedorn wrote:
> > Paul Wise <firstname.lastname@example.org> wrote on 2012-02-21 09:28:
> > > On Tue, Feb 21, 2012 at 8:40 AM, David Roguin wrote:
> > >
> > > > I'm making some changes to the evolution package and every time I want
> > > > to test a tiny change I build a deb, install and run it. As you can
> > > > imagine that takes a lot of time.
> Are you testing changes to packaging or actual code? If the latter, I'd run
> the non-installed binary directly from the build dir. It probably expects
> support data but that's already installed (unless you changed that as well).
> If it's a library, you can LD_PRELOAD the new version.
That did it!
After the 'make' command I'm using dh_auto_install to generate the
debian/tmp dir and then use LD_PRELOAD with the .so I'm modifying (I
think if I just copy the .so It'll speed up things a little more)
> > > maint-guide used to recommend running ./debian/rules binary for that,
> > > not sure if it does now.
> > And use ccache for using compiling results for the next time.
> If the package's makefile is sane, ccache is not needed since unchanged
> files won't be recompiled. And evolution uses automake which produces sane
> makefiles (at least in this regard).
> Too bad, in this case, a no-change rebuild still takes 1/4 of time needed
> for a clean build. It seems it's mostly:
> 1. installing mo files
> 2. dh_shlibdeps
> 3. debhelper/dpkg-dev
> It doesn't seem to me you can avoid especially 2. and 3. easily.
> (And no, I'm not proposing to replace 3. with fine techniques in
> http://angband.pl/debian/pool/main/g/goodbye/goodbye_0.2-1.dsc ☺).
> If you weren't using cdbs, debhelper can speed up things quite a bit with
> --parallel[¹], especially for packages with multiple binaries like
> evolution. And hey, these days if you don't have multiple cores, your phone
> is aged.
That speeded up things a little, thanks for the tip!
> [¹]. You need to
> export DEB_BUILD_OPTIONS=parallel=`grep ^processor /proc/cpuinfo|wc -l`
> as well, but that's something which should have been the default everywhere
> but on buildds. Packages that are not marked as parallelizable won't be
> affected so it's a safe thing to do.