Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Building perl reproducibly: __DATE__ and __TIME__ usage in perl.c #14860

Closed
p5pRT opened this issue Aug 17, 2015 · 22 comments
Closed

Building perl reproducibly: __DATE__ and __TIME__ usage in perl.c #14860

p5pRT opened this issue Aug 17, 2015 · 22 comments

Comments

@p5pRT
Copy link

p5pRT commented Aug 17, 2015

Migrated from rt.perl.org#125830 (status was 'resolved')

Searchable as RT125830$

@p5pRT
Copy link
Author

p5pRT commented Aug 17, 2015

From @ntyni

On Sun, Jul 12, 2015 at 10​:59​:27PM +0300, Niko Tyni wrote​:

On Sun, Jul 05, 2015 at 06​:25​:49PM -0000, Father Chrysostomos wrote​:

Niko Tyni wrote​:

Would you be willing to accept a patch that makes this __DATE__/__TIME__
usage configurable? Or would it make sense to just unconditionally
replace the message with $Config{cf_time} information, either at build
or run time?

I believe such a patch would be acceptable. Presumably you mean some-
thing like this?

#ifndef PERL_BUILD_DATE
# define PERL_BUILD_DATE __DATE__
#endif

Thanks. Yes, something like that is the minimal necessary modification,
and is implemented in the attached patch.

However, it doesn't seem to make the overriding particularly easy in
the actual build​: it requires either stuffing PERL_BUILD_DATE into
$Config{ccflags} (unnecessarily passing that down to XS modules too),
or modifying config.h after running Configure. But maybe I'm just missing
some mechanism for injecting "local" compiler flags to the build?

On the other hand, a full Configure question seems overkill for this,
particularly as Configure already provides the time stamp when it was run
(in 'cf_time'). I'd personally prefer just re-using that time stamp,
unless there's a case for a strong distinction of the two? See the other
attached patch for such an alternative implementation.

This probably got accidentally overlooked; opening a bug report about it.
The original thread starts at
http​://nntp.perl.org/group/perl.perl5.porters/229127

Re-attaching the two alternative patches.
--
Niko Tyni ntyni@​debian.org

@p5pRT
Copy link
Author

p5pRT commented Aug 17, 2015

From @ntyni

0001-Allow-overriding-the-compile-time-in-perl-V-output.patch
From f5b9f09daee93032d66c1e574d972a977ce0ac9a Mon Sep 17 00:00:00 2001
From: Niko Tyni <ntyni@debian.org>
Date: Sun, 12 Jul 2015 22:23:00 +0300
Subject: [PATCH] Allow overriding the compile time in "perl -V" output

The C preprocessor macros __DATE__ and __TIME__ embed the compile time
into the binary for the purposes of "perl -V" output. This makes the
build unreproducible: compiling the same source with the same toolchain
cannot be made to yield bitwise identical binaries and other generated
files.

The compile time can now be overridden with the PERL_BUILD_DATE macro.
---
 perl.c | 15 ++++++++++-----
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/perl.c b/perl.c
index cbb66e0..f4ceadb 100644
--- a/perl.c
+++ b/perl.c
@@ -1795,15 +1795,20 @@ S_Internals_V(pTHX_ CV *cv)
     PUSHs(Perl_newSVpvn_flags(aTHX_ non_bincompat_options,
 			      sizeof(non_bincompat_options) - 1, SVs_TEMP));
 
+#ifndef PERL_BUILD_DATE
 #ifdef __DATE__
 #  ifdef __TIME__
-    PUSHs(Perl_newSVpvn_flags(aTHX_
-			      STR_WITH_LEN("Compiled at " __DATE__ " " __TIME__),
-			      SVs_TEMP));
+#    define PERL_BUILD_DATE __DATE__ " " __TIME__
 #  else
-    PUSHs(Perl_newSVpvn_flags(aTHX_ STR_WITH_LEN("Compiled on " __DATE__),
-			      SVs_TEMP));
+#    define PERL_BUILD_DATE __DATE__
 #  endif
