[Nouveau] [Mesa3d-dev] makedepend in Mesa

[Dan Nicholson]

On Thu, Feb 25, 2010 at 11:18 AM, Xavier Chantry
<chantry.xavier at gmail.com> wrote:
> On Tue, Feb 23, 2010 at 11:14 PM, Dan Nicholson <dbn.lists at 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