>>> <[EMAIL PROTECTED]> writes:
[...]
>> Wow. Did you changed something in your configure.in and
>> Makefile.am's during this jump?
> No, we changed nothing. Should we ?
Not necessarily. These tools should be backward compatible
(althought they sometime failed to).
[...]
> In the whole project directory (and all subdirectories) you
> find neither a *.P* file nor a .deps directory.
Odd.
[...]
>> To summarize
>>
>> % cd obj/gcc_2.95.3-release-GL; ../../configure --youroptions
>>
>> does not create some (or all?) of the .deps/*.P* files, while
>>
>> % ./configure --youroptions
>>
>> successfully creates everything required. Is this correct?
> No. We wrote an autoconf macro to rerun configure
> automatically in obj/gcc_2.95.3-release-GL during a configure
> run which is started in the project root directory. The users
> like this. So the only command you have to start is
> ./configure in the project root directory.
Any chance we can see this macro? Actually I'd like to know the
exact sequence of commands which are being run. From your
description I understand something more or less like this:
if test x"$srcdir" = x'.'; then
for comp in gcc_2.95.3 ...; do
for rel in release debug ...; do
for lib in GL mesa ...; do
dir=$comp-$rel-$lib
mkdir -p obj/$dir
(cd obj/$dir &&
../../configure --with-comp=$comp --with-rel=$rel --with-lib=$lib)
done
done
done
exit
fi
Also, now I don't really undestand what you meant with the
following:
>>> If I try to build the software without this extra object
>>> directory the .deps directories are created.
Is this a build with that macro disabled?
[...]
>> % rm -Rf kernel/framework/.deps
>> % ./config.status kernel/framework/Makefile depfiles
> On my system, this does absolutely nothing.
Please, send the output of
% ./config.status --help
and
% rm -Rf kernel/framework/.deps
% sh -x ./config.status kernel/framework/Makefile depfiles
[...]
--
Alexandre Duret-Lutz
