Re: [Dri-devel] libGL{U,w}
On Wed, Nov 20, 2002 at 04:11:10PM -0700, Brian Paul wrote: I'm willing to bet that there's around 100 header files in the XFree86 tree that get pulled into the compilation of the various DRI-related source files. Determining what to keep and what to discard would be a long process. Isn't the X11 depencency system recursive? There you have a list of what's needed and what's not needed, or did I miss the point? -- Marcelo --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] libGL{U,w}
On Mon, Nov 18, 2002 at 09:46:35PM -0500, David Dawes wrote: ... If the goal is to make the DRI CVS as small as possible, why not go all the way and turn it into an environment for building only the DRI-related modules? That would change the nature of XFree86 merges quite a bit, but that wouldn't necessarily be a bad thing. That definately sounds like the Right Thing To Do. So who's volunteering? :- --- This sf.net email is sponsored by: Battle your brains against the best in the Thawte Crypto Challenge. Be the first to crack the code - register now: http://www.gothawte.com/rd521.html ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] libGL{U,w}
Philip Brown wrote: On Mon, Nov 18, 2002 at 09:46:35PM -0500, David Dawes wrote: ... If the goal is to make the DRI CVS as small as possible, why not go all the way and turn it into an environment for building only the DRI-related modules? That would change the nature of XFree86 merges quite a bit, but that wouldn't necessarily be a bad thing. That definately sounds like the Right Thing To Do. Easier said than done. I'm willing to bet that there's around 100 header files in the XFree86 tree that get pulled into the compilation of the various DRI-related source files. Determining what to keep and what to discard would be a long process. Then, there's the Imakefile system. For every directory with DRI- related files you'd have to keep all Imakefiles in all parent directories. Eventually you'd wind up with a skeleton of the XFree86 tree with key files scattered throughout. I'm not sure that the effort involved in setting that up would be worth it. -Brian --- This sf.net email is sponsored by: Battle your brains against the best in the Thawte Crypto Challenge. Be the first to crack the code - register now: http://www.gothawte.com/rd521.html ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] libGL{U,w}
On Wed, Nov 20, 2002 at 04:11:10PM -0700, Brian Paul wrote: Philip Brown wrote: That definately sounds like the Right Thing To Do. Easier said than done. I'm willing to bet that there's around 100 header files in the XFree86 tree that get pulled into the compilation of the various DRI-related source files. well, you could always revert to the utah-glx method, of duplicating an include tree with *just* the X11 header files. Then, there's the Imakefile system. For every directory with DRI- related files you'd have to keep all Imakefiles in all parent directories. Or... stop using Imake, and switch to autoconf. I'm not sure that the effort involved in setting that up would be worth it. Obviously, it is a very considerable amount of effort. But the results would be much cleaner, and hopefully lead to more abstraction away from the xfree code, and into a code tree structure that is more tightly coherent in and of itself --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] libGL{U,w}
On Thu, Nov 07, 2002 at 04:32:03PM +, Keith Whitwell wrote: Michel Dänzer wrote: On Don, 2002-11-07 at 16:56, Keith Whitwell wrote: Michel Dänzer wrote: These no longer get built by default. Any objections against the attached patch? Actually if they're not built, I think we should ditch them from cvs. We're not working on them. In that case I'd vote again for removing unused drivers etc. as well. I'm ok with that too, as long as it simplifies rather than complicates the lives of people who are doing XFree merges. It would probably complicate things a little, if anything. It certainly wouldn't make it any easier. If the goal is to make the DRI CVS as small as possible, why not go all the way and turn it into an environment for building only the DRI-related modules? That would change the nature of XFree86 merges quite a bit, but that wouldn't necessarily be a bad thing. David --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] libGL{U,w}
On Thu, Nov 07, 2002 at 03:13:30PM +0100, Michel Dänzer wrote: These no longer get built by default. Any objections against the attached patch? Is there any reason to ? Have we patched/changed these at all from the standard 4.2.0 base ? Alan. --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] libGL{U,w}
On Don, 2002-11-07 at 16:01, Alan Hourihane wrote: On Thu, Nov 07, 2002 at 03:13:30PM +0100, Michel Dänzer wrote: These no longer get built by default. Any objections against the attached patch? Is there any reason to ? Have we patched/changed these at all from the standard 4.2.0 base ? I don't know, probably not. My personal reason is that I need them for my Debian packages. Of course, I can patch the tree for building them, but at least the Imakefile part makes no sense to me as it is. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] libGL{U,w}
Alan Hourihane wrote: On Thu, Nov 07, 2002 at 03:13:30PM +0100, Michel Dänzer wrote: These no longer get built by default. Any objections against the attached patch? Is there any reason to ? Have we patched/changed these at all from the standard 4.2.0 base ? When I bring Mesa 5.0 into CVS I'll bring in some GLU changes (mostly compilation warning fixes). Otherwise, I don't think anything has changed in GLU or GLw for a long time. I don't have an opinion on Michel's patch. -Brian --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] libGL{U,w}
On Thu, Nov 07, 2002 at 04:09:44PM +0100, Michel Dänzer wrote: On Don, 2002-11-07 at 16:01, Alan Hourihane wrote: On Thu, Nov 07, 2002 at 03:13:30PM +0100, Michel Dänzer wrote: These no longer get built by default. Any objections against the attached patch? Is there any reason to ? Have we patched/changed these at all from the standard 4.2.0 base ? I don't know, probably not. My personal reason is that I need them for my Debian packages. Of course, I can patch the tree for building them, but at least the Imakefile part makes no sense to me as it is. I don't have a problem with turning them on. Check with Eric Anholt to make sure there isn't a FreeBSD build problem with that patch. Alan. --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] libGL{U,w}
On Thu, Nov 07, 2002 at 08:17:06AM -0700, Brian Paul wrote: Alan Hourihane wrote: On Thu, Nov 07, 2002 at 03:13:30PM +0100, Michel Dänzer wrote: These no longer get built by default. Any objections against the attached patch? Is there any reason to ? Have we patched/changed these at all from the standard 4.2.0 base ? When I bring Mesa 5.0 into CVS I'll bring in some GLU changes (mostly compilation warning fixes). Have you sent the changes back to the ogl-sample list at SGI ? If so, we'll pick them changes up when XFree86 merges the ogl-sample directory again. Alan. --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] libGL{U,w}
Alan Hourihane wrote: On Thu, Nov 07, 2002 at 08:17:06AM -0700, Brian Paul wrote: Alan Hourihane wrote: On Thu, Nov 07, 2002 at 03:13:30PM +0100, Michel Dänzer wrote: These no longer get built by default. Any objections against the attached patch? Is there any reason to ? Have we patched/changed these at all from the standard 4.2.0 base ? When I bring Mesa 5.0 into CVS I'll bring in some GLU changes (mostly compilation warning fixes). Have you sent the changes back to the ogl-sample list at SGI ? I haven't. I will but there's no guarantee that SGI will apply my patch in a timely manner. If so, we'll pick them changes up when XFree86 merges the ogl-sample directory again. -Brian --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] libGL{U,w}
On Thu, Nov 07, 2002 at 03:56:46PM +, Keith Whitwell wrote: Michel Dänzer wrote: These no longer get built by default. Any objections against the attached patch? Actually if they're not built, I think we should ditch them from cvs. We're not working on them. Now that sound like a better deal. Alan. --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] libGL{U,w}
On Thu, Nov 07, 2002 at 04:32:03PM +, Keith Whitwell wrote: Michel Dänzer wrote: On Don, 2002-11-07 at 16:56, Keith Whitwell wrote: Michel Dänzer wrote: These no longer get built by default. Any objections against the attached patch? Actually if they're not built, I think we should ditch them from cvs. We're not working on them. In that case I'd vote again for removing unused drivers etc. as well. I'm ok with that too, as long as it simplifies rather than complicates the lives of people who are doing XFree merges. I wouldn't like to remove the drivers. They don't cause any import conflicts and they're useful to those who want to start a DRI driver for another chipset. But GLU is a pain in the neck. It has alsorts of $Id, $Revision and $Date cvs tags that get updated during commits. This causes import conflicts and the work involved to resolve them. I doubt we'll ever work on GLU or GLw. Alan. --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] libGL{U,w}
On Don, 2002-11-07 at 17:38, Alan Hourihane wrote: On Thu, Nov 07, 2002 at 04:32:03PM +, Keith Whitwell wrote: Michel Dänzer wrote: On Don, 2002-11-07 at 16:56, Keith Whitwell wrote: Michel Dänzer wrote: These no longer get built by default. Any objections against the attached patch? Actually if they're not built, I think we should ditch them from cvs. We're not working on them. In that case I'd vote again for removing unused drivers etc. as well. I'm ok with that too, as long as it simplifies rather than complicates the lives of people who are doing XFree merges. I wouldn't like to remove the drivers. They don't cause any import conflicts and they're useful to those who want to start a DRI driver for another chipset. They can trivially be added back in that case, and these libraries for people who want to provide packages off the DRI tree. But GLU is a pain in the neck. It has alsorts of $Id, $Revision and $Date cvs tags that get updated during commits. This causes import conflicts and the work involved to resolve them. I doubt we'll ever work on GLU or GLw. I see, I'll cope. Anyway, back to the point of my patch: even in the context of the XFree86 tree, does it make sense only to build these libraries when all libraries are built, even if the user explicitly wants to build them? -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] libGL{U,w}
On Don, 2002-11-07 at 18:04, Alan Hourihane wrote: On Thu, Nov 07, 2002 at 05:48:22PM +0100, Michel Dänzer wrote: On Don, 2002-11-07 at 17:38, Alan Hourihane wrote: On Thu, Nov 07, 2002 at 04:32:03PM +, Keith Whitwell wrote: Michel Dänzer wrote: On Don, 2002-11-07 at 16:56, Keith Whitwell wrote: Michel Dänzer wrote: These no longer get built by default. Any objections against the attached patch? Actually if they're not built, I think we should ditch them from cvs. We're not working on them. In that case I'd vote again for removing unused drivers etc. as well. I'm ok with that too, as long as it simplifies rather than complicates the lives of people who are doing XFree merges. I wouldn't like to remove the drivers. They don't cause any import conflicts and they're useful to those who want to start a DRI driver for another chipset. They can trivially be added back in that case, and these libraries ...are useful... for people who want to provide packages off the DRI tree. Why remove them, if we end up having to put them back ? And for the libraries - they haven't changed since 4.2.0 - so why would people want to put them in packages ? Because they're in the same package as libGL, it would make life a bit easier, but like I said I'll cope. Anyway, back to the point of my patch: even in the context of the XFree86 tree, does it make sense only to build these libraries when all libraries are built, even if the user explicitly wants to build them? Like I said, Check with Eric. I know he added a BuildLibraries to the XThrStub one, so maybe there's an underlying build problem somewhere else that needs to be fixed before we can apply this. IMHO that should be handled somewhere in config/ then instead of the Imakefile preventing this where it works. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] libGL{U,w}
On Thu, Nov 07, 2002 at 09:16:49AM -0800, Ian Romanick wrote: On Thu, Nov 07, 2002 at 05:04:41PM +, Alan Hourihane wrote: On Thu, Nov 07, 2002 at 05:48:22PM +0100, Michel Dänzer wrote: On Don, 2002-11-07 at 17:38, Alan Hourihane wrote: On Thu, Nov 07, 2002 at 04:32:03PM +, Keith Whitwell wrote: Michel Dänzer wrote: On Don, 2002-11-07 at 16:56, Keith Whitwell wrote: Michel Dänzer wrote: These no longer get built by default. Any objections against the attached patch? Actually if they're not built, I think we should ditch them from cvs. We're not working on them. In that case I'd vote again for removing unused drivers etc. as well. I'm ok with that too, as long as it simplifies rather than complicates the lives of people who are doing XFree merges. I wouldn't like to remove the drivers. They don't cause any import conflicts and they're useful to those who want to start a DRI driver for another chipset. They can trivially be added back in that case, and these libraries for people who want to provide packages off the DRI tree. Why remove them, if we end up having to put them back ? And for the libraries - they haven't changed since 4.2.0 - so why would people want to put them in packages ? For most of the cards, that's a BIG if. Quite a few of the cards that we're packing around drivers for don't even have any 3D acceleration to support. The sun*, tseng, tga, i128, cyrix, cirrus, chips, and ark drivers come to mind. The only drivers for which we don't already have 3D support for (in the trunk) that we should probably keep around are the i740 (just in case!), nv, s3virge, and savage. If somebody could scare up docs, rendition might could be added to the list... Your forgetting that sun* has the ffb driver. If your volunteering to do the merges in future Ian - go ahead and remove them. :) Alan. --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] libGL{U,w}
On Thu, Nov 07, 2002 at 05:26:40PM +0100, Michel Dänzer wrote: On Don, 2002-11-07 at 16:56, Keith Whitwell wrote: Michel Dänzer wrote: These no longer get built by default. Any objections against the attached patch? Actually if they're not built, I think we should ditch them from cvs. We're not working on them. In that case I'd vote again for removing unused drivers etc. as well. Err, no please, i still have plans to work on the gamma driver, but have not that much time right now (I guess it would be the prime candidate for removal, isn't it ?) Friendly, Sven Luther --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] libGL{U,w}
On Thu, 2002-11-07 at 09:04, Alan Hourihane wrote: On Thu, Nov 07, 2002 at 05:48:22PM +0100, Michel Dänzer wrote: Anyway, back to the point of my patch: even in the context of the XFree86 tree, does it make sense only to build these libraries when all libraries are built, even if the user explicitly wants to build them? Like I said, Check with Eric. I know he added a BuildLibraries to the XThrStub one, so maybe there's an underlying build problem somewhere else that needs to be fixed before we can apply this. That was because libXThrStub is not in the DRI tree, and BuildLibraries was is to NO for the DRI tree (I was just reverting a change made during the 4.2.99.2 merge). libXThrStub is only used by libX11, which is also not in the tree. Although I haven't actually tried a build with libGLU/libGLw, I don't expect there to be any problems. -- Eric Anholt [EMAIL PROTECTED] http://people.freebsd.org/~anholt/dri/ --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
