#109 gdl_version_ge: utility to check order of GDL versions(2)

open
nobody
None
1
2011-08-20
2011-07-27
No

GDL users can now automatically detect if they are using GDL and if so, which version of GDL they are using.
However, they cannot easily check the version chronology, so tests requiring "a version at least as new as
version X" will in some cases wrongly infer that the version being used is older than it really is.
This will cause some GDL scripts to unnecessarily use "private" hacks to deal with missing features
or bugs even though the hacks are in fact not needed due to GDL having been improved.
Alternatively, tests can only test for very specific version numbers. In feature request 3148359
an example function is proposed. See
https://sourceforge.net/tracker/?func=detail&aid=3148359&group_id=97659&atid=618686

In answer to the question, why put it in the GDL source tree: because otherwise people who
want their scripts to function correctly using older versions while still taking advantage of bug
fixes and new features will have to each rewrite the utility from scratch. i am most happy to
post bug reports for GDL, but i'm not going to wait for the bug fix before implementing my
own hack (if i can find a hack). At the same time, i would prefer my scripts to automatically
use the improved GDL version when that's done.

BTW, sorry for the slow reply. i assume that i have to open a new "artifact" since the
old one was closed.

Discussion

  • Alain C.

    Alain C. - 2011-08-20

    I created a EPOCH field in !GDL structure (in the CVS). This field is set up at the time of the compilation. Please try it and make suggestions. I also agree we need such an information.

     
  • Alain C.

    Alain C. - 2011-08-20
    • priority: 5 --> 1
     
  • Boud Roukema

    Boud Roukema - 2011-09-02

    Sorry, but I don't think this solves the problem. For example, a debian-stable version might have a fairly
    recent compilation epoch from the CPP __DATE__ value because of minor patches applied by debian
    maintainers and recompilation, but this epoch will not represent the changes in the cvs version of GDL
    at that date. Also, a sysadmin compiling from source may compile an old version with private hacks.
    There are many reasons for recompiling where re-downloading from cvs is not always a good idea:
    development and system maintenance are two different goals :).

    However, your general idea is probably cleaner than implementing my "ge" function. But instead
    of the compilation date, IMHO what is needed is the date of the most recent code change.

    For example, in bash,

    export MOST_RECENT_CODE_DATE=`ls -lt src/*.[ch]pp|head -n 1| awk '{print $6 ":" $7}'|sed -e 's/:/-/g'`
    echo ${MOST_RECENT_CODE_DATE}

    gives me

    2011-08-31-17-15

    for the cvs download i made a few minutes ago. The "-" signs could be removed to make a
    purely numerical comparison possible. From a package development/maintenance point of view,
    i'm not sure whether a self-reference to the files of the package makes more sense as part of
    the C++ code or whether it should be an external script.

    Maybe within the autotools approach it should become a new .m4 file? I know almost nothing
    about the cmake approach.

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks