Re: [Mesa3d-dev] Gallium code reorganization

2008-02-14 Thread Keith Whitwell
Michel Dänzer wrote:
 On Thu, 2008-02-14 at 20:05 +0900, José Fonseca wrote:
 On 2/14/08, Keith Whitwell [EMAIL PROTECTED] wrote:
 José Fonseca wrote:
  
   1. Physically separate gallium source code from mesa code. This will be 
 the
   final layout:
  
   - src/mesa
   - src/gallium
 - state_tracker
   - ogl
   - ...


 I think the one thing I'd say is that the GL state tracker is really a
  part of Mesa -- it's effectively a Mesa driver which targets the Gallium
  interfaces rather than some piece of hardware.

  Given that the gallium interface is fairly water-tight (ie. you can't
  reach round it to some driver internals) compared to the Mesa driver
  interface which is basically just include all the mesa internal
  headers, I think it will become clear if you try and do this that the
  state_tracker will sit pretty uncomfortably anywhere other than inside
  mesa...
 So src/mesa/driver/state_tracker then?
 
 src/mesa/driver/gallium ?

The trouble with this is you now have two things in the stack which can 
be called 'the gallium driver', ie:

GL API
--
Core Mesa
--
Gallium Driver (formerly State Tracker)
--
Gallium API
--
Gallium Driver
--
Winsys, DRM, HW


I'd be happy to either leave this piece out of the proposed changes for 
now, or to move it to mesa/drivers/state_tracker.

Basically I think we have a clear idea what to do with the rest of the 
stack, probably we should just move ahead on that and either leave the 
Mesa state tracker alone or only make minimal changes to it.

Leaving it out of this round of changes doesn't mean that we can't 
move/rename it later -- because it's a part of mesa, changing it later 
won't break or affect any other Gallium clients.  It's really an 
internal matter for Mesa where that code lives  what it's called.

Keith


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [Mesa3d-dev] Gallium code reorganization

2008-02-13 Thread Daniel Stone
On Thu, Feb 14, 2008 at 03:38:45PM +0900, José Fonseca wrote:
 3. Using scons, enhance the build system to support all platforms we are 
 interested (i.e., linux and win32, atm), 

http://lwn.net/Articles/188693/

'There were major problems building KDE on non-Linux platforms with
SCons (e.g. on OS X); in general they felt it did not yet have a mature
configuration system.'

IOW, 'not autotools' is not a panacea for ultimate portability.

Cheers,
Daniel


signature.asc
Description: Digital signature
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [Mesa3d-dev] Gallium code reorganization

2008-02-13 Thread José Fonseca
On Thu, 2008-02-14 at 08:50 +0200, Daniel Stone wrote:
 On Thu, Feb 14, 2008 at 03:38:45PM +0900, José Fonseca wrote:
  3. Using scons, enhance the build system to support all platforms we are 
  interested (i.e., linux and win32, atm), 
 
 http://lwn.net/Articles/188693/
 
 'There were major problems building KDE on non-Linux platforms with
 SCons (e.g. on OS X); in general they felt it did not yet have a mature
 configuration system.'
 
 IOW, 'not autotools' is not a panacea for ultimate portability.

You're not adding anything new. You can take 'not autotools' in the
sentence above and replace it with whatever you want, and it will still
hold true.

I wont dispute the theoretical merits of scons vs autotools vs cmake
anymore. It's beyond that point. KDE did their homework and reached
their conclusions. I've been doing my homework and have reached other
conclusions. (This difference will only cause you surprise if you assume
KDE == Mesa, or you actually expect there is such a panacea). Now the
way of proving scons works for Mesa/Gallium or not is making it happen.
Everything else now is uncalled speculation.

(Plus you're mentioning OS X when my concern is primarily supporting
windows, where autotools is useless.)

Jose


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel