Re: [Sbcl-devel] SBCL 0.8.0 build failures on FreeBSD

[Christophe R. <cs...@ca...>]

Dag-Erling Smorgrav <de...@of...> writes:

> Christophe Rhodes <cs...@ca...> writes:
>> Right.  So if we included a Win32 interface, would you want to package
>> that part for FreeBSD too?
>
> No, deciding to leave out a part because it's not supported on this
> platform is OK, but if something that *is* supported suddenly fails to
> build, I want the entire build to fail.

So is the solution not for you to test for the existence of the
relevant test-passed files in the contrib/ subdirectories, where you
define which parts are supported, and if said test-passed files do not
exist, throwing an error?  This wouldn't be a great solution for
mainline development, but if you're working solely as a packager, does
that do what you want?

>> Maybe it would help to explain what the requirements are for your
>> packaging system?  I personally have no experience at all of it.
>
> It's not so different from other package systems - the build needs to
> be 100% reproducible.  If something on the user's machine makes part
> of the build fail, I want the bug report from that user to say "the
> build failed at this point with this error message", not "I installed
> SBCL two weeks ago and I just found out that three files are missing".

An alternative to the above might be to consider
sbcl-the-compiler-and-runtime-environment and sbcl's contrib as
coupled but separate packages, the latter depending on the former?  I
suppose you'd still have to decide what was "supported" and what was
not... how do you deal with projects that deliberately remove
functionality (such as bits of GNOME recently, say)?  Do you make new
packages for the new releases?

Cheers,

Christophe
-- 
http://www-jcsu.jesus.cam.ac.uk/~csr21/       +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%")    (pprint #36rJesusCollegeCambridge)