I am trying to edit an Apache module on Debian (strictly, I'm doing this on Raspbian Jessie-Lite), and am broadly following the Debian build instructions:

$ mkdir -p ~/src/debian; cd ~/src/debian
$ apt-get source apache2-bin
$ cd apache2-2.4.10
$ debuild -b -uc -us

And the build process takes roughly one and a half hours on an olde original Pi. Which is fine. Once! But I believe the build process is performing a make clean and so after a minor edit of a single mod_*.c file, it wants to rebuild the entire thing, which is kind of slowing down my development!

I have tried adding -dc to the debuild command, but then it didn't build anything. I even tried deleting the target mod_*.so file to "encourage" it into rebuilding it, but still no!

UPDATE 2016-08-21: Adding -nc to the debuild command does not cause modules to be recompiled. Here's the output from that command:

$ debuild -b -uc -us -nc
 dpkg-buildpackage -rfakeroot -D -us -uc -b -nc
dpkg-buildpackage: source package apache2
dpkg-buildpackage: source version 2.4.10-10+deb8u5
dpkg-buildpackage: source distribution jessie-security
dpkg-buildpackage: source changed by Salvatore Bonaccorso <carnil@debian.org>
 dpkg-source --before-build apache2-2.4.10
dpkg-buildpackage: host architecture armhf
 debian/rules build
dh build --parallel --with autotools_dev
 fakeroot debian/rules binary
dh binary --parallel --with autotools_dev
 dpkg-genchanges -b >../apache2_2.4.10-10+deb8u5_armhf.changes
dpkg-genchanges: binary-only upload (no source code included)
 dpkg-source --after-build apache2-2.4.10
dpkg-buildpackage: binary-only upload (no source included)
Now running lintian...
N: 16 tags overridden (1 error, 4 warnings, 11 info)
Finished running lintian.

Add the -nc option to your debuild command line. This may expose problems in the build system or the packaging though, so be prepared. But for small fixes it usually works fine.

However, as the apache2 source package uses debhelper (like many other packages), this alone is not enough, because debhelper also keeps its own journal of completed steps in separate log files for each binary package. These can be removed entirely by dh_clean. But to get debhelper redo no more than the necessary work, truncate only the relevant one by

sed -i '/^dh_auto_build$/Q' debian/apache2-bin.debhelper.log

before running debuild -nc.

|improve this answer|||||
  • Thank you too for your reply! It didn't work though! :D In fact, the output, and the duration taken were identical to removing the clean bits from debian/rules. I've updated the question with the output from debuild with -nc in case it helps. – Peter Ryan Aug 21 '16 at 23:00
  • What happens if you invoke plain make in the top level source directory after making your code changes? If that rebuilds what you need, try debuild -nc after that. – Ferenc Wágner Aug 24 '16 at 8:16
  • make does do something; it compiles bits in [top-level-source]/modules/mappers/.libs/ but the .so file in there is larger than the .so file that is installed (9.4K vs 35K). However, the file that a full debuild builds ends up in [top-level-source]/debian/apache2-bin/usr/lib/apache2/modules/. So my doing a make followed by debuild -nc didn't result in a file I could install. – Peter Ryan Aug 25 '16 at 22:13
  • I'm might be saying what you already know, but it seems to me that there's the Apache distribution, along with all it's make files, and then there's the Debian patches and its makes files... and the two are separate? And I'm also wondering if the Debian stuff doesn't just recompile everything because easier/safer to do so! Maybe?! – Peter Ryan Aug 25 '16 at 22:16
  • The size difference is probably the result of stripping. Anyway, this in encouraging. Now, run sed -i '/^dh_auto_build$/Q' debian/apache2-bin.debhelper.log (supposing your changes concern the apache2-bin binary package). Then run debuild -nc. – Ferenc Wágner Aug 26 '16 at 7:17

Inside the debian directory there's a rules file. It's a essentially a make file. If you remove all the directives about cleaning and then add


And put nothing in it no cleaning will happen (at all). Be careful though this might cause build problems, not likely but might. Another alternative is to not change anything and use the -j option to do a parallel build. Not sure the advantage that'd give on a raspberry pi.

Rules file should look like this.

|improve this answer|||||
  • Thanks for your reply! I've tried editing debian/rules, but whilst it is much quicker (less than 7 minutes), it doesn't re-compile the module I've edited. – Peter Ryan Aug 21 '16 at 17:22
  • Having had a look around, there's a lot of .mk files in there too, but I'm utterly lost as to what calls what and when! – Peter Ryan Aug 21 '16 at 17:25

I had a similar problem; Scite debian package has in debian/rules:

BUILD_DATE="$(date --utc --date="@${SOURCE_DATE_EPOCH:-$(date +%s)}" "+%b %d %Y %T")"

        dh $@

        dh_auto_build --sourcedirectory=scintilla/gtk -- GTK3=1 $(BUILD_LUA)
        dh_auto_build --sourcedirectory=scite/gtk -- gnomeprefix=/usr GTK3=1 $(BUILD_LUA)

Essentially, override_dh_auto_build calls the make, which detects changed source files and rebuilds only changed ones. However, even if debian/rules sets BUILD_DATE, running:

fakeroot debian/rules -j$(nproc) override_dh_auto_build

... will fail at some cpp source files that use BUILD_DATE as a define. The solution is to explicitly specify this variable on the command line call:

fakeroot debian/rules -j$(nproc) CPPFLAGS+=-DBUILD_DATE="" override_dh_auto_build

... and then compilation passes (additional bonus is that a new .deb is not created, so you don't have to wait for that). Essentially, this helps to rerun just the rebuild process for changed files that gives you the .so/.exe, without packaging a .deb.

|improve this answer|||||

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.