[Pkg-pascal-devel] help needed

[Abou Al Montacir]

Hi Paul,
On Fri, 2015-11-20 at 22:22 +0100, Paul Gevers wrote:
> Hi Abou,
> 
> On 20-11-15 15:12, Abou Al Montacir wrote:
> > For sure this patch is ugly compared to the first one.
> Can you please elaborate on why? I believed the second one was cleaner.
I meant that I do prefer to change the function getdatestr in case it is used
some where else in the future. Indeed this abstracts the usage of
SOURCE_DATE_EPOCH.
However the first patch only affects the compiler. This means that the result of
{$I %DATE%} will always return the compiler sources date. This is of course a
bug.
It would be probably better to do:
Index: fpc/fpcsrc/compiler/globals.pas
=================================================================
---
fpc.orig/fpcsrc/compiler/globals.pas
+++ fpc/fpcsrc/compiler/globals.pas
@@ -43,7
+43,7 @@ interface
 {$ENDIF}
       { comphook pulls in sysutils anyways }
      
cutils,cclasses,cfileutl,
-      cpuinfo,
+      cpuinfo,DateUtils,
      
globtype,version,systems; 
     const
@@ -766,8 +766,13 @@ implementation
    }
    
   var
         Year,Month,Day: Word;
+        SourceDateEpoch: string;
      
begin
+        SourceDateEpoch = GetEnvironmentVariable('SOURCE_DATE_EPOCH');
-   
     DecodeDate(Date,year,month,day);
+        if Length(SourceDateEpoch)>0 then
+
          DecodeDate(UnixToDateTime(SourceDateEpoch),year,month,day)
+       
else
+          DecodeDate(Date,year,month,day);
        
getdatestr:=L0(Year)+'/'+L0(Month)+'/'+L0(Day);
       end;
Will explain more how
to cope with DecodeDate.
> > 
> > It definitely affects the compiler when compiling other programs also.
> I had the believe the the first one was more definite. So I like to
> learn here.
> 

Are you talking about the same thing as the bug above?
> > 
> > I'd prefer some thing like similar to your first path but where your
> > variable contains the SOURCE_DATE_EPOCH in the format of Date function
> > output.
> I hope you understand that the format of SOURCE_DATE_EPOCH is outside of
> our control. It is defined¹ as "A UNIX timestamp, defined as the number
> of seconds (excluding leap seconds) since 01 Jan 1970 00:00:00 UTC."
> Where: "The value MUST be an ASCII representation of an integer with no
> fractional component, identical to the output of date +%s."
> 

Thank for the link, now it is more clear, so you can not define the format as
you want (especially a string) and that explains your DEB_DATE in the second
patch..
> > 
> > Function UnixToDateTime(const AValue: Int64): TDateTime;
> > 
> > begin
> > 
> >   Result:=IncSecond(UnixEpoch, AValue);
> > 
> > end;
> > 
> > Function IncSecond(const AValue: TDateTime; const ANumberOfSeconds: Int64): TDateTime;
> > 
> > begin
> > 
> >   Result:=AValue+ANumberOfSeconds / SecsPerDay;
> > 
> >   MaybeSkipTimeWarp(AValue,Result);
> > 
> > end;
> > 
> > Procedure MaybeSkipTimeWarp(OldDate: TDateTime; var NewDate: TDateTime);
> > 
> > begin
> > 
> >   if (OldDate>0) and (NewDate<0) then
> > 
> >     NewDate:=NewDate-0.5
> > 
> >   else if (OldDate<-1.0) and (NewDate>-1.0) then
> > 
> >     NewDate:=NewDate+0.5;
> > 
> > end;
> > 
> > You can also put all this code in makefile or in a function that you add
> > it in your patch. We are talking about 3 lines of code here.
> > 

> 
> 
> Can you elaborate on what you have in mind exactly? I would really like
> to come to a patch that would be acceptable by upstream in the upstream
> code. I currently believe that scanner.pas is really the appropriate
> place, with maybe globals.pas as an alternative. But maybe you have
> great alternatives in mind.

I just think that we copy paste these function in globals.pas, maybe after
merging then all in one function. This will avoid adding a dependency on a new
unit.
-- 
Cheers,
Abou Al Montacir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-pascal-devel/attachments/20151122/8244cfd7/attachment.html>