[Nouveau] [Mesa3d-dev] makedepend in Mesa
dbn.lists at gmail.com
Tue Feb 23 14:14:15 PST 2010
On Tue, Feb 23, 2010 at 1:29 PM, Xavier Chantry
<chantry.xavier at 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 [~jeremy at 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
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
> 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 it's not used consistently since it
has to be setup manually in the Makefile vs. automatically like
> diff --git a/configure.ac b/configure.ac
> index 485836a..ba5f267 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1441,6 +1441,11 @@ echo " CFLAGS: $cflags"
> echo " CXXFLAGS: $cxxflags"
> echo " Macros: $defines"
> +if test "x$MKDEP" = x; then
> + echo ""
> + echo " warning: makedepend is not installed, so it is
> recommended to make distclean after any code change."
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.
More information about the Nouveau