Jonathan Nieder: > Hi! > > Niels Thykier wrote: > >> [...] >> >> Notely, this trickery prevents you from hacking on the upstream parts >> and use "dpkg-buildpackage -b -nc -uc -us" to reduce the build times >> for subsequent builds. You would have to add some rm -f calls to >> delete "internal debhelper state files" as well between each >> dpkg-buildpackage call. > > The ideal is to have dependencies correctly set so that if something > changes, the build system knows exactly what needs to be rebuilt. Is > that achieveable in the debhelper context? > > Summary: I don't have a strong opinion about what policy should say to > do with poorly-designed makefiles, but let's make sure debhelper > doesn't enter that category. > > Thanks, > Jonathan >
As I see it, there is no way for debhelper to sanely determine whether something should be rebuild or not without just rerunning that part. debhelper cannot see "inside" the upstream build system. If you modify a .c file, debhelper won't notice and will currently just skip the entire build. Alternatively, debhelper will have to invoke the build system and rely on it to not be flawed. AFAICT, the current practise recommended by policy have the same issue (assuming you implement the stamp file or touch the "build" file). Thanks, ~Niels
