On 10/1/07, Ian Jackson <[EMAIL PROTECTED]> wrote:
> David Anderson writes ("Re: Packaging a library that requires cross-compiled
> code"):
> > This provides a way to build the entire package, using only
> > debian-provided packages, with a 'caching' functionality to avoid
> > having to rebuild a toolchain if a previous version of the package is
> > installed.
>
> I saw you were having some trouble with that. I'm afraid I can't
> offer much beyond sympathy. It's unfortunate, but you're just
> tackling a difficult problem.
No worries, the folks on #debian-python have helped me figure out something.
> A better approach would be to compare the built binary blob and die if
> it's not identical to the upstream one. Obviously there would be some
> kind of override - easiest perhaps just to remove the existing binary
> blob.
>
> That means that any accidental breakage to the building machinery will
> be spotted and fixed, but users are still able to change it. You'd
> want to leave a comment in the source file warning someone who edits
> it that they have to hit the check over the head as well.
I'm not sure what you mean by detecting accidental breakage to the
build machinery, but that means building a full cross-compiler each
time the package is rebuilt. Currently, we have a set of rules that
use the upstream blob by default, but enable a full rebuild (including
cross-compiler) when a DEB_BUILD_OPTIONS flag is passed.
My objective here is simply to avoid building gcc for a 50k python
package. My only interest is taking unnecessary load off all the stuff
and machines that will be building my package :-). It seems to me that
this solution is good, since it does enable users to manually rebuild
everything if they really want to, but makes package construction in
the general case nice and fast, as a platform independent python
package should be.
- Dave
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
