grass

grass copied to clipboard

Describe the bug

When filing in my recent bugs reports on Windows, I observed that the libgis_date, libgis_revision, revision, build_date fields don't seem updated, and mention 2024-04-14 or in the 2024-04-13 day (when there were big changes in the build environment). Assuming that this April 14, 2024, is after the changes in configure to use the git dates (https://github.com/OSGeo/grass/pull/3435, March 24, 2024), I expect that these would be up to date.

Looking at the most recent commit that have files that appear in the installed source, I see the changes https://github.com/OSGeo/grass/commit/132755b544255ede1de9a76a48fb2fc144d68bfa (2024-05-22) included in the latest nightly for f4d8c62acd9bb6a65854a111ea73380f7760b838 (2024-05-23), so the source actually changes.

To reproduce

1. On a windows computer, install the latest grass-dev package from the OSGeo4W installer. (A fresh install through Windows sandbox can help make sure no older install interferes, supported on all editions except Home, since I assume it uses Hyper-V)
2. In either the grass console, or osgeo4w console, call g.version -ecxrgb or grass84 --exec g.version -ecxrgb respectively (I find it weird that it requires grass84, not grass like the docs, I thought we had simplified this).
3. See that the various fields seem out of date.
4. (Also see that the Kölnstrasse 99 in the address shows up as Kölnstrasse 99, the o with two dots is shown as Latin Capital Letter A with Tilde followed by Pilcrow Sign) Note: it is not Windows sandbox and that the old console host is used, on my main os, through the new windows terminal too it has this

Expected behavior

Build info version is correct, especially as the bug reports that will come in won't be useful if the versions are wrong

Screenshots

C:\OSGeo4W>grass84 --exec g.version -ecrbg
WARNING: Concurrent mapset locking is not supported on Windows
version=8.4.0dev
date=2024
revision=exported
build_date=2024-04-14
build_platform=x86_64-w64-mingw32
build_off_t_size=8

Copyright and License Statement

The Geographic Resources Analysis and Support System (GRASS)
Geographic Information System (GIS) is Copyright by members
of the GRASS Development Team.

This program is free software; you can redistribute it and/or modify it
under the terms of the GNU General Public License as published by the
Free Software Foundation; either version 2 of the License, or (at your
option) any later version.

Parts of GRASS are not copyright by the GRASS development team.
The original authors hold the copyrights and you have to abide
to their licensing terms where noted.
(Keep in mind that code linking into GRASS can only be distributed
if compatible with the GPL.)

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License (GPL) for more details.

You should have received a copy of the GNU General Public License
along with this program; if not, write to the
  Free Software Foundation, Inc.,
  51 Franklin Street, Fifth Floor
  Boston, MA 02110-1301 USA

Questions regarding GRASS GIS should be directed to the
GRASS Development Team at the following address:

 GRASS Development Team
 c/o Markus Neteler
 mundialis GmbH & Co. KG
 Kölnstrasse 99
 53111 Bonn, Germany
 neteler AT osgeo.org

Internet:  https://grass.osgeo.org

