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
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 it's not used consistently since it
has to be setup manually in the Makefile vs. automatically like
automake.
> 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."
> +fi
> +
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.
--
Dan