Hi,

On Sat, Feb 29, 2020 at 06:41:27PM +0100, Alexander Dahl wrote:
> On Sat, Feb 29, 2020 at 09:48:28AM +0100, Michael Olbrich wrote:
> > On Fri, Feb 28, 2020 at 05:14:41PM +0100, Alexander Dahl wrote:
> > > On Fri, Feb 28, 2020 at 04:40:10PM +0100, Roland Hieber wrote:
> > > > Instead we could use the date of ./tarball-version (like
> > > > PTXDIST_BSP_AUTOVERSION does too) or the current VCS commit; or if the
> > > > BSP is not a VCS repo, or if the worktree has local changes, fall back
> > > > to searching for the most recent file in the current BSP.
> > > 
> > > Or the user could just do anything she wants and feed it into
> > > REPRODUCIBLE_TIMESTAMP_CUSTOM?
> > 
> > How about
> >  - 'now' (what we have now)
> 
> Nice for backwards compatibility and to not break expections of users.
> 
> >  - 'last commit' (CommitDate fromt the last commit)
> 
> Assuming the BSP is in Git, but most users will do that anyway. 
> 
> I consider this a good one. You get a comprehensible timestamp related
> to the BSP (instead of the ptxdist or toolchain version) while still
> getting the same result on multiple builds of the same revision of the
> BSP, wouldn't you?

Yes, exactly. And it should be the CommitDate not the AuthorDate.
It will be reproducible but still show when the last changes happened.

> >  - 'custom' (from a string)
> > 
> > I'm not sure what you'd want to put in a custom string, but I wouldn't mind
> > adding it.
> 
> +1

I'm sure someone will find a use-case for this as well...

Michael

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

Reply via email to