On Thu, Feb 25, 2010 at 11:18 AM, Xavier Chantry <chantry.xav...@gmail.com> wrote: > On Tue, Feb 23, 2010 at 11:14 PM, Dan Nicholson <dbn.li...@gmail.com> wrote: >> >> 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. >> > > Thanks for all these explanations ! > >> >> 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. >> > > Why do we need static configs ? > If I understand correctly, we have the choice between 1 autoconf file, > and more than 100 static config files ? > And autoconf can potentially capture all these static configurations and more > ?
Because a lot of the vmware guys use the static configs. They like being able to just do "make linux". >> I think the problem is more that it's not used consistently since it >> has to be setup manually in the Makefile vs. automatically like >> automake. >> > > My understanding of autotools is still very limited. mesa currently > doesn't use automake, does it ? > A git grep automake lets me believe that it was dropped in 5.1 Yeah, we just use autoconf to generate configs/autoconf. After that it's treated just like one of the static configs. All the Makefiles are manual. > So currently makedepend needs to be setup manually in all the Makefiles ? > > And using automake would give a big advantage on the two sides : > 1) automatic makedepend setup > 2) efficient use of gcc dep tracking > ? Right, except automake doesn't use makedepend. It does the equivalent with gcc's generation of make dependency rules. Look for the -M option in gcc(1). Using automake and libtool would have a lot of advantages over mesa's homegrown system. The big drawback is the added complexity and the fact that Brian has historically wanted nothing to do with it. >> I'd be comfortable having makedepend be a hard requirement in >> configure. Otherwise, I'd rather have this be AC_MSG_WARN([your >> message]) right after the AC_PATH_PROG for makedepend. >> > > Actually I wanted to propose a hard requirement but then thought some > people might complain. > If I just put a AC_MSG_WARN right after AC_PATH_PROG, I am afraid it > won't make a big difference as it won't be very visible. > To make a hard requirement, I could just use AC_MSG_ERROR instead ? > > [I wonder if it wouldn't be easier to make scons work like I want to > avoid all these problems. > I believe I would just need to add nouveau support, and probably look > into this : > # TODO: Build several variants at the same time? > # http://www.scons.org/wiki/SimultaneousVariantBuilds] Well, that's for scons, which is completely independent of autoconf/configs/Makefile. I believe the vmware guys use scons primarily for building on windows, which the configs system can't handle. > 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. -- Dan ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
