automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Re: automake dependencies, missing *.Plo files


From: joachim.j.gloger
Subject: Re: Re: automake dependencies, missing *.Plo files
Date: Tue, 9 Apr 2002 13:31:38 +0200

Hi,

thank you very much for your reply and your detailed questions. I try to answer 
them as good as possible.

Here we go.

> >>>   <address@hidden> writes:
>
>  > Hi,
>  > we just upgrading to
>
>  > automake 1.6        (from 1.4)
>  > autoconf 2.53       (from 2.13)
>  > libtool 1.4.2       (from 1.3.5)
>
> Wow.  Did you changed something in your configure.in and
> Makefile.am's during this jump?

No, we changed nothing. Should we ?

>
>  > and now the package won't compile anymore. I guess that the
>  > dependency mechanism has somewhat changed.
>
> Indeed, see http://sources.redhat.com/automake/dependencies.html
> for an overview.

I read this, but for my problem it did not help me very much.

>
>  > The configuration of our software package is as follows. We
>  > are using an 'obj/gcc_2.95.3-release-GL' directory to store
>  > the .o files and the libs (We do not like to keep them in the
>  > source code directory). The configure command runs ok and put
>  > the Makefiles in the obj/gcc_2.95.3-release-GL
>  > directories. The problem is that a subsequent 'make' command
>  > stops immediately:
>
>  > make -C 
/servers/ockham_fs1/gloger/develop/LabFramework/obj/gcc_2.95.3-release-GL/. all
>  > make[1]: Entering directory 
`/servers/ockham_fs1/gloger/develop/LabFramework/obj/gcc_2.95.3-release-GL'
>  > Making all in kernel
>  > make[2]: Entering directory 
`/servers/ockham_fs1/gloger/develop/LabFramework/obj/gcc_2.95.3-release-GL/kerne
l'
>  > Making all in framework
>  > make[3]: Entering directory  
`/servers/ockham_fs1/gloger/develop/LabFramework/obj/gcc_2.95.3-release-GL/kerne
l/framework'
>  > Makefile:221: .deps/BaseData.Plo: No such file or directory
>  > Makefile:222: .deps/BaseInspector.Plo: No such file or directory
>  > Makefile:223: .deps/BaseViewer.Plo: No such file or directory
>  > Makefile:224: .deps/BaseViewerPanel.Plo: No such file or directory
>  > Makefile:225: .deps/CommonInspectors.Plo: No such file or directory
>  > Makefile:226: .deps/DataHandler.Plo: No such file or directory
>  > Makefile:227: .deps/Defaults.Plo: No such file or directory
>  > Makefile:228: .deps/DirCache.Plo: No such file or directory
>  > Makefile:229: .deps/Exception.Plo: No such file or directory
>  > Makefile:230: .deps/InspectorHandler.Plo: No such file or directory
>  > Makefile:231: .deps/LabPainter.Plo: No such file or directory
>  > Makefile:232: .deps/QtDefaultSupport.Plo: No such file or directory
>  > Makefile:233: .deps/ViewerHandler.Plo: No such file or directory
>  > make[3]: *** No rule to make target `.deps/ViewerHandler.Plo'.  Stop.
>  > make[3]: Leaving directory 
`/servers/ockham_fs1/gloger/develop/LabFramework/obj/gcc_2.95.3-release-GL/kerne
l/framework'
>  > make[2]: *** [all-recursive] Error 1
>  > make[2]: Leaving directory 
`/servers/ockham_fs1/gloger/develop/LabFramework/obj/gcc_2.95.3-release-GL/kerne
l'
>  > make[1]: *** [all-recursive] Error 1
>  > make[1]: Leaving directory 
`/servers/ockham_fs1/gloger/develop/LabFramework/obj/gcc_2.95.3-release-GL'
>  > make: *** [all] Error 2
>
>  > Obviously it do not find the *.Plo files in one of the
>  > 'obj/gcc_2.95.3-release-GL' directories. Those files are not
>  > created at all. I checked this with the find command.
>
> More precisely, did you mean that there is no .deps/*.P*
> created at all, or only those from kernel/framework/ are
> missing?

In the whole project directory (and all subdirectories) you find neither a *.P* 
file nor a .deps directory.

>
> Does the kernel/framework/.deps/ directory exist? What does it
> contain?

No, it does not exist, so it contains nothing.

>
>  > If I try to build the software without this extra object
>  > directory the .deps directories are created.
>
> 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.

Beside that this macro creates for every compiler version and every debug resp. 
release version and for every OpenGL resp. Mesa version of the project an own 
object directory which resides in the directory 'obj' (gcc_2.95.3-release-GL is 
only one of them). After the creation it makes a cd into the created directory 
and starts 'configure' in the project root directly from the macro (more or 
less recursively).

>
> (It's not clear to me whether you was using a VPATH build, i.e.,
> ../../configure as described above; or a maze of symlinks as
> I've seen some people using; or even something else.)

I think the last option (even something else). I hope that the above statements 
makes things clearer.

>
>  > The old automake/autoconf/libtool combination did not fail at all.
>
>  > Any ideas what's going wrong?
>
> No, but here are a few hints.
>
> If you edit configure and uncomment the following line near the end
>
>     # echo "creating $dirpart/$file"
>
> it will print the name of every *.P* it creates.

I did it and run './configure' but it prints nothing.

>
> Actually, these *.P* files are created by config.status for
> each directory it creates an Automake Makefile in.
> (BTW, make sure `./config.status --help' lists the relevant
> Makfiles in the `Configuration files' section).
>
> You can request the creation of the *.P* files for a given
> directory by running
>
>  % rm -Rf kernel/framework/.deps
>  % ./config.status kernel/framework/Makefile depfiles

On my system, this does absolutely nothing.

>
> If this fails to create the files in one setup and succeed in
> the other, then you could rerun this with `sh -x' and compare
> the trace for both cases.
>
> Ah, last question: what sed version are you using?  (Just to
> make sure it's not the same problem as
> http://sources.redhat.com/ml/bug-automake/2001/msg00584.html)

We uses sed 3.02


Regards
Joachim

=========================================================== 
J. M. Gloger, DaimlerChrysler AG, Research Center Ulm 
P.O. Box 2360, 89013 Ulm, Germany 

Phone: +49 731 505 2353 
Fax:   +49 731 505 4113 
Email: address@hidden 

                                              walk the talk 
=========================================================== 


reply via email to

[Prev in Thread] Current Thread [Next in Thread]