mesa3d-dev

[Mesa3d-dev] Separate demos repository

[Eric A. <er...@an...>]

People that hang out on IRC have probably heard about my build system
work.  One of the first steps I've been working on finishing is
splitting out the demos repository.  We're currently distributing the
Mesa progs/ separately from the main Mesa distribution, and most people
aren't installing it, so from a distribution perspective it doesn't make
sense to be in the same repository.  On the other hand, for driver
developers that are having to make clean on a regular basis, wiping out
the programs (if you even use them) doesn't help since the programs
aren't really changing.  And if they are, when you're bisecting around
trying an app, you don't want the app changing at the same time.

So, I've made a branch in my Mesa repository for a split of the progs/
From Mesa.

git://people.freedesktop.org/~anholt/mesa on the mesa-demos branch

Open issues:

Right now they don't install in general, but it would be easy to change
if people are interested in a package that does.  I've tested a bunch of
them in tree and they seem fine.

I've only tested the build on Linux with GL.  The GLES stuff needs to
get hooked up (I don't see a GLES implementation to test against or I
would have).

I don't know what to do about the progs/gallium.  progs/gallium/unit
looks like it should probably live in the Mesa tree next to the code
that it's unit testing.  progs/gallium/python/ though?

None of the GLEW or GLUT is brought along with the apps.  It looks to me
like all OSes should have libGLEW and libfreeglut reasonably available.

I'm not sure if we want the repository to contain all of previous Mesa
history.  Right now that history costs 145MB on disk for a deep
checkout.  If that's a problem for people, we could use the same tool
that xcb did whose name I forget to to construct a history of just
progs/

Where to go from here:

If there isn't violent objection to this, I want to get this into place
in /git/mesa/demos in a couple of weeks, and then remove those
components from the main Mesa repository, plus the things that are only
in there because progs depend on them (GLUT, GLEW).

Re: [Mesa3d-dev] Separate demos repository

[tom f. <tf...@al...>]

Eric Anholt <er...@an...> writes:
[snip -- move demos to separate repo]

*shrug*, doesn't affect me much, but sounds like a good idea.

> I'm not sure if we want the repository to contain all of previous
> Mesa history.  Right now that history costs 145MB on disk for a deep
> checkout.  If that's a problem for people, we could use the same tool
> that xcb did whose name I forget to to construct a history of just
> progs/

You're thinking of git filter-branch.  It can, indeed, drastically
reduce repository size.  Probably this:

  git filter-branch --subdirectory-filter progs -- --all

is what you want.  Might want to delete (some?) branches and tags
afterwards too.

HTH,

-tom

Re: [Mesa3d-dev] Separate demos repository

[Brian P. <br...@vm...>]

Eric Anholt wrote:
> People that hang out on IRC have probably heard about my build system
> work.  One of the first steps I've been working on finishing is
> splitting out the demos repository.  We're currently distributing the
> Mesa progs/ separately from the main Mesa distribution, and most people
> aren't installing it, so from a distribution perspective it doesn't make
> sense to be in the same repository.  On the other hand, for driver
> developers that are having to make clean on a regular basis, wiping out
> the programs (if you even use them) doesn't help since the programs
> aren't really changing.  And if they are, when you're bisecting around
> trying an app, you don't want the app changing at the same time.
> 
> So, I've made a branch in my Mesa repository for a split of the progs/
>>From Mesa.
> 
> git://people.freedesktop.org/~anholt/mesa on the mesa-demos branch
> 
> Open issues:
> 
> Right now they don't install in general, but it would be easy to change
> if people are interested in a package that does.  I've tested a bunch of
> them in tree and they seem fine.
> 
> I've only tested the build on Linux with GL.  The GLES stuff needs to
> get hooked up (I don't see a GLES implementation to test against or I
> would have).
> 
> I don't know what to do about the progs/gallium.  progs/gallium/unit
> looks like it should probably live in the Mesa tree next to the code
> that it's unit testing.  progs/gallium/python/ though?
> 
> None of the GLEW or GLUT is brought along with the apps.  It looks to me
> like all OSes should have libGLEW and libfreeglut reasonably available.
> 
> I'm not sure if we want the repository to contain all of previous Mesa
> history.  Right now that history costs 145MB on disk for a deep
> checkout.  If that's a problem for people, we could use the same tool
> that xcb did whose name I forget to to construct a history of just
> progs/
> 
> Where to go from here:
> 
> If there isn't violent objection to this, I want to get this into place
> in /git/mesa/demos in a couple of weeks, and then remove those
> components from the main Mesa repository, plus the things that are only
> in there because progs depend on them (GLUT, GLEW).

In general I'm ok with putting the demos in a separate repo.

I probably won't have time to look at your branch for a week or two 
though.

I definitely want to keep the Mesa/Kilgard version of GLUT around. 
freeglut behaves differently than Mesa's GLUT in a few ways.  I still 
don't trust the former as much as the later.  It only takes a 
miniscule amount of space and builds in 2-3 seconds.

We need to go through the progs/tests and see which are unit tests 
better suited to living with Mesa rather than a separate demo repo.

Maybe Chia-I Wu can help out with the OpenGL ES / Open VG programs.

I'd appreciate it if you'd hold off on any changes for a little while 
longer.  Thanks.

-Brian

Re: [Mesa3d-dev] Separate demos repository

[José F. <jfo...@vm...>]

On Wed, 2010-03-24 at 15:11 -0700, Eric Anholt wrote:
> People that hang out on IRC have probably heard about my build system
> work.  One of the first steps I've been working on finishing is
> splitting out the demos repository.  We're currently distributing the
> Mesa progs/ separately from the main Mesa distribution, and most people
> aren't installing it, so from a distribution perspective it doesn't make
> sense to be in the same repository.  On the other hand, for driver
> developers that are having to make clean on a regular basis, wiping out
> the programs (if you even use them) doesn't help since the programs
> aren't really changing.  And if they are, when you're bisecting around
> trying an app, you don't want the app changing at the same time.

I also think that separating the demos/tests is a sensible thing to do.
One doesn't (re)build tests as often as the rest of the drivers, and GL,
GL ES, VG, are all stable interfaces.

> So, I've made a branch in my Mesa repository for a split of the progs/
> From Mesa.
> 
> git://people.freedesktop.org/~anholt/mesa on the mesa-demos branch
>
> Open issues:
> 
> Right now they don't install in general, but it would be easy to change
> if people are interested in a package that does.  I've tested a bunch of
> them in tree and they seem fine.
> 
> I've only tested the build on Linux with GL.  The GLES stuff needs to
> get hooked up (I don't see a GLES implementation to test against or I
> would have).
> 
> I don't know what to do about the progs/gallium.  progs/gallium/unit
> looks like it should probably live in the Mesa tree next to the code
> that it's unit testing.  progs/gallium/python/ though?

Yes, all subdirs inside progs/gallium essentially have tests for gallium
interfaces, so its contents should move to src/gallium/tests .

> None of the GLEW or GLUT is brought along with the apps.  It looks to me
> like all OSes should have libGLEW and libfreeglut reasonably available.

> I'm not sure if we want the repository to contain all of previous Mesa
> history.  Right now that history costs 145MB on disk for a deep
> checkout.  If that's a problem for people, we could use the same tool
> that xcb did whose name I forget to to construct a history of just
> progs/

Probably "git filter-branch".

Jose