[PATCH]Use __DATE__ and __TIME__ instead of date(1)

[Patrick Georgi]

Hi,

attached patch uses the __DATE__ and __TIME__ macros instead of date(1)
calls. User visible results are:
- different date format (no timezone included)
- different time stamps in a single build
- less calls to tools from make (and it also slightly helps ccache do
its magic)

Signed-off-by: Patrick Georgi

[Peter Stuge]

Patrick Georgi wrote:
> attached patch uses the __DATE__ and __TIME__ macros instead of date(1)
> calls. User visible results are:
> different date format (no timezone included)

Ok.
> different time stamps in a single build

Hm, but there's only one build.h, right?

//Peter

[Patrick Georgi]

Am 25.09.2010 00:50, schrieb Peter Stuge:
> > different time stamps in a single build
>
> Hm, but there's only one build.h, right?

It's evaluated on compile time, not when build.h is generated.

[Peter Stuge]

Patrick Georgi wrote:
> > > different time stamps in a single build
> >
> > Hm, but there's only one build.h, right?
>
> It's evaluated on compile time, not when build.h is generated.

DOH! Yes of course. :) Is it too ugly to add a compile step to
expand the macro into build.h ?

//Peter

[Patrick Georgi]

Am 25.09.2010 00:56, schrieb Peter Stuge:
> DOH! Yes of course. :) Is it too ugly to add a compile step to
> expand the macro into build.h ?

While keeping all the macros that are in build.h alive? Yes.

I guess, the real question is how many times these values are used in
the first place. As far as I can see, it's only for the banners of
romstage and ramstage. Not exactly crucial.

Patrick

[Peter Stuge]

Patrick Georgi wrote:
> Am 25.09.2010 00:56, schrieb Peter Stuge:
> > DOH! Yes of course. :) Is it too ugly to add a compile step to
> > expand the macro into build.h ?
>
> While keeping all the macros that are in build.h alive? Yes.

And it is the same as the previous date command I guess..

Too ugly even if done right at the beginning?

--8<-- build_time.c
int main() {
printf("#define TIME "%s"\n#define DATE "%s"\n",__TIME__,__DATE__);
return 0;
}
-->8--

build.h: build_time
    build_time > build.ht
    echo ... >> build.ht
> I guess, the real question is how many times these values are used in
> the first place. As far as I can see, it's only for the banners of
> romstage and ramstage. Not exactly crucial.

No, but is there a point in having the timestamp be the same? Maybe
there's actually a point in having them be different!

//Peter

[Frieder Ferlemann]

Hi,

Am 25.09.2010 00:50, schrieb Peter Stuge:
> Patrick Georgi wrote:
> > attached patch uses the __DATE__ and __TIME__ macros instead of date(1)
> > calls. User visible results are:
> > different date format (no timezone included)
>
> Ok.

Maybe use a date format which is closer to ISO 8601?
> date +"%F %T"

2010-09-25 15:39:41
> date +"%FT%T"

2010-09-25T15:39:43

( http://www.uic.edu/depts/accc/software/isodates/datefmt.html#Wanted )

Greetings,
Frieder

[Patrick Georgi]

Am 25.09.2010 15:53, schrieb Frieder Ferlemann:
> Maybe use a date format which is closer to ISO 8601?

How do I specify that in "__DATE__" which this thread and patch is about?

Patrick

[Frieder Ferlemann]

Hi Patrick,

Am 25.09.2010 16:16, schrieb Patrick Georgi:
> Am 25.09.2010 15:53, schrieb Frieder Ferlemann:
> > Maybe use a date format which is closer to ISO 8601?
>
> How do I specify that in "__DATE__" which this thread and patch is about?

Sorry that I kind of highjacked the mail thread
to request a specific output format instead of
concentrating on the implementation.

And sorry I cannot think on how to get an ISO 8601
format derived from "__DATE__" or "__TIME__":

Unfortunately C99 (according to  WG14/N1256 ISO/IEC 9899:TC3, section 6.10.8)
specifies "__DATE__" as
... [a character string literal of the form "Mmm dd yyyy", where] ...
but would also allows for an [implementation-defined valid date] ...

Greetings,
Frieder