libdrm headers (Re: RFC: libdrm repo)
On Mon, 23 Nov 2009 17:12:07 +0100 Michel Dänzer mic...@daenzer.net wrote: On Mon, 2009-11-23 at 10:55 -0500, Kristian Høgsberg wrote: The headers in include/drm will be installed and libdrm_radeon should be updated to use those headers instead of the ones in radeon/ since they're what's upstream. At least one of the headers in question - radeon_bo.h - isn't in the kernel (and it probably makes no sense to put userland specific headers like that in the kernel) and is outdated in include/drm. Now that we are talking about headers, what is the proper layout of *installed* headers? I'm leaving out $prefix in the following. include/drm/ I'd assume that should contain only the kernel headers, and those are going a away soonish or ASAP. (krh already tried to remove them ;-) include/drm/ seems to be also containing libdrm_radeon user API headers? include/intel_bufmgr.h libdrm_intel has their header sitting in the root include dir. include/nouveau/ almost all libdrm_nouveau headers are here, except nouveau_drmif.h, which should probably be moved. include/xf86drm.h include/xf86drmMode.h and then these two... So, each of the three drivers have their headers installed differently, and Nouveau manages to fail even in that. :-) What should installed header tree look like? -- Pekka Paalanen http://www.iki.fi/pq/ -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: libdrm headers (Re: RFC: libdrm repo)
On Mon, Nov 23, 2009 at 11:50 AM, Pekka Paalanen p...@iki.fi wrote: On Mon, 23 Nov 2009 17:12:07 +0100 Michel Dänzer mic...@daenzer.net wrote: On Mon, 2009-11-23 at 10:55 -0500, Kristian Høgsberg wrote: The headers in include/drm will be installed and libdrm_radeon should be updated to use those headers instead of the ones in radeon/ since they're what's upstream. At least one of the headers in question - radeon_bo.h - isn't in the kernel (and it probably makes no sense to put userland specific headers like that in the kernel) and is outdated in include/drm. Now that we are talking about headers, what is the proper layout of *installed* headers? I'm leaving out $prefix in the following. include/drm/ I'd assume that should contain only the kernel headers, and those are going a away soonish or ASAP. (krh already tried to remove them ;-) include/drm/ seems to be also containing libdrm_radeon user API headers? include/intel_bufmgr.h libdrm_intel has their header sitting in the root include dir. include/nouveau/ almost all libdrm_nouveau headers are here, except nouveau_drmif.h, which should probably be moved. include/xf86drm.h include/xf86drmMode.h and then these two... So, each of the three drivers have their headers installed differently, and Nouveau manages to fail even in that. :-) What should installed header tree look like? Yup, as far as I can tell that's what it looked like before my re-org and it's what it finally looks like again. I defnitely agree that it's not an ideal layout, but we can't change it without breaking things. However, now that we use .pc files we should be able to move things around without recent libdrm users breaking. I'm not sure if it's worthwhile though, but if we're moving files around, it's something we can do (mostly) on a per driver basis, but we should of course agree on what kind of layout we want. I'd suggest keeping only kernel header files in include/drm, moving xf86drm.h and xf86drmMode.h to /usr/include/libdrm and moving chipset headers to /usr/include/libdrm/$chipset. cheers, Kristian -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: libdrm headers (Re: RFC: libdrm repo)
On Mon, 2009-11-23 at 12:13 -0500, Kristian Høgsberg wrote: On Mon, Nov 23, 2009 at 11:50 AM, Pekka Paalanen p...@iki.fi wrote: On Mon, 23 Nov 2009 17:12:07 +0100 Michel Dänzer mic...@daenzer.net wrote: On Mon, 2009-11-23 at 10:55 -0500, Kristian Høgsberg wrote: The headers in include/drm will be installed and libdrm_radeon should be updated to use those headers instead of the ones in radeon/ since they're what's upstream. At least one of the headers in question - radeon_bo.h - isn't in the kernel (and it probably makes no sense to put userland specific headers like that in the kernel) and is outdated in include/drm. Now that we are talking about headers, what is the proper layout of *installed* headers? I'm leaving out $prefix in the following. include/drm/ I'd assume that should contain only the kernel headers, and those are going a away soonish or ASAP. (krh already tried to remove them ;-) include/drm/ seems to be also containing libdrm_radeon user API headers? include/intel_bufmgr.h libdrm_intel has their header sitting in the root include dir. include/nouveau/ almost all libdrm_nouveau headers are here, except nouveau_drmif.h, which should probably be moved. include/xf86drm.h include/xf86drmMode.h and then these two... So, each of the three drivers have their headers installed differently, and Nouveau manages to fail even in that. :-) What should installed header tree look like? Yup, as far as I can tell that's what it looked like before my re-org and it's what it finally looks like again. I defnitely agree that it's not an ideal layout, but we can't change it without breaking things. However, now that we use .pc files we should be able to move things around without recent libdrm users breaking. I'm not sure if it's worthwhile though, but if we're moving files around, it's something we can do (mostly) on a per driver basis, but we should of course agree on what kind of layout we want. I'd suggest keeping only kernel header files in include/drm, moving xf86drm.h and xf86drmMode.h to /usr/include/libdrm and moving chipset headers to /usr/include/libdrm/$chipset. So, I was completely shocked when I was alerted on irc that libdrm no longer builds on FreeBSD. It appears that you totally whacked drm.h which is a common file shared and installed by all platforms, which has has all of the conditionals ripped from it and now blindly includes only linux bits. I have not yet determined if other such damage has occurred, but any of the includes that came from shared-core and are required for the build or that get installed should not have been mucked with. WTF? robert. cheers, Kristian -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel -- Robert Noland rnol...@2hip.net 2Hip Networks -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
