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
