Re: Gallium code reorganization
On 2/14/08, José Fonseca [EMAIL PROTECTED] wrote: I'll dedicate some time now to reorganize gallium's code build process. This is stuff which has been discussed internally at TG several times, but this time I want to get it done. My objectives are: - leaner and more easy to understand/navigate source tree - reduce (or even eliminate) merges between private branches of the common gallium parts - help keep the gallium tree portable, by keeping things separate. My plan is: 1. Physically separate gallium source code from mesa code. This will be the final layout: - src/mesa - src/gallium - state_tracker - ogl - ... - drivers - i915simple - i965simple - cell - ... - winsys - dri - intel - ... - xlib - ... - aux - tgsi - draw - pipebuffer - llvm - cso_cache - ... i.e., give a subdir in src/gallium to each gallium architectural layer. 2. Eliminate mesa includes out of the gallium source code from everything but mesa's state_tracker. This is finished now. 3. Using scons, enhance the build system to support all platforms we are interested (i.e., linux and win32, atm), I'm working on this now. ATM you can easily do compile-testing of your changes on many gallium variants from a single tree by executing (e.g., from a script): scons dri=0 scons dri=1 scons llvm=1 And it can be done regardless of what config is enabled, as it won't affect the conventional Makefile build. The end result is still not usable in a few cases (due to library interdependencies issues on linking, and lack of an install target). I'm going to see if I can get cell and win32 working this way too. 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
Re: Gallium code reorganization
Just to let you know that the first step, file shuffling, is finished. The rest will take more time but changes are less pervasive. Once you update any private branches to the new directory layout, you should be able to keep working as usual. Here's a quick summary of the changes you might need to do: - move your source files to the directory layout described below; - update the TOP dirs in your Makefiles; - update the include paths, replacing -I src/mesa/pipe to -I src/gallium/include -I src/gallium/drivers -I src/gallium/aux; - remove pipe/ prefix from from all includes *except* pipe/p_*.h includes. Jose On Thu, 2008-02-14 at 15:38 +0900, José Fonseca wrote: I'll dedicate some time now to reorganize gallium's code build process. This is stuff which has been discussed internally at TG several times, but this time I want to get it done. My objectives are: - leaner and more easy to understand/navigate source tree - reduce (or even eliminate) merges between private branches of the common gallium parts - help keep the gallium tree portable, by keeping things separate. My plan is: 1. Physically separate gallium source code from mesa code. This will be the final layout: - src/mesa - src/gallium - state_tracker - ogl - ... - drivers - i915simple - i965simple - cell - ... - winsys - dri - intel - ... - xlib - ... - aux - tgsi - draw - pipebuffer - llvm - cso_cache - ... i.e., give a subdir in src/gallium to each gallium architectural layer. 2. Eliminate mesa includes out of the gallium source code from everything but mesa's state_tracker (and eventually some winsys). 3. Using scons, enhance the build system to support all platforms we are interested (i.e., linux and win32, atm), 4. Teach the build system how to pick and build pipe/winsys drivers outside of the tree. 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
Re: Gallium code reorganization
OK, I found I had to merge rather than rebase in order to get my changes into the new organization -- apologies for the bubble in the history. Keith José Fonseca wrote: Just to let you know that the first step, file shuffling, is finished. The rest will take more time but changes are less pervasive. Once you update any private branches to the new directory layout, you should be able to keep working as usual. Here's a quick summary of the changes you might need to do: - move your source files to the directory layout described below; - update the TOP dirs in your Makefiles; - update the include paths, replacing -I src/mesa/pipe to -I src/gallium/include -I src/gallium/drivers -I src/gallium/aux; - remove pipe/ prefix from from all includes *except* pipe/p_*.h includes. Jose On Thu, 2008-02-14 at 15:38 +0900, José Fonseca wrote: I'll dedicate some time now to reorganize gallium's code build process. This is stuff which has been discussed internally at TG several times, but this time I want to get it done. My objectives are: - leaner and more easy to understand/navigate source tree - reduce (or even eliminate) merges between private branches of the common gallium parts - help keep the gallium tree portable, by keeping things separate. My plan is: 1. Physically separate gallium source code from mesa code. This will be the final layout: - src/mesa - src/gallium - state_tracker - ogl - ... - drivers - i915simple - i965simple - cell - ... - winsys - dri - intel - ... - xlib - ... - aux - tgsi - draw - pipebuffer - llvm - cso_cache - ... i.e., give a subdir in src/gallium to each gallium architectural layer. 2. Eliminate mesa includes out of the gallium source code from everything but mesa's state_tracker (and eventually some winsys). 3. Using scons, enhance the build system to support all platforms we are interested (i.e., linux and win32, atm), 4. Teach the build system how to pick and build pipe/winsys drivers outside of the tree. 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 - 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: Gallium code reorganization
I think it is almost impossible to rebase under these circumstances. BTW, there was an unforeseen problem -- aux appears to be special file on windows. Hence I had to rename that directory to auxiliary... Jose On 2/15/08, Keith Whitwell [EMAIL PROTECTED] wrote: OK, I found I had to merge rather than rebase in order to get my changes into the new organization -- apologies for the bubble in the history. Keith José Fonseca wrote: Just to let you know that the first step, file shuffling, is finished. The rest will take more time but changes are less pervasive. Once you update any private branches to the new directory layout, you should be able to keep working as usual. Here's a quick summary of the changes you might need to do: - move your source files to the directory layout described below; - update the TOP dirs in your Makefiles; - update the include paths, replacing -I src/mesa/pipe to -I src/gallium/include -I src/gallium/drivers -I src/gallium/aux; - remove pipe/ prefix from from all includes *except* pipe/p_*.h includes. Jose On Thu, 2008-02-14 at 15:38 +0900, José Fonseca wrote: I'll dedicate some time now to reorganize gallium's code build process. This is stuff which has been discussed internally at TG several times, but this time I want to get it done. My objectives are: - leaner and more easy to understand/navigate source tree - reduce (or even eliminate) merges between private branches of the common gallium parts - help keep the gallium tree portable, by keeping things separate. My plan is: 1. Physically separate gallium source code from mesa code. This will be the final layout: - src/mesa - src/gallium - state_tracker - ogl - ... - drivers - i915simple - i965simple - cell - ... - winsys - dri - intel - ... - xlib - ... - aux - tgsi - draw - pipebuffer - llvm - cso_cache - ... i.e., give a subdir in src/gallium to each gallium architectural layer. 2. Eliminate mesa includes out of the gallium source code from everything but mesa's state_tracker (and eventually some winsys). 3. Using scons, enhance the build system to support all platforms we are interested (i.e., linux and win32, atm), 4. Teach the build system how to pick and build pipe/winsys drivers outside of the tree. 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 - 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
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: Gallium code reorganization
On Thu, Feb 14, 2008 at 1:38 AM, José Fonseca [EMAIL PROTECTED] wrote: I'll dedicate some time now to reorganize gallium's code build process. This is stuff which has been discussed internally at TG several times, but this time I want to get it done. My objectives are: - leaner and more easy to understand/navigate source tree I'm not sure what the scope of the work you're proposing here is, but to get to a leaner source tree, I would definitely recommend splitting out the libraries: glu, glut, glw. egl and even glx. Kristian - 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: Gallium code reorganization
On 2/15/08, Kristian Høgsberg [EMAIL PROTECTED] wrote: On Thu, Feb 14, 2008 at 1:38 AM, José Fonseca [EMAIL PROTECTED] wrote: I'll dedicate some time now to reorganize gallium's code build process. This is stuff which has been discussed internally at TG several times, but this time I want to get it done. My objectives are: - leaner and more easy to understand/navigate source tree I'm not sure what the scope of the work you're proposing here is, but to get to a leaner source tree, I would definitely recommend splitting out the libraries: glu, glut, glw. egl and even glx. At some point, gallium might get its own repository and separate from mesa and the libraries you mention -- it would make all sense as Keith sees Mesa as one among many Gallium clients. But for now, I just want to reorganize the code within the same repository so that if/when that's decided, all the parts are loosely coupled to make it painless. 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
Gallium code reorganization
I'll dedicate some time now to reorganize gallium's code build process. This is stuff which has been discussed internally at TG several times, but this time I want to get it done. My objectives are: - leaner and more easy to understand/navigate source tree - reduce (or even eliminate) merges between private branches of the common gallium parts - help keep the gallium tree portable, by keeping things separate. My plan is: 1. Physically separate gallium source code from mesa code. This will be the final layout: - src/mesa - src/gallium - state_tracker - ogl - ... - drivers - i915simple - i965simple - cell - ... - winsys - dri - intel - ... - xlib - ... - aux - tgsi - draw - pipebuffer - llvm - cso_cache - ... i.e., give a subdir in src/gallium to each gallium architectural layer. 2. Eliminate mesa includes out of the gallium source code from everything but mesa's state_tracker (and eventually some winsys). 3. Using scons, enhance the build system to support all platforms we are interested (i.e., linux and win32, atm), 4. Teach the build system how to pick and build pipe/winsys drivers outside of the tree. 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
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
