search

SpatioTemporal / STARE

SpatioTemporal Adaptive Resolution Encoding, a unifying index for geo-located data.
Other
10 stars 7 forks source link

add a stare-config executable #93

Open NiklasPhabian opened 3 years ago

NiklasPhabian commented 3 years ago

It might be worthwhile to mimic e.g. geos' approach to provide an executable supplying us with info about the installed version of the library. This becomes increasingly necessary to keep STARE and pystare in sync for users (https://github.com/SpatioTemporal/pystare/issues/60)

Usage: geos-config [OPTIONS]
Options:
     [--prefix]
     [--version]
     [--libs]
     [--clibs]
     [--cclibs]
     [--static-clibs]
     [--static-cclibs]
     [--cflags]
     [--ldflags]
     [--includes]
     [--jtsport]

geos-config --version
3.8.0
NiklasPhabian commented 2 years ago

@michaelleerilee what would be the right way to check what version of STARE is installed in the e.g. the "STARE_LIB_DIR" right now. Would we have to look at the VERSION file of the source or is there any way of getting the version out of the build? Does my above mentioned approach make sense to you e.g. having an executable that installs with STARE that allows to do 

$ stare-config --version
1.2.5
NiklasPhabian commented 2 years ago

Extending on this; exposing hardcoded versions into the target wont be sufficient. We should much rather poll the version from the git tag or, failing that from the commit hash. In python, versioneer does just that for us. But there should be an equivalent for e.g. cmake.

Hardcoding version numbers will get us in trouble and hours of lost time in confusion when we work with on feature branches or even worse, forks.