search

WISE-Developers / WISE_Application

WISE_Application formerly known as WISE
GNU Affero General Public License v3.0
7 stars 2 forks source link

Pin the GSL version #57

Closed tredpath closed 5 months ago

tredpath commented 5 months ago

Force the GSL library to build from tag v4.0.0 instead of always using the repository head.

For #53

BadgerOnABike commented 5 months ago

I'm curious the intent behind locking to a patch version. I would presume we can safely lock to a major with notes to review subsequent majors for upgrade upon their arrival. Locking to patch has been the source of many of our GDAL issues and I'm concerned doing this here will result in another location where versioning for our software will differ from the broader suite of software on any one system and result in conflicts and misbehaviour.

spydmobile commented 5 months ago

I'm curious the intent behind locking to a patch version. I would presume we can safely lock to a major with notes to review subsequent majors for upgrade upon their arrival. Locking to patch has been the source of many of our GDAL issues and I'm concerned doing this here will result in another location where versioning for our software will differ from the broader suite of software on any one system and result in conflicts and misbehaviour.

right, let me take this one step further, i would argue, admittedly, maybe from a position of ignorance, but why pin to a number at all, why not pion to CURRENT major. not 4.x.x - i agree with your point @BadgerOnABike but I think it should be 100% dynamic. Or am I out to lunch thinking this way?

BadgerOnABike commented 5 months ago

I'm curious the intent behind locking to a patch version. I would presume we can safely lock to a major with notes to review subsequent majors for upgrade upon their arrival. Locking to patch has been the source of many of our GDAL issues and I'm concerned doing this here will result in another location where versioning for our software will differ from the broader suite of software on any one system and result in conflicts and misbehaviour.

right, let me take this one step further, i would argue, admittedly, maybe from a position of ignorance, but why pin to a number at all, why not pion to CURRENT major. not 4.x.x - i agree with your point @BadgerOnABike but I think it should be 100% dynamic. Or am I out to lunch thinking this way?

The only reason I suggest a review period upon a new major is if they have made fundamental architectural changes that we would need to adapt to in order to utilize the new major. Accepting the new major without a review could result in the tool being unable to build and if individuals are building from source on each instantiation this could cause an issue.

Now, we could point dev at most recent major and leave main alone. Then we would detect these failure points.

spydmobile commented 5 months ago

@tredpath care to weigh in here man? Is what we are discussing doable?

RobBryce commented 5 months ago

The GSL library has changed the names and directory structure to header files. C++ has limited preprocessor directives to check and deal with existence of include files in specific paths. Locking to this version deals with this include path issue. This is before we even consider changes to the GSL API.

tredpath commented 5 months ago

I pinned it by specifying which git reference to pull, it's not a pattern match. If you want to pin to a more dynamic version you'd either have to find a new way of pulling it or write some logic to discover which reference is the latest that matches your requirements.