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 <p...@debian.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 That's right. > 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. > -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1329875390.8806.4.camel@davidMac
