[gdal-dev] Motion: adopt GDAL 3.5.3RC1 as final 3.5.3 release

[Even Rouault]

Greg,

I indeed see that some generated files have a lower timestamp than their 
.i sources. Probably something due to some files being regenerated as 
identical (apart higher timestamp) to their existing versions in git and 
thus not being committed into git. There is nothing new in the 
generation process related to this, so weird that this shows up only 
now. Or perhaps this has hit in the past unnoticed.

Anyway I've uploaded updated archives whose only difference is just 
doing "touch swig/python/extensions/*" on top of rc1

   https://download.osgeo.org/gdal/3.5.3/gdal-3.5.3rc2.tar.xz
   https://download.osgeo.org/gdal/3.5.3/gdal-3.5.3rc2.tar.gz
   https://download.osgeo.org/gdal/3.5.3/gdal353rc2.zip

I've also modified the mkgdaldist.sh to force updating the timestamps 
for future releases

Even

Le 27/10/2022 à 17:31, Greg Troxel a écrit :
> the problem is that
>
>    work/gdal-3.5.3/swig/python/extensions/gnm_wrap.cpp
>
> has the same timestamp (in the tar file) as
>
>    work/gdal-3.5.3/swig/include/gnm.i
>
> running
>
>    touch work/gdal-3.5.3/swig/python/extensions/gnm_wrap.cpp
>
> after unpack and before build results in a successful build.
>
> I guess make wants object > source, not >=, which seems fair.
>
> I wonder if gnm.i is itself generated as part of distfile creation, and
> if it needs a 'sleep 1', or if this is "git checkout"  followed by 'make
> dist' and it's all blazingly fast?
>
>
>    

-- 
http://www.spatialys.com
My software is free, but my time generally not.