[Gc]: Dependency tracking for configuration macros
urkedal at nbi.dk
Mon Oct 12 12:16:41 PDT 2009
On 2009-10-12, Andreas Tobler wrote:
> Petter Urkedal wrote:
> > On 2009-10-11, Andreas Tobler wrote:
> >> Petter Urkedal wrote:
> >>> On 2009-10-10, Andreas Tobler wrote:
> >>>> Hm, confused. From my point of view it has nothing to do with gcc. The
> >>>> .deps/atomic_ops.Plo gets created during the configure stage, and there
> >>>> gcc is only invoked for conftests. So I guess there must be some other
> >>>> magic.
> >>> In my case configure only creates dummy files so that "make" does not
> >>> complain about the includes. At least for GCC I think the actual
> >>> dependencies are created by the compiler, replacing those files.
> >> Just for the record, in libatomic_ops/.deps/ I have the 'dummy' entries.
> >> I was speaking about the toplevel .deps/
> > That's probably because they existed before running configure. If you
> > remove the .Plo files from the toplevel .deps/, then configure will
> > re-create them as stubs. The subs in libatomic_ops/.deps will never be
> > replaced since we have disabled recursive make in libatomic_ops. In
> > fact, "AC_CONFIG_SUBDIRS([libatomic_ops])" is currently redundant.
> Thank you! I didn't realize that 'rm -rf *' did _not_ remove the .deps.
> Now after cleaning them out I can build w/o errors. Tests also run fine.
Excellent. This had me really puzzled.
(A little friendly off-topic advice: I guess your home directory is
still intact, but it's best not to mix "rm -rf" with wildcards, since
there are some nasty surprises. One is that ".*" matches "..", which
has quite predictable consequences once you think twice about it.
Another is that "rm -rf" will follow symbolic links listed on the
command line and recursively remove whatever they're pointing to.)
More information about the Gc