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.
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
