Re: [Mesa3d-dev] Gallium code reorganization
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
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
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