symlinks and dependancy tracking (was Re: [patch] stephen's staging headers patch)

[Phil Edwards]

On Tue, Jul 03, 2001 at 09:17:17AM -0400, Stephen M.Webb wrote:
> The problem with soft links is (as far as my experience goes), they don't
> support dependency tracking by timestamp.  If files are soft linked and I
> change one, the timestamp of the link itself does not change, make
> fails to notice the change, and things don't get rebuilt.  Of course, I haven't
> tried this in practice, so I don't know if it's really a problem or not.

It may be a GNU make feature.  Here's an example using GNU make 3.79.1,
with an obvious dependance and a rule that prints 'Updating' as it works:

    % ls
    fake/  real/
    % ls -lF *
    fake:
    total 4
    -rw-rw-r--    1 pme         49 Jul  3 13:10 Makefile
    lrwxrwxrwx    1 pme         14 Jul  3 13:09 real.c -> ../real/real.c
    real:
    total 4
    -rw-rw-r--    1 pme          9 Jul  3 13:11 real.c
    % cd fake
    % gmake
    Updating.
    % ls -lF
    total 8
    -rw-rw-r--    1 pme         49 Jul  3 13:10 Makefile
    lrwxrwxrwx    1 pme         14 Jul  3 13:09 real.c -> ../real/real.c
    -rw-rw-r--    1 pme         10 Jul  3 13:13 real.o
    % gmake
    gmake: `real.o' is up to date.

Okay, initial dependancy checks work.  Now we wait a bit and update the
source file.

    % sleep 60
    % touch ../real/real.c
    % ls -lF
    total 8
    -rw-rw-r--    1 pme         49 Jul  3 13:10 Makefile
    lrwxrwxrwx    1 pme         14 Jul  3 13:09 real.c -> ../real/real.c
    -rw-rw-r--    1 pme         10 Jul  3 13:13 real.o
    % ls -lLF
    total 12
    -rw-rw-r--    1 pme         49 Jul  3 13:10 Makefile
    -rw-rw-r--    1 pme          9 Jul  3 13:14 real.c
    -rw-rw-r--    1 pme         10 Jul  3 13:13 real.o

Okay, the symlink hasn't changed, but following the symlink shows that
the real file is indeed newer...

    % gmake
    Updating.
    % gmake
    gmake: `real.o' is up to date.
    % ls -lF
    total 8
    -rw-rw-r--    1 pme         49 Jul  3 13:10 Makefile
    lrwxrwxrwx    1 pme         14 Jul  3 13:09 real.c -> ../real/real.c
    -rw-rw-r--    1 pme         10 Jul  3 13:15 real.o
    %

...and the dependant file is remade correctly.  So we'd be okay here (and
I've noticed this myself, working in the target_alias/libstdc++-v3/src
builddir).  I don't have access to the Suns at the moment, so I can't say
whether the same thing would happen using Sun make (or anything other than
GNU make).

(Idle thought:  I wonder if there's an autoconf test for this feature?
If we can test the 'make' in use, and the feature is not present, we can
force the LN_S variable to not do symlinks and insure correctness.  Again,
I'm making the same assumption here that I initially made back when we
started checking for GNU make:  that the 'make' used during configure is
the same 'make' used during build.  (If it isn't, I say it's the user's
fault for playing games midstream. :-)  There's an archive of autoconf
macros, but it was down last time I checked.)


Phil

-- 
Would I had phrases that are not known, utterances that are strange, in
new language that has not been used, free from repetition, not an utterance
which has grown stale, which men of old have spoken.
                                     - anonymous Egyptian scribe, c.1700 BC