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 email@example.com