How to debuild (Debian) Apache without it performing a clean












3














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.









share|improve this question





























    3














    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.









    share|improve this question



























      3












      3








      3







      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.









      share|improve this question















      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.






      debian apache-httpd compiling raspbian c






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Aug 25 '18 at 21:41









      Rui F Ribeiro

      39.2k1479130




      39.2k1479130










      asked Aug 20 '16 at 1:22









      Peter RyanPeter Ryan

      5017




      5017






















          3 Answers
          3






          active

          oldest

          votes


















          6














          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.






          share|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



















          4














          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



          override_dh_clean:


          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.






          share|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



















          0














          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")"
          override CPPFLAGS += -DBUILD_DATE=""$(BUILD_DATE)""

          %:
          dh $@

          override_dh_auto_build:
          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.






          share|improve this answer





















            Your Answer








            StackExchange.ready(function() {
            var channelOptions = {
            tags: "".split(" "),
            id: "106"
            };
            initTagRenderer("".split(" "), "".split(" "), channelOptions);

            StackExchange.using("externalEditor", function() {
            // Have to fire editor after snippets, if snippets enabled
            if (StackExchange.settings.snippets.snippetsEnabled) {
            StackExchange.using("snippets", function() {
            createEditor();
            });
            }
            else {
            createEditor();
            }
            });

            function createEditor() {
            StackExchange.prepareEditor({
            heartbeatType: 'answer',
            autoActivateHeartbeat: false,
            convertImagesToLinks: false,
            noModals: true,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: null,
            bindNavPrevention: true,
            postfix: "",
            imageUploader: {
            brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
            contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
            allowUrls: true
            },
            onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            });


            }
            });














            draft saved

            draft discarded


















            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f304590%2fhow-to-debuild-debian-apache-without-it-performing-a-clean%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown

























            3 Answers
            3






            active

            oldest

            votes








            3 Answers
            3






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes









            6














            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.






            share|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
















            6














            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.






            share|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














            6












            6








            6






            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.






            share|improve this answer














            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.







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Mar 23 '17 at 21:14

























            answered Aug 21 '16 at 18:51









            Ferenc WágnerFerenc Wágner

            2,959920




            2,959920












            • 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


















            • 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
















            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




            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




            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




            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




            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




            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













            4














            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



            override_dh_clean:


            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.






            share|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
















            4














            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



            override_dh_clean:


            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.






            share|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














            4












            4








            4






            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



            override_dh_clean:


            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.






            share|improve this answer














            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



            override_dh_clean:


            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.







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited 31 mins ago









            Stephen Kitt

            165k24366446




            165k24366446










            answered Aug 20 '16 at 18:58









            LivinglifebackLivinglifeback

            1,104713




            1,104713












            • 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


















            • 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
















            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




            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




            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











            0














            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")"
            override CPPFLAGS += -DBUILD_DATE=""$(BUILD_DATE)""

            %:
            dh $@

            override_dh_auto_build:
            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.






            share|improve this answer


























              0














              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")"
              override CPPFLAGS += -DBUILD_DATE=""$(BUILD_DATE)""

              %:
              dh $@

              override_dh_auto_build:
              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.






              share|improve this answer
























                0












                0








                0






                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")"
                override CPPFLAGS += -DBUILD_DATE=""$(BUILD_DATE)""

                %:
                dh $@

                override_dh_auto_build:
                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.






                share|improve this answer












                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")"
                override CPPFLAGS += -DBUILD_DATE=""$(BUILD_DATE)""

                %:
                dh $@

                override_dh_auto_build:
                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.







                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered Dec 24 '18 at 3:08









                sdaausdaau

                2,65263149




                2,65263149






























                    draft saved

                    draft discarded




















































                    Thanks for contributing an answer to Unix & Linux Stack Exchange!


                    • Please be sure to answer the question. Provide details and share your research!

                    But avoid



                    • Asking for help, clarification, or responding to other answers.

                    • Making statements based on opinion; back them up with references or personal experience.


                    To learn more, see our tips on writing great answers.





                    Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


                    Please pay close attention to the following guidance:


                    • Please be sure to answer the question. Provide details and share your research!

                    But avoid



                    • Asking for help, clarification, or responding to other answers.

                    • Making statements based on opinion; back them up with references or personal experience.


                    To learn more, see our tips on writing great answers.




                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function () {
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f304590%2fhow-to-debuild-debian-apache-without-it-performing-a-clean%23new-answer', 'question_page');
                    }
                    );

                    Post as a guest















                    Required, but never shown





















































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown

































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown







                    Popular posts from this blog

                    CARDNET

                    Boot-repair Failure: Unable to locate package grub-common:i386

                    濃尾地震