[Mesa-dev] talloc (Was: Merge criteria for glsl2 branch)

José Fonseca jfonseca at vmware.com
Thu Aug 12 04:24:01 PDT 2010

On Thu, 2010-08-12 at 04:10 -0700, Dave Airlie wrote:
> On Thu, Aug 12, 2010 at 9:00 PM, José Fonseca <jfonseca at vmware.com> wrote:
> > On Wed, 2010-08-11 at 17:40 -0700, Dave Airlie wrote:
> >> On Thu, Aug 12, 2010 at 9:42 AM, José Fonseca <jfonseca at vmware.com> wrote:
> >> > On Wed, 2010-08-11 at 12:52 -0700, Ian Romanick wrote:
> >> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> >> Hash: SHA1
> >> >>
> >> >> José Fonseca wrote:
> >> >> > Could then Aras Pranckevicius's talloc port to windows be merged into
> >> >> > glsl2 branch before glsl2 is merged into master?
> >> >>
> >> >> I think we learned our lesson with GLEW.  Trying to keep a copy of an
> >> >> external dependency in our tree only leads to sadness.  I have no
> >> >> intention to repeat that mistake.
> >> >
> >> > Having the GLEW source was quite useful for windows. I guess the lesson
> >> > would not be not ship source, but only build it if necessary. If talloc
> >> > source is not needed for Linux then we can just build it when absent.
> >> > You can even ignore it from automake.
> >>
> >> Can't you guys setup a separate windows deps repo? that you gather all
> >> the prereqs for building on Windows
> >> in one place and recommend people check it out before mesa?
> >
> > Unfortunately there is no standard way to install headers and libraries
> > in windows -- there's no /usr/include or /usr/lib, and there might be
> > multiple MSVC versions. There are ways around it, sure. Might be worth
> > giving a shot eventually.
> >
> >> Really optimising for the wrong bunch of people here by dragging this
> >> stuff into mesa git.
> >
> > Many projects do this: they include the source of other projects, to
> > make it easier to build without having to build all dependencies.
> We spend a lot of time unbundling stuff in projects because its a
> really bad model, esp for things like security updates. What happens
> if the version of talloc we ship ends up a with a problem and nobody
> is tracking upstream and notices the issue, this doesn't scale, at
> some point you have to draw a line, again you have 0 experience with
> packaging mesa for its main purpose and use case, so excuse me if I
> dismiss the rest of your pithy comments.

Good points, but I still don't see how my proposal of not building them
on linux does not address them.

> talloc is a bit different than glew I can accept that, since glew
> isn't a mesa build req, but should we start shipping bison, flex etc,
> is it only build reqs or runtime reqs? 

no. but that's why we commit the bison and flex output in the repository
for example.

> it would be nice instead of
> being an ass you perhaps helped draw up some guidelines with all the
> other Windows folks.

my feelings exactly when I read the last sentence of your previous

in a hindsight perhaps you meant distributions + end users vs
developers, but I understood it as windows developers == bunch of wrong
people, and linux developers == bunch of good people. who cares. there
isn't "wrong bunch of people" regardless.


More information about the mesa-dev mailing list