On 20/05/14 04:49, Jonathan Gray wrote: > On Mon, May 19, 2014 at 11:57:58PM +0100, Emil Velikov wrote: >> On 18/05/14 12:22, Jonathan Gray wrote: >> [snip] >>> >>> Currently I run my autotools builds like this: >>> >>> export LDFLAGS=-L/usr/local/lib >>> export CPPFLAGS="-I/usr/local/include -I/usr/local/include/libelf" >>> export AUTOMAKE_VERSION=1.12 >>> export AUTOCONF_VERSION=2.69 >>> export LEX=/usr/local/bin/gflex >>> ./autogen.sh \ >>> --with-gallium-drivers=r300,r600,radeonsi,swrast,nouveau \ >>> --with-dri-drivers=i915,i965,r200,radeon,swrast \ >>> --disable-silent-rules \ >>> --enable-r600-llvm-compiler --enable-gallium-llvm \ >>> --disable-llvm-shared-libs \ >>> --enable-gles1 --enable-gles2 \ >>> --enable-shared-glapi \ >>> --disable-osmesa \ >>> --enable-debug \ >>> --enable-gbm \ >>> --with-egl-platforms="x11,drm" \ >>> --prefix=/usr/mesa >>> >> I'm a bit curious how xenocara's CVS is going to handle the symlinks when >> building dri/radeon, dri/r200 and st/dri (all gallium dri drivers). AFAICS it >> will fail miserably :\ >> If interested you can rework the former two and effectively drop a handful >> symbol redefinition, shed off some code and size off the classic dri. I'm >> planning to address the st/dri case after this series is merged. > > I'm not really sure what xenocara has to do with the autotools build? > As said before xenocara uses it's own set of makefiles, ie > http://www.openbsd.org/cgi-bin/cvsweb/xenocara/lib/libGL/dri/radeon/Makefile?rev=HEAD;content-type=text%2Fplain > http://www.openbsd.org/cgi-bin/cvsweb/xenocara/lib/libGL/dri/r600g/Makefile?rev=HEAD;content-type=text%2Fplain > with seperate directories for libglapi libGL libEGL libGLESv1_CM libGLESv2 > that refer to the source in > http://www.openbsd.org/cgi-bin/cvsweb/xenocara/dist/Mesa/ > Hmm... I assumed that the openbsd makefiles were a mere stripped down version of the ones generated by autohell. Seem like that is not the case :\ FWIW you guys can reuse the Makefile.sources if interested.
>> >> >From the above configure one cannot determine if you're building vdpau. >> Current code enables the vdpau targets if the vdpau package is available. Can >> you confirm if this is the case or not ? > > My autotools builds are not done on a system with vdpau installed. > The resulting target list from configure here looks like: > > Gallium: yes > Target dirs: dri-nouveau dri-swrast r300/dri r600/dri > radeonsi/dri > Winsys dirs: nouveau/drm radeon/drm sw sw/dri sw/xlib > Driver dirs: galahad identity llvmpipe noop nouveau r300 r600 > radeonsi rbug softpipe trace > Trackers dirs: dri > > The build does not seem to reference gallium/state_trackers/vdpau but > does build mesa/main/vdpau.c and mesa/state_tracker/st_vdpau.c > > It would be nice to have the possibility of building the gallium > vdpau code in future however. > Yes it would be very nice to have. I'm not sure that classifies as regression, as you haven't really built/used them. With that said the plan is to revisit the messy symlink creation at a later stage. -Emil _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
