Implementation-Agnostic Support for Alternative Compilers: ccache, distcc, etc.

Bug #182942 reported by Matt T. Proud
4
Affects Status Importance Assigned to Milestone
devscripts (Debian)
Fix Released
Unknown
devscripts (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

Binary package hint: devscripts

I have been using debuild for quite a while now, mainly because I know
that one of its goals is to sanitize the build environment. In any
case, I have interest in having it support a ccache or distcc
environment as elegantly as possible. What I have done here is provide
an additional CLI option that allows the user to prepend another
search location to the sanitized ${PATH}. Why I have chosen this route
is that it allows the packager to bypass a standard suite of compilers
in ${PATH} in favor of aliases, bootstrappers, job distributers, or
whatever else anyone can imagine. It's pretty implementation-agnostic.

I see this approach to being somewhat cleaner than providing explicit
support for ccache or distcc in debuild, as not doing this would
require debuild henceforth to follow ccache or distcc's environment
variable configuration rules. I'm sure none of you want to track the
specifics of their implementation. Plus, this is better than
explicitly overriding the ${PATH}, as one can do now to achieve this,
because this does not require the end-user to constantly track
debuild's implementation nor ${PATH} rules as the Linux FHS changes
over time.

What are your thoughts?

I've attached a patch that I made. And---yes---the patch includes
modifications to the manual pages. ;-) I also submitted an updated package to REVU, but I'm not confident that my GPG is properly registered.

Revision history for this message
Matt T. Proud (matttproud-google) wrote :
Revision history for this message
Matt T. Proud (matttproud-google) wrote :

Resubmission due to browser crashing during POST. :-/

Revision history for this message
Matt T. Proud (matttproud-google) wrote :

I submitted this upstream to Debian: BTS #460719.

It'd be nice to get this incorporated before the forthcoming code freeze. I will work with my coworkers who are Debian maintainers about seeing if we can get this pushed into Debian, too.

Revision history for this message
Daniel Holbach (dholbach) wrote :

This patch is different from the one you sent to Debian. Does it contain bits of the SVN checkout? If so, it'd be nice to have changelog entries (if available upstream).

Changed in devscripts:
status: Unknown → New
Revision history for this message
Matt T. Proud (matttproud-google) wrote :

Daniel,

You are correct: It does contains SVN artifacts. I had made a checkout of the TRUNK version and applied the patch I made for Ubuntu Hardy against it and submitted it to Debian's BTS.

The actual debuild utility and manual page have not changed between the latest Hardy source package and SVN TRUNK. The only thing that has has been the changelog.

I am curious---what do you mean by ``If so, it'd be nice to have changelog entries (if available upstream)?''

Let me know.

Cheers,

Matt

Revision history for this message
Daniel Holbach (dholbach) wrote :

The only bit in the patch concerning the changelog is:

diff -Nru devscripts-2.10.11ubuntu3/debian/changelog devscripts-2.10.11ubuntu4/debian/changelog
--- devscripts-2.10.11ubuntu3/debian/changelog 2008-01-06 02:47:27.000000000 -0800
+++ devscripts-2.10.11ubuntu4/debian/changelog 2008-01-14 10:30:01.000000000 -0800
@@ -1,3 +1,11 @@
+devscripts (2.10.11ubuntu4) hardy; urgency=low
+
+ * Patch debuild to allow one to prepend the sanitized PATH in an
+ implementation-agonstic way to support alternative compilers and
+ build chains such as ccache and distcc.
+
+ -- Matt T. Proud <email address hidden> Mon, 14 Jan 2008 10:27:24 -0800
+
 devscripts (2.10.11ubuntu3) hardy; urgency=low

   [ Terence Simpson ]

It does not mention the SVN artifacts.

Revision history for this message
Matt T. Proud (matttproud-google) wrote :

Daniel,

What I did was make two patches: One of them was purely a debdiff against the original Hardy source package; whereas the other was a SVN diff against the code in Debian's VCS. The first debdiff has been submitted here and the second directly to Debian. I did this because I would like to see the feature implemented, and I was uncertain as to which project would implement it first.

That would explain the diverging changelog entries.

The debdiff one, of course, does not include SVN artifacts, since the source package's archive did not include them.

This is the header from the SVN version:

Index: debian/changelog
===================================================================
--- debian/changelog (revision 902)
+++ debian/changelog (working copy)

Further divergences:
Hardy source package version: 2.10.11ubuntu3 (Upstream: 2.10.11)
SVN TRUNK version: 2.10.14
Number of entries between the two versions that have occurred: Three.

Maybe I am not understanding what you are asking, but I guess that I am confused as to what you are asking for that's not already available in SVN or the source package itself. Most of the time when submitting patches to Launchpad, people prefer receiving debdiffs instead of VCS diffs. That's why I submitted this patch as I did. Am I wrong?

Revision history for this message
Daniel Holbach (dholbach) wrote :

OK, then it's all good. Nevermind.

Revision history for this message
Matthias Klose (doko) wrote :

why a new option, if

  PATH=/opt/foo/bin:$PATH debuild ...

works as well?

Changed in devscripts:
status: New → Incomplete
Changed in devscripts:
status: New → Fix Committed
Changed in devscripts:
status: Fix Committed → Fix Released
Revision history for this message
Adam D. Barratt (adam-barratt) wrote :

Matthias Klose wrote on 2008-02-08

> why a new option, if
> PATH=/opt/foo/bin:$PATH debuild ...
> works as well?

That won't work unless one uses --preserve-env=PATH. The new option also allows one to have a "dirty" path in the build environment and not have to worry about that by letting debuild sanitise it and then add the new directory

Revision history for this message
Adam D. Barratt (adam-barratt) wrote :

Looking at the versions available, this should be fixed already in intrepid and hardy-backports, as it was included in the Debian package in 2.10.20

Revision history for this message
Bryce Harrington (bryce) wrote :

Fixed already in Intrepid... we're carrying version 2.10.26 now

Changed in devscripts:
status: Incomplete → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.