+#endif
+#endif
+
+#ifdef PERL_BUILD_DATE
+    PUSHs(Perl_newSVpvn_flags(aTHX_
+			      STR_WITH_LEN("Compiled at " PERL_BUILD_DATE),
+			      SVs_TEMP));
 #else
     PUSHs(&PL_sv_undef);
 #endif
-- 
2.1.4

@p5pRT
Copy link
Author

p5pRT commented Aug 17, 2015

From @ntyni

0001-Compile-Config-cf_time-into-the-perl-binary-instead-.patch
From 821d98ec9cd0611c50f0fb078d12546834ab2685 Mon Sep 17 00:00:00 2001
From: Niko Tyni <ntyni@debian.org>
Date: Sun, 5 Jul 2015 18:41:10 +0300
Subject: [PATCH] Compile $Config{cf_time} into the perl binary instead of
 __DATE__/__TIME__

Unlike the C preprocessor macros __DATE__ and __TIME__, the cf_time
value is overridable via config.over mechanism. This can be used
to make the build reproducible, so that compiling the same source
with the same toolchain always gives bitwise identical binaries
and other generated files.
---
 config_h.SH |  2 ++
 perl.c      | 11 +----------
 2 files changed, 3 insertions(+), 10 deletions(-)

diff --git a/config_h.SH b/config_h.SH
index 0d4a409..40aa3a3 100755
--- a/config_h.SH
+++ b/config_h.SH
@@ -5244,6 +5244,8 @@ sed <<!GROK!THIS! >$CONFIG_H -e 's!^#undef\(.*/\)\*!/\*#define\1 \*!' -e 's!^#un
 #$usesocks	USE_SOCKS		/**/
 #endif
 
+#define PERL_CF_TIME "$cf_time"
+
 #endif
 !GROK!THIS!
 ;;
diff --git a/perl.c b/perl.c
index cbb66e0..bf2b5ea 100644
--- a/perl.c
+++ b/perl.c
@@ -1795,18 +1795,9 @@ S_Internals_V(pTHX_ CV *cv)
     PUSHs(Perl_newSVpvn_flags(aTHX_ non_bincompat_options,
 			      sizeof(non_bincompat_options) - 1, SVs_TEMP));
 
-#ifdef __DATE__
-#  ifdef __TIME__
     PUSHs(Perl_newSVpvn_flags(aTHX_
-			      STR_WITH_LEN("Compiled at " __DATE__ " " __TIME__),
+			      STR_WITH_LEN("Configured at " PERL_CF_TIME),
 			      SVs_TEMP));
