Re: [Nouveau] [Mesa3d-dev] makedepend in Mesa
On Fri, Mar 19, 2010 at 12:23 PM, Xavier Chantry chantry.xav...@gmail.com wrote: On Thu, Feb 25, 2010 at 9:41 PM, Dan Nicholson dbn.li...@gmail.com wrote: diff --git a/configure.ac b/configure.ac index 485836a..a582337 100644 --- a/configure.ac +++ b/configure.ac @@ -28,8 +28,11 @@ AC_PROG_CPP AC_PROG_CC AC_PROG_CXX AC_CHECK_PROGS([MAKE], [gmake make]) -AC_PATH_PROG([MKDEP], [makedepend]) AC_PATH_PROG([SED], [sed]) +AC_PATH_PROG([MKDEP], [makedepend], no) +if test x$MKDEP = xno; then + AC_MSG_ERROR([makedepend not found]) +fi Yep, that would do it. In fact, when I wrote configure.ac originally, I wanted it to be a hard requirement and assumed that AC_PATH_PROG would error by default if it didn't find the program. Should I resubmit a proper git patch ? Sure. I have been running with makedepend installed on my 3 systems for 1 month, it has worked very well. I don't think I got ONE weird failure in the past month, while I used to get more than once per week. The only thing I need is to sometimes run autogen.sh and/or configure, when there are some structure changes (e.g. nv30-nv40 merge to nvfx). AFAIK this is also handled automatically in other projects. But this is much less annoying, because it fails at build time, instead of segfaulting at runtime. Yeah, automatic autotools updates could maybe be handled in the top-level Makefile, but really that's more of a job that automake takes care of. Everyone complains about mesa crappy build system so I thought all the failures I got were expected. Now I see they weren't, just that makedepend is badly required :) I am just worried some people might run into the same troubles as me. But I wonder if there are any since only Dan answered in that thread. The only drawback I know of is adding a hard requirement on makedepend where there wasn't one before, but distros usually have it. -- Dan ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [Intel-gfx] [PATCH 3/3] libdrm: Move all noninstalled headers to noinst_HEADERS.
On Fri, Mar 12, 2010 at 4:50 AM, Pauli Nieminen suok...@gmail.com wrote:
Cleanup make system so that all noninstalled headers are put
to noinst_HEADERS. This quarentees that header will be present
in tar ball but not installed with make install.
CC: nouveau@lists.freedesktop.org
Signed-off-by: Pauli Nieminen suok...@gmail.com
---
Makefile.am | 6 +++---
intel/Makefile.am | 10 ++
nouveau/Makefile.am | 4 +++-
3 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/Makefile.am b/Makefile.am
index e434e1d..61da186 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -55,13 +55,13 @@ libdrm_la_SOURCES = \
xf86drmHash.c \
xf86drmRandom.c \
xf86drmSL.c \
- xf86drmMode.c \
- libdrm_lists.h
+ xf86drmMode.c
libdrmincludedir = ${includedir}
libdrminclude_HEADERS = xf86drm.h xf86drmMode.h
-noinst_HEADERS = xf86atomic.h
+noinst_HEADERS = xf86atomic.h \
+ libdrm_lists.h
EXTRA_DIST = libdrm.pc.in include/drm/*
diff --git a/intel/Makefile.am b/intel/Makefile.am
index 9add505..d56b03a 100644
--- a/intel/Makefile.am
+++ b/intel/Makefile.am
@@ -36,14 +36,16 @@ libdrm_intel_la_LIBADD = ../libdrm.la @PTHREADSTUBS_LIBS@
@CLOCK_LIB@
libdrm_intel_la_SOURCES = \
intel_bufmgr.c \
- intel_bufmgr_priv.h \
intel_bufmgr_fake.c \
intel_bufmgr_gem.c \
- intel_chipset.h \
- mm.c \
- mm.h
+ mm.c
libdrm_intelincludedir = ${includedir}
libdrm_intelinclude_HEADERS = intel_bufmgr.h
+noinst_HEADERS = \
+ intel_bufmgr_priv.h \
+ intel_chipset.h \
+ mm.h
+
pkgconfig_DATA = libdrm_intel.pc
diff --git a/nouveau/Makefile.am b/nouveau/Makefile.am
index 5d759c5..53099eb 100644
--- a/nouveau/Makefile.am
+++ b/nouveau/Makefile.am
@@ -18,7 +18,6 @@ libdrm_nouveau_la_SOURCES = \
nouveau_notifier.c \
nouveau_bo.c \
nouveau_resource.c \
- nouveau_private.h \
nouveau_reloc.c
libdrm_nouveaucommonincludedir = ${includedir}/nouveau
@@ -38,5 +37,8 @@ libdrm_nouveauincludedir = ${includedir}/drm
libdrm_nouveauinclude_HEADERS = \
nouveau_drmif.h
+noinst_HEADERS = \
+ nouveau_private.h
+
pkgconfigdir = @pkgconfigdir@
pkgconfig_DATA = libdrm_nouveau.pc
I don't think this is the best strategy. Having the headers under
_SOURCES already means they'll get distributed. The only reason for
the separate _HEADERS declarations is if you need to install them.
http://www.gnu.org/software/automake/manual/automake.html#Headers
--
Dan
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [Mesa3d-dev] makedepend in Mesa
On Tue, Feb 23, 2010 at 1:29 PM, Xavier Chantry chantry.xav...@gmail.com wrote: While keeping up-to-date the nouveau mesa driver (either classic or gallium), or doing regression testing, the big majority of my rebuilds resulted in segfaults. I am not talking about autogen or configure detection. I believe this also works automatically in other projects and doesn't with mesa, but forgetting to do this usually causes a build failure. Then autogen/configure can be run and make can resume the build. What is more problematic is when an apparently successful build does not work. The reply I used to get is just to make clean or distclean/realclean. clean is usually works, but rebuilding everything takes time. And regression testing needs a lot of rebuilding :) Anyway I found this IRC discussion yesterday quite interesting : 20:30 * jbarnes curses the mesa build system 20:31 jbarnes change intel_fbo.h, nothing rebuilds 20:32 Dr_Jakob makedepend installed? 20:33 jbarnes yeah but it looks like we don't symlink intel_fbo.h into i915 and include it in the makefile 20:33 jbarnes so I guess the deps don't get picked up 20:34 Dr_Jakob Hmm 20:34 jbarnes oh no I guess I don't have makedepend 20:34 -!- jsgf [~jer...@adsl-69-107-81-54.dsl.pltn13.pacbell.net] has joined #dri-devel 20:34 * jbarnes tries again with that installed 20:35 jbarnes don't most projects just use gcc's dep tracking? 20:35 Dr_Jakob yes 20:36 Dr_Jakob I tried to add that but it mostly turned into fail. We could use gcc directly for depends (I have a patch to do it), but: 1. I don't think it would actually help much in terms of rebuilds since makedepend seems to do a perfectly adequate job of finding the needed headers. 2. gcc expects to output a single make target for a single source file. mesa just tosses all the source files at makedepend which generates a depend file with a bunch of targets. gcc is phenomenally slow doing the same. Changing the build to include one dep file per source file would be a ton of churn. 3. The fast way automake does gcc dep tracking is to do it as a step during the compile. Since gcc fully preprocesses the source file before generating the make target, you can get it for free during the compile. Doing as a separate step like mesa means you're throwing away the preprocessing and then doing it again immediately afterward. The time adds up. I guess what I'm saying is that I wouldn't bother with gcc dep tracking unless it's coming as part of automake. 20:37 jbarnes Dr_Jakob: you guys mostly build with scons these days right? 20:37 jbarnes and that has a separate set of files for tracking sources? 20:37 Dr_Jakob For windows yes, but I use make for linux. 20:37 Dr_Jakob Then again I'm pretty good at installing makedepend ;-) 20:37 jbarnes heh 20:39 Dr_Jakob I don't often have to do a make clean. 20:40 suokko I guess there is something broken in radeon makefiles because make clean is required quite often 20:40 suokko Luckily ccache is very fast 20:40 MostAwesomeDude Yeah, ccache is a much better friend than makedepend. 21:48 shining still not very clear to me, should everyone have makedepend installed for building mesa ? 21:49 Dr_Jakob it is higly recommended yes. 21:51 shining does it help with mesa build failures ? I have seen many many times in #nouveau weird mesa behavior because of build failure, and a make distclean/realclean fixed it 21:51 shining sorry its not build failure 21:51 Dr_Jakob yes 21:51 shining it *seems* to build fun but it doesnt work correctly, most of the time it simply segfaults 21:52 shining huh 21:52 shining s/fun/fine 21:54 suokko shining: Problem without makedepend is that in rebuild make doesn't build all files that should be rebuild because it doesn't know about included files. So if you link old and new object files and some memory layout changed you will get segfaults 22:49 shining then I would workaround it by requiring makedepend 22:51 zackr we don't have a configure step so you'll need to most likely rewrite the build system to do that I probably should look into ccache (and I probably will), but if makedepend improves the rebuild situation, I believe it should be better advertised. And unless I am mistaken, mesa does have a configure step, I even believed most people use that. So my simple suggestion would be to simply print a warning if makedepend is not detected. configure checks for makedepend, but doesn't error if it's not found. It probably should. Likewise, the commands running makedepend should probably not be silenced with stderr redirected to /dev/null. That would break builds for people using the static configs without makedepend. I saw a report saying make clean was still needed with makedepend installed, but maybe not every parts of mesa uses makedepend correctly, like the nouveau driver ? I think the problem is more that
