Re: [PULL] Server build fixes
On Thu, 3 Mar 2011 20:42:55 -0800, Dan Nicholson wrote: > I think your original patch is the right way to go. Merged. 705f047..628d16a master -> master -- keith.pack...@intel.com pgpXnnWjnLLDe.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PULL] Server build fixes
On Thu, Mar 3, 2011 at 2:10 PM, Keith Packard wrote: > On Sat, 26 Feb 2011 11:01:38 -0800, Dan Nicholson wrote: > >> It should get run every time config.status is run, which is every time >> configure runs. So, sdksyms.dep should get updated exactly when the >> Makefiles do. I do agree that sdksyms.c shouldn't be shipped in the >> tarball, but I think it should work anyway (patch attached). > > Do you have a 'final' patch that you'd like me to merge at this point? I think your original patch is the right way to go. sdksyms.dep _is_ needed as far as I can tell because we need sdksyms.c to depend on all the headers. Say you add a new symbol in dix.h. That won't necessarily mean that the *config.h files get rebuilt. However adding an explicit dependency on *config.h means that you will definitely get sdksyms.c regenerated after you run configure. That seems like a safe thing to do. You can include my: Reviewed-by: Dan Nicholson ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PULL] Server build fixes
On Sat, 26 Feb 2011 11:01:38 -0800, Dan Nicholson wrote: > It should get run every time config.status is run, which is every time > configure runs. So, sdksyms.dep should get updated exactly when the > Makefiles do. I do agree that sdksyms.c shouldn't be shipped in the > tarball, but I think it should work anyway (patch attached). Do you have a 'final' patch that you'd like me to merge at this point? -- keith.pack...@intel.com pgpAUjLhUHIuO.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PULL] Server build fixes
On Sun, 27 Feb 2011 14:29:30 -0800, Dan Nicholson wrote: > I rolled Keith's diff in with my own and added the fix of actually > making sdksyms.dep be a prerequisite for sdksyms.c. I think that should > fix all the cases. Actually, I'm wondering if sdksyms.dep isn't needed if we add an explicit dependency on do-not-use-config.h for sdksyms.c -- any change to the config stuff that might affect the contents of sdksyms.c will also change do-not-use-config.h, right? Or, am I just confused -- this is surprisingly twisty. -- keith.pack...@intel.com pgpVDjCUkWJYk.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PULL] Server build fixes
On Sun, Feb 27, 2011 at 03:26:32AM +0100, Cyril Brulebois wrote: > Hi, > > Keith Packard (26/02/2011): > > I read through the automake docs and they suggest placing a > > dependency on the generated configuration header file. We've got > > several, but there's the auto-generated do-not-use-config.h which > > holds all of the cpp defines which sdksyms.c may use. > > > > I think this is what we want: […] > > at least, this fixes the issue I was having. Steps to reproduce: > git checkout master > git clean -xdf > autoreconf -vfi > ./configure > make dist > # elsewhere > tar xf $tarball > cd $directory > ./configure --disable-xv > > With master → fails, master + your patch → works. Accordingly: > > Tested-by: Cyril Brulebois > > Also, the generated sdksyms.c lands in the build directory, meaning > one can happily do stuff like: > mkdir build1 build2 > (cd build1 && ../configure --disable-stuff) > (cd build2 && ../configure --enable-stuff) > make -C build1 > make -C build2 > > And even “make” build1 and build2 in parallel. > > (FYI, that's what we do in Debian: we build two flavours; one regular, > one for the debian-installer; with a configuration phase, then a build > phase; hence my issues with --disable-xv and the like. ;)) I rolled Keith's diff in with my own and added the fix of actually making sdksyms.dep be a prerequisite for sdksyms.c. I think that should fix all the cases. -- Dan >From 6263490d272a2f15f1a38a8eb452b73e9bcd0ba2 Mon Sep 17 00:00:00 2001 From: Dan Nicholson Date: Sat, 26 Feb 2011 08:34:27 -0800 Subject: [PATCH] xfree86: Ensure sdksyms.c is regenerated when appropriate The contents of sdksyms.c are dependent on configuration, so they should be freshly generated each time and not shipped in the tarball. Prereqs on sdksyms.dep and one of the config.h files will ensure that the sdksyms.c is regenerated whenever config.status is run. Signed-off-by: Dan Nicholson --- hw/xfree86/loader/Makefile.am |8 ++-- 1 files changed, 6 insertions(+), 2 deletions(-) diff --git a/hw/xfree86/loader/Makefile.am b/hw/xfree86/loader/Makefile.am index 7f386cc..3d864cd 100644 --- a/hw/xfree86/loader/Makefile.am +++ b/hw/xfree86/loader/Makefile.am @@ -17,13 +17,17 @@ libloader_la_SOURCES = \ loaderProcs.h \ loadext.c \ loadmod.c \ - os.c \ + os.c + +nodist_libloader_la_SOURCES = \ sdksyms.c + libloader_la_LIBADD = $(DLOPEN_LIBS) CLEANFILES = sdksyms.c sdksyms.dep -sdksyms.dep sdksyms.c: sdksyms.sh +sdksyms.c: sdksyms.dep +sdksyms.dep sdksyms.c: sdksyms.sh $(top_builddir)/include/do-not-use-config.h CPP='$(CPP)' AWK='$(AWK)' $(srcdir)/sdksyms.sh $(top_srcdir) $(AM_CFLAGS) $(CFLAGS) $(INCLUDES) SDKSYMS_DEP = sdksyms.dep -- 1.7.3.4 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PULL] Server build fixes
Hi, Keith Packard (26/02/2011): > I read through the automake docs and they suggest placing a > dependency on the generated configuration header file. We've got > several, but there's the auto-generated do-not-use-config.h which > holds all of the cpp defines which sdksyms.c may use. > > I think this is what we want: […] at least, this fixes the issue I was having. Steps to reproduce: git checkout master git clean -xdf autoreconf -vfi ./configure make dist # elsewhere tar xf $tarball cd $directory ./configure --disable-xv With master → fails, master + your patch → works. Accordingly: Tested-by: Cyril Brulebois Also, the generated sdksyms.c lands in the build directory, meaning one can happily do stuff like: mkdir build1 build2 (cd build1 && ../configure --disable-stuff) (cd build2 && ../configure --enable-stuff) make -C build1 make -C build2 And even “make” build1 and build2 in parallel. (FYI, that's what we do in Debian: we build two flavours; one regular, one for the debian-installer; with a configuration phase, then a build phase; hence my issues with --disable-xv and the like. ;)) Thanks. KiBi. signature.asc Description: Digital signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PULL] Server build fixes
Dan Nicholson (26/02/2011): > And when I run make, sdksyms.sh is run first and then sdksyms.c is > built. Can you check if that's the case on your error? Or, if you > manually run sdksyms.sh again, does the error go away? You may be > right, though. sdksyms.c doesn't explicitly depend on sdksyms.dep, > so if they're both there on the first run, then make may decide to > skip generating them. Here's what I get: * after tar xf on 1.10.0's tarball: $ find -name 'sdksym*' -ls 10352198 -rwxr-xr-x 1 cyrilcyril7549 Dec 20 09:48 ./hw/xfree86/loader/sdksyms.sh 1035228 216 -rw-r--r-- 1 cyrilcyril 213889 Feb 26 06:14 ./hw/xfree86/loader/sdksyms.c * after configure --disable-xv $ find -name 'sdksym*' -ls 10352198 -rwxr-xr-x 1 cyrilcyril7549 Dec 20 09:48 ./hw/xfree86/loader/sdksyms.sh 12375154 -rw-r--r-- 1 cyrilcyril 8 Feb 27 02:13 ./hw/xfree86/loader/.deps/sdksyms.Plo 10354680 -rw-r--r-- 1 cyrilcyril 0 Feb 27 02:13 ./hw/xfree86/loader/sdksyms.dep 1035228 216 -rw-r--r-- 1 cyrilcyril 213889 Feb 26 06:14 ./hw/xfree86/loader/sdksyms.c * after make breaks: $ find -name 'sdksym*' -ls 10352198 -rwxr-xr-x 1 cyrilcyril7549 Dec 20 09:48 ./hw/xfree86/loader/sdksyms.sh 1237514 20 -rw-r--r-- 1 cyrilcyril 19021 Feb 27 02:22 ./hw/xfree86/loader/.deps/sdksyms.Tpo 12375154 -rw-r--r-- 1 cyrilcyril 8 Feb 27 02:13 ./hw/xfree86/loader/.deps/sdksyms.Plo 10354680 -rw-r--r-- 1 cyrilcyril 0 Feb 27 02:13 ./hw/xfree86/loader/sdksyms.dep 1035228 216 -rw-r--r-- 1 cyrilcyril 213889 Feb 26 06:14 ./hw/xfree86/loader/sdksyms.c Will give your patch a try later, probably “tomorrow”. KiBi. signature.asc Description: Digital signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PULL] Server build fixes
On Sat, Feb 26, 2011 at 10:31 AM, Keith Packard wrote: > On Sat, 26 Feb 2011 15:33:20 +0100, Cyril Brulebois wrote: > >> I fear that the sdksyms part is broken. If one builds with some >> options different than the ones used to generate the tarball, the file >> isn't generated again, leading to such issues. > > Looks like sdksyms.c should be stuck in nodist_libloader_la_SOURCES so > that it doesn't get distributed. Nothing has changed here in a long > time, so I'm a bit confused why this cropped up so soon with 1.10.0; > the sdksyms.c stuff was added over two years ago. > > A 'make clean' before 'make' will resolve the issue for the existing > 1.10 package. > >> A wild guess would be the “touch” added to configure leading to an >> up-to-date target. Also, I'm not sure it's a good idea to ship >> sdksyms.c in the tarball? (It was shipped already in rc3 and before, >> but that didn't lead to any issues.) > > I read through the automake docs and they suggest placing a dependency > on the generated configuration header file. We've got several, but > there's the auto-generated do-not-use-config.h which holds all of the > cpp defines which sdksyms.c may use. > > I think this is what we want: > > diff --git a/hw/xfree86/loader/Makefile.am b/hw/xfree86/loader/Makefile.am > index 7f386cc..0e5b304 100644 > --- a/hw/xfree86/loader/Makefile.am > +++ b/hw/xfree86/loader/Makefile.am > @@ -12,18 +12,21 @@ EXTRA_DIST = \ > loaderProcs.h \ > sdksyms.sh > > +nodist_libloader_la_SOURCES = \ > + sdksyms.c > + > libloader_la_SOURCES = \ > loader.c \ > loaderProcs.h \ > loadext.c \ > loadmod.c \ > - os.c \ > - sdksyms.c > + os.c > + > libloader_la_LIBADD = $(DLOPEN_LIBS) > > CLEANFILES = sdksyms.c sdksyms.dep > > -sdksyms.dep sdksyms.c: sdksyms.sh > +sdksyms.dep sdksyms.c: sdksyms.sh $(top_builddir)/include/do-not-use-config.h > CPP='$(CPP)' AWK='$(AWK)' $(srcdir)/sdksyms.sh $(top_srcdir) > $(AM_CFLAGS) $(CFLAGS) $(INCLUDES) > > SDKSYMS_DEP = sdksyms.dep Oh, I didn't see this before I sent. This seems like a useful thing, but I think there really needs to be a rule that sdksyms.c depends on sdksyms.dep in case the dep file gets updated out-of-band from running sdksyms.sh. nodisting the file will probably be good enough, but your patch can't hurt. Reviewed-by: Dan Nicholson -- Dan ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PULL] Server build fixes
On Sat, Feb 26, 2011 at 6:33 AM, Cyril Brulebois wrote: > Hi, > > Keith Packard (25/02/2011): >> On Fri, 25 Feb 2011 06:43:58 -0800, Dan Nicholson >> wrote: >> >> > Dan Nicholson (2): >> > xfree86: Allow sdksyms.dep to be included portably >> > dmx: Construct paths in doxygen.conf to fix VPATH builds >> >> Merged. >> 780a77a..6b951de master -> master > > I fear that the sdksyms part is broken. If one builds with some > options different than the ones used to generate the tarball, the file > isn't generated again, leading to such issues. > > Example: > | CC sdksyms.lo > | ../../../../hw/xfree86/loader/sdksyms.c:416: error: 'AugmentSelf' > undeclared here (not in a function) > | ../../../../hw/xfree86/loader/sdksyms.c:417: error: > 'RegisterAuthorizations' undeclared here (not in a function) > > if xdcmp is disabled, since in include/os.h we have: > | #if XDMCP > | extern _X_EXPORT void AugmentSelf(pointer /*from*/, int /*len*/); > | extern _X_EXPORT void RegisterAuthorizations(void); > | #endif > > A wild guess would be the “touch” added to configure leading to an > up-to-date target. Also, I'm not sure it's a good idea to ship > sdksyms.c in the tarball? (It was shipped already in rc3 and before, > but that didn't lead to any issues.) It should get run every time config.status is run, which is every time configure runs. So, sdksyms.dep should get updated exactly when the Makefiles do. I do agree that sdksyms.c shouldn't be shipped in the tarball, but I think it should work anyway (patch attached). If you unpack and run configure, that should create a sdksyms.dep newer than sdksyms.c. Here's what I got after disting a tarball, unpacking and running configure: -rw-r--r--. 1 dan dan 213787 Feb 26 08:29 hw/xfree86/loader/sdksyms.c -rw-r--r--. 1 dan dan 0 Feb 26 08:30 hw/xfree86/loader/sdksyms.dep -rwxr-xr-x. 1 dan dan 7549 Feb 14 17:21 hw/xfree86/loader/sdksyms.sh And when I run make, sdksyms.sh is run first and then sdksyms.c is built. Can you check if that's the case on your error? Or, if you manually run sdksyms.sh again, does the error go away? You may be right, though. sdksyms.c doesn't explicitly depend on sdksyms.dep, so if they're both there on the first run, then make may decide to skip generating them. -- Dan From d37506472470436db3c0302ebf01b6082261fd87 Mon Sep 17 00:00:00 2001 From: Dan Nicholson Date: Sat, 26 Feb 2011 08:34:27 -0800 Subject: [PATCH] xfree86: Don't distribute sdksyms.c The contents of sdksyms.c are dependent on configuration, so they should be freshly generated each time and not shipped in the tarball. Signed-off-by: Dan Nicholson --- hw/xfree86/loader/Makefile.am |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/hw/xfree86/loader/Makefile.am b/hw/xfree86/loader/Makefile.am index 7f386cc..f9cc858 100644 --- a/hw/xfree86/loader/Makefile.am +++ b/hw/xfree86/loader/Makefile.am @@ -17,7 +17,8 @@ libloader_la_SOURCES = \ loaderProcs.h \ loadext.c \ loadmod.c \ - os.c \ + os.c +nodist_libloader_la_SOURCES = \ sdksyms.c libloader_la_LIBADD = $(DLOPEN_LIBS) -- 1.7.3.4 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PULL] Server build fixes
On Sat, 26 Feb 2011 15:33:20 +0100, Cyril Brulebois wrote: > I fear that the sdksyms part is broken. If one builds with some > options different than the ones used to generate the tarball, the file > isn't generated again, leading to such issues. Looks like sdksyms.c should be stuck in nodist_libloader_la_SOURCES so that it doesn't get distributed. Nothing has changed here in a long time, so I'm a bit confused why this cropped up so soon with 1.10.0; the sdksyms.c stuff was added over two years ago. A 'make clean' before 'make' will resolve the issue for the existing 1.10 package. > A wild guess would be the “touch” added to configure leading to an > up-to-date target. Also, I'm not sure it's a good idea to ship > sdksyms.c in the tarball? (It was shipped already in rc3 and before, > but that didn't lead to any issues.) I read through the automake docs and they suggest placing a dependency on the generated configuration header file. We've got several, but there's the auto-generated do-not-use-config.h which holds all of the cpp defines which sdksyms.c may use. I think this is what we want: diff --git a/hw/xfree86/loader/Makefile.am b/hw/xfree86/loader/Makefile.am index 7f386cc..0e5b304 100644 --- a/hw/xfree86/loader/Makefile.am +++ b/hw/xfree86/loader/Makefile.am @@ -12,18 +12,21 @@ EXTRA_DIST = \ loaderProcs.h \ sdksyms.sh +nodist_libloader_la_SOURCES = \ + sdksyms.c + libloader_la_SOURCES = \ loader.c \ loaderProcs.h \ loadext.c \ loadmod.c \ - os.c \ - sdksyms.c + os.c + libloader_la_LIBADD = $(DLOPEN_LIBS) CLEANFILES = sdksyms.c sdksyms.dep -sdksyms.dep sdksyms.c: sdksyms.sh +sdksyms.dep sdksyms.c: sdksyms.sh $(top_builddir)/include/do-not-use-config.h CPP='$(CPP)' AWK='$(AWK)' $(srcdir)/sdksyms.sh $(top_srcdir) $(AM_CFLAGS) $(CFLAGS) $(INCLUDES) SDKSYMS_DEP = sdksyms.dep -- keith.pack...@intel.com pgpODS5BKG9eO.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PULL] Server build fixes
Hi, Keith Packard (25/02/2011): > On Fri, 25 Feb 2011 06:43:58 -0800, Dan Nicholson wrote: > > > Dan Nicholson (2): > > xfree86: Allow sdksyms.dep to be included portably > > dmx: Construct paths in doxygen.conf to fix VPATH builds > > Merged. >780a77a..6b951de master -> master I fear that the sdksyms part is broken. If one builds with some options different than the ones used to generate the tarball, the file isn't generated again, leading to such issues. Example: | CC sdksyms.lo | ../../../../hw/xfree86/loader/sdksyms.c:416: error: 'AugmentSelf' undeclared here (not in a function) | ../../../../hw/xfree86/loader/sdksyms.c:417: error: 'RegisterAuthorizations' undeclared here (not in a function) if xdcmp is disabled, since in include/os.h we have: | #if XDMCP | extern _X_EXPORT void AugmentSelf(pointer /*from*/, int /*len*/); | extern _X_EXPORT void RegisterAuthorizations(void); | #endif A wild guess would be the “touch” added to configure leading to an up-to-date target. Also, I'm not sure it's a good idea to ship sdksyms.c in the tarball? (It was shipped already in rc3 and before, but that didn't lead to any issues.) KiBi. signature.asc Description: Digital signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PULL] Server build fixes
On Fri, 25 Feb 2011 06:43:58 -0800, Dan Nicholson wrote: > Dan Nicholson (2): > xfree86: Allow sdksyms.dep to be included portably > dmx: Construct paths in doxygen.conf to fix VPATH builds Merged. 780a77a..6b951de master -> master -- keith.pack...@intel.com pgpOEr02XLbPd.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PULL] Server build fixes
On Fri, 2011-02-25 at 11:02 -0800, Keith Packard wrote: > Right, this fails only when building out-of-tree directly from git, > not > From a tarball. > The doxygen generated html files are stuffed in the tarball. Doxygen is not invoked when building from a tarball. signature.asc Description: This is a digitally signed message part ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PULL] Server build fixes
On Fri, 25 Feb 2011 18:03:44 +, Daniel Stone wrote: > Try doing the initial ./configure from out-of-tree: it should fail > then. Right, this fails only when building out-of-tree directly from git, not From a tarball. The fix isn't perfect -- there's a missing dependency issue which can be seen by building with -j5. Seems to work fine -j1. -- keith.pack...@intel.com pgpv5HhMzEKLZ.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PULL] Server build fixes
On Fri, 2011-02-25 at 08:59 -0800, Keith Packard wrote: > So, I'm a bit confused here -- I do 'make distcheck' to build > releases, > and it works for me. I'd like to know how I can test this patch to > make > sure it does what you expect. > The failing scenario involves builds where srcdir != builddir. Automake calls this a VPATH build. http://www.gnu.org/software/automake/manual/automake.html#VPATH-Builds This type of build addresses a requirement where multiple binaries can be generated from a single source tree by modulating the configuration. For example a build with dri and without dri. The distcheck target uses a VPATH build to build and install the package. It can find errors that are not found during a regular build because it builds from "a virtual tarball from makefile" rather than the source on disk. A classic error is new header file that was not added in the makefile. A developer, or most likely a distro, can use a VPATH setup to build. They can also run distcheck from this VPATH build. This is the failing scenario as I understand it. The test case is to build xserver from a VPATH build and then run distcheck. A VPATH build can be created this way: xserver$ make distclean xserver$ mkdir build && cd build xserver/build$ ../configure --prefix whatever # note the ../ xserver/build$ make distcheck You need to run distclean from your source tree to clean the current configuration. Create a build directory where binaries will be generated. Run the "configure" script located in the source tree from the build tree. No need to autogen, we are not re-creating the configuration. Just like for a source tree, you don't need to "make" the build directory, just run distcheck. You have a set of tarballs in the build dir, not srcdir. You can run distclean from the build dir, go back to the srcdir and configure it, and resume using it. signature.asc Description: This is a digitally signed message part ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PULL] Server build fixes
On Fri, Feb 25, 2011 at 09:53:00AM -0800, Keith Packard wrote: > On Fri, 25 Feb 2011 18:04:56 +0100, Cyril Brulebois wrote: > > Keith Packard (25/02/2011): > > > So, I'm a bit confused here -- I do 'make distcheck' to build > > > releases, and it works for me. I'd like to know how I can test this > > > patch to make sure it does what you expect. > > > > Do you end up building with devel docs, so with doxygen support when > > you're running make distcheck? > > Yeah, I try to build as much as I can: > > (from config.log) > > $ ./configure --enable-maintainer-mode --prefix=/local/xorg --enable-docs > --enable-devel-docs --enable-kdrive --enable-dmx > > I even took the resulting tarball and did a separate o-o-t build with > --enable-devel-docs and that seemed to work just fine. Here's one of the > xmlto commands that it ran: > > /usr/bin/xmlto --searchpath > /home/keithp/tmp/test-build/xorg-server-1.9.99.903/build/doc/xml -m > /usr/share/sgml/X11/xorg.xsl --stringparam > html.stylesheet=/usr/share/sgml/X11/xorg.css xhtml-nochunks > ../../../../hw/dmx/doc/dmx.xml Try doing the initial ./configure from out-of-tree: it should fail then. Cheers, Daniel signature.asc Description: Digital signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PULL] Server build fixes
On Fri, 25 Feb 2011 18:04:56 +0100, Cyril Brulebois wrote: > Keith Packard (25/02/2011): > > So, I'm a bit confused here -- I do 'make distcheck' to build > > releases, and it works for me. I'd like to know how I can test this > > patch to make sure it does what you expect. > > Do you end up building with devel docs, so with doxygen support when > you're running make distcheck? Yeah, I try to build as much as I can: (from config.log) $ ./configure --enable-maintainer-mode --prefix=/local/xorg --enable-docs --enable-devel-docs --enable-kdrive --enable-dmx I even took the resulting tarball and did a separate o-o-t build with --enable-devel-docs and that seemed to work just fine. Here's one of the xmlto commands that it ran: /usr/bin/xmlto --searchpath /home/keithp/tmp/test-build/xorg-server-1.9.99.903/build/doc/xml -m /usr/share/sgml/X11/xorg.xsl --stringparam html.stylesheet=/usr/share/sgml/X11/xorg.css xhtml-nochunks ../../../../hw/dmx/doc/dmx.xml -- keith.pack...@intel.com pgpLYNqhUEeaf.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PULL] Server build fixes
Keith Packard (25/02/2011): > So, I'm a bit confused here -- I do 'make distcheck' to build > releases, and it works for me. I'd like to know how I can test this > patch to make sure it does what you expect. Do you end up building with devel docs, so with doxygen support when you're running make distcheck? KiBi. signature.asc Description: Digital signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PULL] Server build fixes
On Fri, 25 Feb 2011 06:43:58 -0800, Dan Nicholson wrote: > dmx: Construct paths in doxygen.conf to fix VPATH builds > > The paths in doxygen.conf assumed that srcdir=builddir and broke > otherwise. Use autoconf to fill in the paths to the srcdir so that the > files can be found when users have a separate build directory (as with > distcheck). So, I'm a bit confused here -- I do 'make distcheck' to build releases, and it works for me. I'd like to know how I can test this patch to make sure it does what you expect. -- keith.pack...@intel.com pgp2YXjlZAeU2.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