./configure --host=x86_64-w64-mingw32 --with-libs=/C/src/osgeo4w/src/GRASS-~1/osgeo4w/osgeo4w/lib /C/src/osgeo4w/src/GRASS-~1/osgeo4w/osgeo4w/bin --with-includes=/C/src/osgeo4w/src/GRASS-~1/osgeo4w/osgeo4w/include --libexecdir=/C/src/osgeo4w/src/GRASS-~1/osgeo4w/osgeo4w/bin --prefix=/C/src/osgeo4w/src/GRASS-~1/osgeo4w/osgeo4w/apps/grass --bindir=/C/src/osgeo4w/src/GRASS-~1/osgeo4w/osgeo4w/bin --includedir=/C/src/osgeo4w/src/GRASS-~1/osgeo4w/osgeo4w/include --with-opengl=windows --without-x --with-cxx --enable-shared --enable-largefile --with-fftw --with-freetype --with-freetype-includes=/C/src/osgeo4w/src/GRASS-~1/osgeo4w/osgeo4w/include/freetype2 --with-proj-share=/C/src/osgeo4w/src/GRASS-~1/osgeo4w/osgeo4w/share/proj --with-proj-includes=/C/src/osgeo4w/src/GRASS-~1/osgeo4w/osgeo4w/include --with-proj-libs=/C/src/osgeo4w/src/GRASS-~1/osgeo4w/osgeo4w/lib --with-postgres --with-postgres-includes=/C/src/osgeo4w/src/GRASS-~1/osgeo4w/osgeo4w/include --with-postgres-libs=/C/src/osgeo4w/src/GRASS-~1/osgeo4w/osgeo4w/lib --with-gdal=/c/src/osgeo4w/src/grass-dev/grass/mswindows/osgeo4w/gdal-config --with-geos=/c/src/osgeo4w/src/grass-dev/grass/mswindows/osgeo4w/geos-config --with-sqlite --with-sqlite-includes=/C/src/osgeo4w/src/GRASS-~1/osgeo4w/osgeo4w/include --with-sqlite-libs=/c/src/osgeo4w/src/grass-dev/grass/mswindows/osgeo4w/lib --with-regex --with-nls --with-zstd --with-odbc --with-blas --with-lapack --with-lapack-includes=/mingw64/include --with-openmp --with-cairo --with-cairo-includes=/C/src/osgeo4w/src/GRASS-~1/osgeo4w/osgeo4w/include --with-cairo-ldflags=-L/c/src/osgeo4w/src/grass-dev/grass/mswindows/osgeo4w/lib -lcairo --with-bzlib --with-liblas=/c/src/osgeo4w/src/grass-dev/grass/mswindows/osgeo4w/liblas-config --with-netcdf=/C/src/osgeo4w/src/GRASS-~1/osgeo4w/osgeo4w/bin/nc-config --without-pdal host_alias=x86_64-w64-mingw32
libgis_revision=8.4.0dev
libgis_date=2024-04-13T22:45:54+00:00
proj=9.4.0
gdal=3.8.5
geos=3.12.1
sqlite=3.45.1

C:\OSGeo4W>

System description

• Operating System: Windows 11 22H2 in windows sandbox
• GRASS GIS version: 8.4dev nightly from OSGeo4W, 8.4-313-f4d8c62ac-1, + change the file from #3732 (see copied console)

Additional context

I finished a PR adding extra info to the .github/workflows/print_versions.sh script, and making sure it gets ran on Linux, macOS and Windows CI, and we see that the fields are updated. I'm posting it right after.

With 8.4-314-xxxx-1, g.version with all the flags report a library build date of 2024-05-27 with a certain time, and the build date of the software is also 2024-05-27. There is still the revision that is set to "exported".

I wonder if adding libsclean in addition to distclean would make sure everything is recompiled.

https://github.com/OSGeo/grass/blob/f59851043fbd7cb52288b7000d7e76824ae63ab7/mswindows/osgeo4w/package.sh#L138-L142

I remember some issues with contributor's PRs where this was a problem, as clean isn't enough sometimes, and distclean isn't cleaning everything.

One of these two must be done before the other (written before as one of the list of targets passed to make), as once the Platform.make is cleaned, the rest doesn't run since Platform.make is trying to be included but doesn't exist anymore.

tested with

System Info                                                                     
GRASS version: 8.5.0dev                                                         
Code revision: 0b0cffce0                                                        
Build date: 2024-06-16                                                          
Build platform: x86_64-w64-mingw32                                              
GDAL: 3.9.0                                                                     
PROJ: 9.4.0                                                                     
GEOS: 3.12.2                                                                    
SQLite: 3.45.1                                                                  
Python: 3.12.4                                                                  
wxPython: 4.2.1                                                                 
Platform: Windows-11-10.0.22631-SP0 (OSGeo4W)      

g.version -ecrbg
version=8.5.0dev
date=2024
revision=0b0cffce0
build_date=2024-06-16
build_platform=x86_64-w64-mingw32
build_off_t_size=8

I wonder if adding libsclean in addition to distclean would make sure everything is recompiled.

BTW: running make libsclean seems not to work properly, at least on my Fedora box:

make  libsclean 
rm -rf /dist.
rm -rf /bin.
...

The architecture isn't shown and the absolute path is also wrong (current directory missing from path).