Dan Nicholson wrote: > On Mon, Feb 9, 2009 at 1:11 PM, Brian Paul <bri...@vmware.com> wrote: >> Kristian Høgsberg wrote: >>> On Mon, Feb 9, 2009 at 3:28 PM, Dan Nicholson <dbn.li...@gmail.com> wrote: >>>> On Mon, Feb 9, 2009 at 9:11 AM, Brian Paul <bri...@vmware.com> wrote: >>>>> In terms of the build system, we'll initially default to the non-gallium >>>>> build. To build with gallium I'll add some new configs like >>>>> 'linux-gallium'. >>>> I haven't tried building gallium at all, but is there interest in >>>> adding support to the autoconf goo? I don't know how well it would fit >>>> in with the current semantics (--enable-driver=...), but I could take >>>> a look. >>> I would definitely appreciate that. >>> >>> thanks, >>> Kristian >> Dan, I was hoping you'd offer to do that! :) >> >> In the long term, we'll probably want to build a mix of both traditional and >> gallium-based drivers at the same time. >> >> For the short-term something like --enable-gallium that would kind of throw >> a big switch would be OK (build gallium drivers but not the traditional >> ones). >> >> For Cell, it would be nice if we could auto-detect the presence of the Cell >> SDK headers/libs and build the gallium cell driver if they're present. >> >> Whatever you can manage would be appreciated. > > Sure. I'm not that familiar with what's actually being built under > gallium, so it might take a couple days to get familiar with that. > Taking a quick glance at gallium-master-merge, it looks like glisse > added some support already to configure. Unfortunately, I think it > will break the classic mesa build a bit. At least for DRI. I think it > should be doable to start with a big --enable-gallium switch. I'm sure > eventually we can get something to build classic + gallium in one > shot. > > If anyone wants to shed any light on what's built and installed on > gallium vs. classic, I'd appreciate that. I think I have a notional > understanding of the pipe/state_tracker/winsys architecture of > gallium, but I'm not quite visualizing how that gets built up.
Yeah, there's more subdirs now. In general, each subdir we go into builds a .a archive or assembles a group of .a archives into a .so shared library. If you do a traditional 'make <config>' build then do a 'find . name "*.a"' you can get an idea of where things are. You might want to hold off on updating autoconf until we get things a bit more sorted out. > Also, I've brought this up before, but I think it would be really > helpful to require GNU make for building mesa. Building classic DRI or > gallium already requires it, but I think it will become really ugly to > keep all the build logic stashed in configure as the options continue > to expand. What I'd like is some judicious use of conditionals: > > http://www.gnu.org/software/make/manual/make.html#Conditionals > > Just something to think about. I know there are some platforms where > GNU make is not the default, but it is usually easily available. Well, some GNU make features are used for building gallium now, like $(foreach ...) so we might as well give in. We'll see if anyone complains... -Brian ------------------------------------------------------------------------------ Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
