Long time, and "make"

[technolope]

It's been over a month since I've logged a journal entry here. Life is changing a lot, and I am having difficulties keeping up with it. Compound that with multiple major computer hardware failures in the last two weeks and a visit from my parents and you'll see why I've been too frazzled to write

Comments

[mrgeddylee]

Did you run "make -d -m" or "make -d -n"? You said -m, and if that's what you actually ran, then it just rebuilt libOmegaFlow.a for you, which means your timestamps don't prove anything that I can recognize.

[technolope]

Whoops, I meant "-d -n" (the option to have make *not* actually run the commands).

[mrgeddylee]

I don't run Make much anymore, but I was suspicious when I saw

ar rcs libOmegaFlow.a build/*.o slatec/*.o naca/*.o
Successfully remade target file `libOmegaFlow.a'.

in the output you pasted.

[technolope]

I made sure to check the timestamps before and after running "make -d -n", and they are the same. I am at a loss.

[jesus_jeff]

the gmake release notes mention that although gmake uses nanosecond times, some other tools don't keep those times. 'cp -p' and ar are notable in that respect.
hat *set* timestamps do
not preserve micro- or nano-second granularity. This means that "cp -p"
and other similar tools (tar, etc.) may not exactly duplicate timestamps
with micro- and nano-second granularity on some systems. If your build
system contains rules that depend on proper behavior of tools like "cp
-p", you should consider using the .LOW_RESOLUTION_TIME pseudo-target to
force make to treat them properly. See the manual for details.