Set the timestamp of files in the stage dir to the timestamp of the newest distfile. This is to support reproducable builds. Note, doesn't work on 8.x, need to find a solution to that.

[swills]

Test Plan

Already did several poudriere bulk -a on 10.1 with it, no issues, but need to
fix 8.x issue. Perhaps someone with more make(1) knowledge has suggestions.

[mat]

Mk/bsd.port.mk

5037

Is there a chance that a distfile can have it's timestamp in the future ?

[swills]

In D2032#3, @mat wrote:

Is there a chance that a distfile can have it's timestamp in the future ?

I suppose, if an upstream set the file timestamp in the future, fetch would reproduce it, why?

[mat]

In D2032#5, @swills wrote:

In D2032#3, @mat wrote:

Is there a chance that a distfile can have it's timestamp in the future ?

I suppose, if an upstream set the file timestamp in the future, fetch would reproduce it, why?

Well, some build systems will base themselves on timestamps to know when to build, or rebuild, Perl, for instance, when using ExtUtils::MakeMaker (at least) will check if the Makefile generated from running perl Makefile.PL is more recent than Makefile.PL, and Perl's Config.pm which is at /usr/local/lib/perl5/${PERL_VER}/mach/Config.pm if this file has a timestamp in the future, you can't ever build anything with ExtUtils::MakeMaker because it'll keep rebuilding the Makefile until it's more recent than Config.pm :-)

[bapt]

Mk/bsd.port.mk

5037

Taking the timestamp from distfile will work only for ports with distfiles

[emaste]

Mk/bsd.port.mk

5038–5039

what's with the empty else?

[swills]

Mk/bsd.port.mk

5037

mat: yes, if fetch replicates the timestamp, it will be in the future. bapt: yes, correct. Using the distfile timestamp seemed like the best option, but maybe there is something better?

5038–5039

Just a mistake on my part.

[emaste]

Related effort in D4385