-#  else
-    PUSHs(Perl_newSVpvn_flags(aTHX_ STR_WITH_LEN("Compiled on " __DATE__),
-			      SVs_TEMP));
-#  endif
-#else
-    PUSHs(&PL_sv_undef);
-#endif
 
     for (i = 1; i <= local_patch_count; i++) {
 	/* This will be an undef, if PL_localpatches[i] is NULL.  */
-- 
2.1.4

@p5pRT
Copy link
Author

p5pRT commented Aug 18, 2015

From @tonycoz

On Mon Aug 17 09​:29​:14 2015, ntyni@​debian.org wrote​:

On Sun, Jul 12, 2015 at 10​:59​:27PM +0300, Niko Tyni wrote​:

On Sun, Jul 05, 2015 at 06​:25​:49PM -0000, Father Chrysostomos wrote​:

Niko Tyni wrote​:

Would you be willing to accept a patch that makes this
__DATE__/__TIME__
usage configurable? Or would it make sense to just
unconditionally
replace the message with $Config{cf_time} information, either at
build
or run time?

I believe such a patch would be acceptable. Presumably you mean
some-
thing like this?

#ifndef PERL_BUILD_DATE
# define PERL_BUILD_DATE __DATE__
#endif

Thanks. Yes, something like that is the minimal necessary
modification,
and is implemented in the attached patch.

However, it doesn't seem to make the overriding particularly easy in
the actual build​: it requires either stuffing PERL_BUILD_DATE into
$Config{ccflags} (unnecessarily passing that down to XS modules too),
or modifying config.h after running Configure. But maybe I'm just
missing
some mechanism for injecting "local" compiler flags to the build?

On the other hand, a full Configure question seems overkill for this,
particularly as Configure already provides the time stamp when it was
run
(in 'cf_time'). I'd personally prefer just re-using that time stamp,
unless there's a case for a strong distinction of the two? See the
other
attached patch for such an alternative implementation.

This probably got accidentally overlooked; opening a bug report about
it.
The original thread starts at
http​://nntp.perl.org/group/perl.perl5.porters/229127

Re-attaching the two alternative patches.

My preference would be "Allow overriding the compile time in "perl -V" output" since it only changes the behaviour of the build whe explicitly requested.

The macro definitions will need reindentation.

Anyone else have an opinion?

Tony

@p5pRT
Copy link
Author

p5pRT commented Aug 18, 2015

The RT System itself - Status changed from 'new' to 'open'

@p5pRT
Copy link
Author

p5pRT commented Aug 18, 2015

From @bulk88

On Mon Aug 17 23​:34​:55 2015, tonyc wrote​:

My preference would be "Allow overriding the compile time in "perl -V"
output" since it only changes the behaviour of the build whe
explicitly requested.

The macro definitions will need reindentation.

Anyone else have an opinion?

Tony

I'd also go with ""Allow overriding the compile time in "perl -V" output", for some reason I think that $cf_time is not reproducible unless they say config.sh is part of Perl's source code and they ship config.sh in Debian, instead of it being a build product as P5P says it is.

--- a/perl.c
+++ b/perl.c
@​@​ -1795,15 +1795,20 @​@​ S_Internals_V(pTHX_ CV *cv)
  PUSHs(Perl_newSVpvn_flags(aTHX_ non_bincompat_options,
  sizeof(non_bincompat_options) - 1, SVs_TEMP));

+#ifndef PERL_BUILD_DATE<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<FIRST ONE
#ifdef __DATE__
# ifdef __TIME__
- PUSHs(Perl_newSVpvn_flags(aTHX_
- STR_WITH_LEN("Compiled at " __DATE__ " " __TIME__),
- SVs_TEMP));
+# define PERL_BUILD_DATE __DATE__ " " __TIME__
# else
- PUSHs(Perl_newSVpvn_flags(aTHX_ STR_WITH_LEN("Compiled on " __DATE__),
- SVs_TEMP));
+# define PERL_BUILD_DATE __DATE__
# endif
+#endif
+#endif
+
+#ifdef PERL_BUILD_DATE <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<SECOND ONE
+ PUSHs(Perl_newSVpvn_flags(aTHX_
+ STR_WITH_LEN("Compiled at " PERL_BUILD_DATE),
+ SVs_TEMP));
#else
  PUSHs(&PL_sv_undef);
#endif
--

this needs an #elif, not a #ifdef then a #ifndef on the same define

--
bulk88 ~ bulk88 at hotmail.com

@p5pRT
Copy link
Author

p5pRT commented Aug 18, 2015

From @ntyni

On Tue, Aug 18, 2015 at 07​:59​:24AM -0700, bulk88 via RT wrote​:

On Mon Aug 17 23​:34​:55 2015, tonyc wrote​:

My preference would be "Allow overriding the compile time in "perl -V"
output" since it only changes the behaviour of the build whe
explicitly requested.

The macro definitions will need reindentation.

Anyone else have an opinion?

Tony

I'd also go with ""Allow overriding the compile time in "perl -V" output", for some reason I think that $cf_time is not reproducible unless they say config.sh is part of Perl's source code and they ship config.sh in Debian, instead of it being a build product as P5P says it is.

Thanks for looking at this.

The point is that cf_time can be overridden via config.over to make it
reproducible.

I'm happy with PERL_BUILD_DATE (i.e. the first patch) if somebody
can tell me how to set that at Configure time without it ending up in
$Config{ccflags}. The flags in $Config{ccflags} get passed to all XS
module builds, which would look silly in this case.

I guess we could patch cflags.SH, but at that point we could just as
well patch perl.c itself...
--
Niko Tyni ntyni@​debian.org

@p5pRT
Copy link
Author

p5pRT commented Aug 18, 2015

From @ntyni

On Mon, Aug 17, 2015 at 11​:34​:57PM -0700, Tony Cook via RT wrote​:

On Mon Aug 17 09​:29​:14 2015, ntyni@​debian.org wrote​:

Thanks. Yes, something like that is the minimal necessary
modification, and is implemented in the attached patch.

[...]

On the other hand, a full Configure question seems overkill for this,
particularly as Configure already provides the time stamp when it was
run (in 'cf_time'). I'd personally prefer just re-using that time stamp,
unless there's a case for a strong distinction of the two? See the
other attached patch for such an alternative implementation.

My preference would be "Allow overriding the compile time in "perl -V" output" since it only changes the behaviour of the build whe explicitly requested.

We only now noticed that the cf_time patch causes a test failure in
cpan/Config-Perl-V/t/10_base.t because V.pm is matching for 'Compiled
at', which the patch changes to read 'Configured at'. Sorry about missing
that earlier.

The easiest fix is to amend the patch not to change the wording. Updated
patch attached for the sake of completeness. It's not properly tested
though at this point as the discussion seems to prefer the other patch.
--
Niko Tyni ntyni@​debian.org

@p5pRT
Copy link
Author

p5pRT commented Aug 18, 2015

From @ntyni

0001-Compile-Config-cf_time-into-the-perl-binary-instead-.patch
From aad30acda02cb94fb1e8d718c7b86416fa4d7d4d Mon Sep 17 00:00:00 2001
From: Niko Tyni <ntyni@debian.org>
Date: Sun, 5 Jul 2015 18:41:10 +0300
Subject: [PATCH] Compile $Config{cf_time} into the perl binary instead of
 __DATE__/__TIME__

Unlike the C preprocessor macros __DATE__ and __TIME__, the cf_time
value is overridable via config.over mechanism. This can be used
to make the build reproducible, so that compiling the same source
with the same toolchain always gives bitwise identical binaries
and other generated files.

Bug: https://rt.perl.org/Ticket/Display.html?id=125830
Bug-Debian: https://bugs.debian.org/774422
Patch-Name: debian/do-not-record-build-date.diff
---
 config_h.SH |  2 ++
 perl.c      | 11 +----------
 2 files changed, 3 insertions(+), 10 deletions(-)

diff --git a/config_h.SH b/config_h.SH
index fb2224e..8d67775 100755
--- a/config_h.SH
+++ b/config_h.SH
@@ -5199,6 +5199,8 @@ sed <<!GROK!THIS! >$CONFIG_H -e 's!^#undef\(.*/\)\*!/\*#define\1 \*!' -e 's!^#un
 #$usesocks	USE_SOCKS		/**/
 #endif
 
+#define PERL_CF_TIME "$cf_time"
+
 #endif
 !GROK!THIS!
 ;;
diff --git a/perl.c b/perl.c
index e64f1f4..0909f59 100644
--- a/perl.c
+++ b/perl.c
@@ -1795,18 +1795,9 @@ S_Internals_V(pTHX_ CV *cv)
     PUSHs(Perl_newSVpvn_flags(aTHX_ non_bincompat_options,
 			      sizeof(non_bincompat_options) - 1, SVs_TEMP));
 
-#ifdef __DATE__
-#  ifdef __TIME__
     PUSHs(Perl_newSVpvn_flags(aTHX_
-			      STR_WITH_LEN("Compiled at " __DATE__ " " __TIME__),
+			      STR_WITH_LEN("Compiled at " PERL_CF_TIME),
 			      SVs_TEMP));
-#  else
-    PUSHs(Perl_newSVpvn_flags(aTHX_ STR_WITH_LEN("Compiled on " __DATE__),
-			      SVs_TEMP));
-#  endif
-#else
-    PUSHs(&PL_sv_undef);
-#endif
 
     for (i = 1; i <= local_patch_count; i++) {
 	/* This will be an undef, if PL_localpatches[i] is NULL.  */
-- 
2.1.4

@p5pRT
Copy link
Author

p5pRT commented Aug 18, 2015

From @Tux

On Tue, 18 Aug 2015 19​:30​:45 +0300, Niko Tyni <ntyni@​debian.org> wrote​:

On Mon, Aug 17, 2015 at 11​:34​:57PM -0700, Tony Cook via RT wrote​:

On Mon Aug 17 09​:29​:14 2015, ntyni@​debian.org wrote​:

Thanks. Yes, something like that is the minimal necessary
modification, and is implemented in the attached patch.

[...]

On the other hand, a full Configure question seems overkill for this,
particularly as Configure already provides the time stamp when it was
run (in 'cf_time'). I'd personally prefer just re-using that time stamp,
unless there's a case for a strong distinction of the two? See the
other attached patch for such an alternative implementation.

My preference would be "Allow overriding the compile time in "perl -V" output" since it only changes the behaviour of the build whe explicitly requested.

We only now noticed that the cf_time patch causes a test failure in
cpan/Config-Perl-V/t/10_base.t because V.pm is matching for 'Compiled
at', which the patch changes to read 'Configured at'. Sorry about missing
that earlier.

That is on me. I have *no* problem with matching both,
but I think other processes might be happy to see that
unchanged indeed.

The easiest fix is to amend the patch not to change the wording. Updated
patch attached for the sake of completeness. It's not properly tested
though at this point as the discussion seems to prefer the other patch.

--
H.Merijn Brand http​://tux.nl Perl Monger http​://amsterdam.pm.org/
using perl5.00307 .. 5.21 porting perl5 on HP-UX, AIX, and openSUSE
http​://mirrors.develooper.com/hpux/ http​://www.test-smoke.org/
http​://qa.perl.org http​://www.goldmark.org/jeff/stupid-disclaimers/

@p5pRT
Copy link
Author

p5pRT commented Aug 18, 2015

From @jmdh

On Tue, Aug 18, 2015 at 07​:30​:45PM +0300, Niko Tyni wrote​:

On Mon, Aug 17, 2015 at 11​:34​:57PM -0700, Tony Cook via RT wrote​:

On Mon Aug 17 09​:29​:14 2015, ntyni@​debian.org wrote​:

Thanks. Yes, something like that is the minimal necessary
modification, and is implemented in the attached patch.

[...]

On the other hand, a full Configure question seems overkill for this,
particularly as Configure already provides the time stamp when it was
run (in 'cf_time'). I'd personally prefer just re-using that time stamp,
unless there's a case for a strong distinction of the two? See the
other attached patch for such an alternative implementation.

My preference would be "Allow overriding the compile time in "perl -V" output" since it only changes the behaviour of the build whe explicitly requested.

We only now noticed that the cf_time patch causes a test failure in
cpan/Config-Perl-V/t/10_base.t because V.pm is matching for 'Compiled
at', which the patch changes to read 'Configured at'. Sorry about missing
that earlier.

The easiest fix is to amend the patch not to change the wording. Updated
patch attached for the sake of completeness. It's not properly tested
though at this point as the discussion seems to prefer the other patch.

This is true, but it's then quite likely to be entirely false statement
to say that perl was compiled at a certain time. For the record, and
running the risk of overloading this bug with too many patches, here is
a fix for Config​::Perl​::V.

(Note that this discussion is largely independent of which basic patch
is used).

Dominic.

@p5pRT
Copy link
Author

p5pRT commented Aug 18, 2015

From @jmdh

0003-Fix-cpan-Config-Perl-V-V.pm-to-match-perl-V.patch
From 08894fe5363ce808df6c2d2f881f76430e54f450 Mon Sep 17 00:00:00 2001
From: Dominic Hargreaves <dom@earth.li>
Date: Tue, 18 Aug 2015 15:35:07 +0200
Subject: [PATCH 3/3] Fix cpan/Config-Perl-V/V.pm to match perl -V

perl -V has been patched to return 'Configured at' rather than
'Compiled at' as part of the reproducible builds effort. Reflect this
change in cpan/Config-Perl-V/V.pm too.

Patch-Name: debian/fix_config_perl_v_for_configured_at.diff
---
 cpan/Config-Perl-V/V.pm | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/cpan/Config-Perl-V/V.pm b/cpan/Config-Perl-V/V.pm
index def79bb..c860f97 100644
--- a/cpan/Config-Perl-V/V.pm
+++ b/cpan/Config-Perl-V/V.pm
@@ -274,7 +274,7 @@ sub plv2hash
 
     my $build = { %empty_build };
 
-    $pv =~ m{^\s+Compiled at\s+(.*)}m
+    $pv =~ m{^\s+(?:Compiled|Configured) at\s+(.*)}m
 	and $build->{stamp}   = $1;
     $pv =~ m{^\s+Locally applied patches:(?:\s+|\n)(.*?)(?:[\s\n]+Buil[td] under)}ms
 	and $build->{patches} = [ split m/\n+\s*/, $1 ];
@@ -338,6 +338,7 @@ sub myconfig
     my $stamp = eval { Config::compile_date () };
     if (defined $stamp) {
 	$stamp =~ s/^Compiled at //;
+	$stamp =~ s/^Configured at //;
 	$build->{osname}      = $^O;
 	$build->{stamp}       = $stamp;
 	$build->{patches}     =     [ Config::local_patches () ];
-- 
2.1.4

@p5pRT
Copy link
Author

p5pRT commented Aug 19, 2015

From @tonycoz

On Tue Aug 18 09​:14​:15 2015, ntyni@​debian.org wrote​:

On Tue, Aug 18, 2015 at 07​:59​:24AM -0700, bulk88 via RT wrote​:

On Mon Aug 17 23​:34​:55 2015, tonyc wrote​:

My preference would be "Allow overriding the compile time in "perl
-V"
output" since it only changes the behaviour of the build whe
explicitly requested.

The macro definitions will need reindentation.

Anyone else have an opinion?

I'd also go with ""Allow overriding the compile time in "perl -V"
output", for some reason I think that $cf_time is not reproducible
unless they say config.sh is part of Perl's source code and they ship
config.sh in Debian, instead of it being a build product as P5P says
it is.

Thanks for looking at this.

The point is that cf_time can be overridden via config.over to make it
reproducible.

I'm happy with PERL_BUILD_DATE (i.e. the first patch) if somebody
can tell me how to set that at Configure time without it ending up in
$Config{ccflags}. The flags in $Config{ccflags} get passed to all XS
module builds, which would look silly in this case.

I guess we could patch cflags.SH, but at that point we could just as
well patch perl.c itself...

Passing the definition to all the the XS builds didn't particularly bother me, but I expected to have less trouble passing the -DPERL_BUILD_DATE=... to Configure​:

  ./Configure ... -Accflags=-DPERL_BUILD_DATE='"some date"'

(and many variations) lost the quotes each time, presumably due to all the shell manipulation of the variables (which might be fixable, but I'm not sure I want to jump down that hole.)

Editing config.sh and rebuilding config.sh works though.

Tony

@p5pRT
Copy link
Author

p5pRT commented Aug 22, 2015

From @ntyni

On Tue, Aug 18, 2015 at 06​:56​:59PM -0700, Tony Cook via RT wrote​:

Passing the definition to all the the XS builds didn't particularly bother me, but I expected to have less trouble passing the -DPERL_BUILD_DATE=... to Configure​:

./Configure ... -Accflags=-DPERL_BUILD_DATE='"some date"'

(and many variations) lost the quotes each time, presumably due to all the shell manipulation of the variables (which might be fixable, but I'm not sure I want to jump down that hole.)

I tried many variations of this as well and failed.

Editing config.sh and rebuilding config.sh works though.

There's probably a typo there...

I got it to work by appending '#define PERL_BUILD_DATE "..."' to config.h
after running Configure, and that's good enough for me FWIW.
--
Niko Tyni ntyni@​debian.org

@p5pRT
Copy link
Author

p5pRT commented Aug 28, 2015

From @jmdh

Here is the final version of this patch included in Debian, with the reindentation requested by Tony. I believe this should be suitable for inclusion in blead (and indeed it applies cleanly).

Thanks,
Dominic.

@p5pRT
Copy link
Author

p5pRT commented Aug 28, 2015

From @jmdh

do-not-record-build-date.diff
From 5915800fd10cbb59be3f1b3639ebb1a7ce5ea88c Mon Sep 17 00:00:00 2001
From: Niko Tyni <ntyni@debian.org>
Date: Sun, 12 Jul 2015 22:23:00 +0300
Subject: Allow overriding the compile time in "perl -V" output

The C preprocessor macros __DATE__ and __TIME__ embed the compile time
into the binary for the purposes of "perl -V" output. This makes the
build unreproducible: compiling the same source with the same toolchain
cannot be made to yield bitwise identical binaries and other generated
files.

The compile time can now be overridden with the PERL_BUILD_DATE macro.

Bug: https://rt.perl.org/Ticket/Display.html?id=125830
Bug-Debian: https://bugs.debian.org/774422
Patch-Name: debian/do-not-record-build-date.diff
---
 perl.c | 19 ++++++++++++-------
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/perl.c b/perl.c
index e64f1f4..4d835d2 100644
--- a/perl.c
+++ b/perl.c
@@ -1795,15 +1795,20 @@ S_Internals_V(pTHX_ CV *cv)
     PUSHs(Perl_newSVpvn_flags(aTHX_ non_bincompat_options,
 			      sizeof(non_bincompat_options) - 1, SVs_TEMP));
 
-#ifdef __DATE__
-#  ifdef __TIME__
+#ifndef PERL_BUILD_DATE
+#  ifdef __DATE__
+#    ifdef __TIME__
+#      define PERL_BUILD_DATE __DATE__ " " __TIME__
+#    else
+#      define PERL_BUILD_DATE __DATE__
+#    endif
+#  endif
+#endif
+
+#ifdef PERL_BUILD_DATE
     PUSHs(Perl_newSVpvn_flags(aTHX_
-			      STR_WITH_LEN("Compiled at " __DATE__ " " __TIME__),
-			      SVs_TEMP));
-#  else
-    PUSHs(Perl_newSVpvn_flags(aTHX_ STR_WITH_LEN("Compiled on " __DATE__),
+			      STR_WITH_LEN("Compiled at " PERL_BUILD_DATE),
 			      SVs_TEMP));
-#  endif
 #else
     PUSHs(&PL_sv_undef);
 #endif

@p5pRT
Copy link
Author

p5pRT commented Sep 2, 2015

From @jimc

So, it looks now that the narrow goals of the ticket are addressed.

Id like to extend the discussion.
It would be nice if perl could be configured to install as

perl5.23.2-80-gcd03fd3-k<f00ball>

ie including the -g<sha> shown in git describe
and also a meaningful checksum on the configuration & platform.

this would simplify benchmarking, and potentially yield benchmark results
that are comparable across many boxes.

Porting/bench /opt/perl5/perl5*-g*-k*

Its clear to me there are many steps, to many parts of the build system,
and I dont know what they are.

that said, I think attached is the 1st step​:
patch Configure so that its easier to skip the config-noise

cf_hash=`grep -v '^#=' config.sh | md5sum`

@p5pRT
Copy link
Author

p5pRT commented Sep 2, 2015

From @jimc

0001-Configure-improve-config.sh-by-setting-up-for-no-SHA.patch
From 1d671a29526bf7587a592aadb57b338a840e1a5b Mon Sep 17 00:00:00 2001
From: Jim Cromie <jim.cromie@gmail.com>
Date: Tue, 1 Sep 2015 20:52:18 -0600
Subject: [PATCH] Configure: improve config.sh by setting up for no SHA1-noise.

the header info in config.sh currently has a number of fields whose
value is unconstrained ($cf_time, $cf_by, $myuname).  For example:

 # Package name      : perl5
 # Source directory  : .
 # Configuration time: Fri Aug 28 21:09:08 MDT 2015
 # Configured by     : jimc
 # Target system     : linux groucho.jimc.earth 4.2.0-rc7-x2a-00125-gd0b89bd #278 smp sat aug 22 13:35:17 mdt 2015 x86_64 x86_64 x86_64 gnulinux

The presence of these fields destroys any `md5sum config.sh` utility,
which otherwize would tell much about the config, SW and HW platform
perl was built on.

This patch tweaks Configure to markup the variant part of the header
so those 3 lines are easy to exclude from a grep, wo messing with the
uses of the varnames themselves.

  grep -v '^#=' config.sh | grep -v | cksum

So this is a small step towards adding -K<md5-mumble> into the perl
executable's installed version, such that we could do:

  Porting/bench /opt/perl/perl5.23.2-80-gcd03fd3-k*

and get benchmark results that have a chance of being comparable across
many porters' boxes.
---
 Configure | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/Configure b/Configure
index 464737d..6d8d149 100755
--- a/Configure
+++ b/Configure
@@ -23937,11 +23937,11 @@ $startsh
 # instead choose to run each of the .SH files by yourself, or "Configure -S".
 #
 
-# Package name      : $package
-# Source directory  : $src
-# Configuration time: $cf_time
-# Configured by     : $cf_by
-# Target system     : $myuname
+#= Package name      : $package
+#= Source directory  : $src
+#= Configuration time: $cf_time
+#= Configured by     : $cf_by
+#= Target system     : $myuname
 
 EOT
 : Add in command line options if available
-- 
2.1.0

@p5pRT
Copy link
Author

p5pRT commented Oct 18, 2015

From @tonycoz

On Tue Sep 01 20​:59​:32 2015, yoduh wrote​:

So, it looks now that the narrow goals of the ticket are addressed.

Id like to extend the discussion.
It would be nice if perl could be configured to install as

This should be a new ticket.

Tony

@p5pRT
Copy link
Author

p5pRT commented Oct 18, 2015

From @tonycoz

On Sat Aug 22 00​:45​:23 2015, ntyni@​debian.org wrote​:

On Tue, Aug 18, 2015 at 06​:56​:59PM -0700, Tony Cook via RT wrote​:

Passing the definition to all the the XS builds didn't particularly
bother me, but I expected to have less trouble passing the
-DPERL_BUILD_DATE=... to Configure​:

./Configure ... -Accflags=-DPERL_BUILD_DATE='"some date"'

(and many variations) lost the quotes each time, presumably due to
all the shell manipulation of the variables (which might be fixable,
but I'm not sure I want to jump down that hole.)

I tried many variations of this as well and failed.

Editing config.sh and rebuilding config.sh works though.

There's probably a typo there...

I got it to work by appending '#define PERL_BUILD_DATE "..."' to
config.h
after running Configure, and that's good enough for me FWIW.

I've held off on applying your patch because I really want to be able to control this from the Configure command-line, but I don't see a way to do so.

Tony

@p5pRT
Copy link
Author

p5pRT commented Nov 2, 2015

From @tonycoz

On Sun Oct 18 16​:30​:20 2015, tonyc wrote​:

On Sat Aug 22 00​:45​:23 2015, ntyni@​debian.org wrote​:

On Tue, Aug 18, 2015 at 06​:56​:59PM -0700, Tony Cook via RT wrote​:

Passing the definition to all the the XS builds didn't particularly
bother me, but I expected to have less trouble passing the
-DPERL_BUILD_DATE=... to Configure​:

./Configure ... -Accflags=-DPERL_BUILD_DATE='"some date"'

(and many variations) lost the quotes each time, presumably due to
all the shell manipulation of the variables (which might be
fixable,
but I'm not sure I want to jump down that hole.)

I tried many variations of this as well and failed.

Editing config.sh and rebuilding config.sh works though.

There's probably a typo there...

I got it to work by appending '#define PERL_BUILD_DATE "..."' to
config.h
after running Configure, and that's good enough for me FWIW.

I've held off on applying your patch because I really want to be able
to control this from the Configure command-line, but I don't see a way
to do so.

This was fixed in 7bd8199, so I've applied this patch as 6baa8db, thanks for the patch.

Tony

@p5pRT
Copy link
Author

p5pRT commented Nov 2, 2015

@tonycoz - Status changed from 'open' to 'resolved'

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant