8000 HTS_VERSION macro · Issue #794 · samtools/htslib · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

HTS_VERSION macro #794

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
jkbonfield opened this issue Nov 8, 2018 · 1 comment
Closed

HTS_VERSION macro #794

jkbonfield opened this issue Nov 8, 2018 · 1 comment

Comments

@jkbonfield
Copy link
Contributor
jkbonfield commented Nov 8, 2018 •
edited
Loading

Htslib exports an hts_version function, those code is:

const char *hts_version()
{
    return HTS_VERSION;
}

where HTS_VERSION is in version.h, eg currently mine is #define HTS_VERSION "1.9-63-g5d8bf3f".

We need to ability to be able to detect this at configure time, preferably without needing to compile and execute a test program so we permit cross-compiling. As this isn't even a static variable, it's hard to glean this from symbol table grepping.

Cleaner would simply be moving HTS_VERSION to a public header file instead. Perhaps with HTS_VERSION_MAJOR and HTS_VERSION_MINOR numerical equivalents too. See ZLIB_VER macros in zlib.h for an example.

Even the string form alone is parseable from bourne shell. Eg for a.b.c style versions

HTS_VERSION=`sed -n 's/.*#define *HTS_VERSION *"\([^"]*\)"/\1/p' "$dir/hts.h"`
v1=`expr "${HTS_VERSION:-}" : '\([[0-9]]*\)'`
v2=`expr "${HTS_VERSION:-}" : '[[0-9]]*\.\([[0-9]]*\)'`
v3=`expr "${HTS_VERSION:-}" : '[[0-9]]*\.[[0-9]]*\.\([[0-9]]*\)'`

have_vers=`expr "${v1:-0}" "*" 1000000 + "${v2:-0}" "*" 1000 + "${v3:-0}"`
jmarshall added a commit to jmarshall/htslib that referenced this issue Sep 20, 2019
@jmarshall
Add HTS_VERSION #define for use in compile-time #if checks
d68e83f 
Add HTS_VERSION macro to aid writing preprocessor checks to test
for the presence of HTSlib facilities, e.g.,

  #if HTS_VERSION >= 101000  // Check for v1.10 or later

Like the version numbers in version.sh, NEWS, and the manual pages,
this must be updated manually (or via mkrelease) as part of the commit
that merges develop to master during the release process.

When merging the tagged release commit back to develop, this must be
updated again (manually or via tag_release) as described in the comment
in <htslib/hts.h>.

Fixes samtools#794. (This has been added as 1.9.90, where .90 indicates an
in-development Git repository version leading up the next release.)
jmarshall added a commit to jmarshall/htslib that referenced this issue Sep 20, 2019
@jmarshall
Add HTS_VERSION #define for use in compile-time #if checks
211796c 
Add HTS_VERSION and HTS_VERNUM() macros, to aid writing preprocessor
checks to test for the presence of HTSlib facilities, e.g.,

  #if HTS_VERSION >= HTS_VERNUM(1,10,0)  // Check for v1.10 or later

Like the version numbers in version.sh, NEWS, and the manual pages,
this must be updated manually (or via mkrelease) as part of the commit
that merges develop to master during the release process.

When merging the tagged release commit back to develop, this must be
updated again (manually or via tag_release) as described in the comment
in <htslib/hts.h>.

Fixes samtools#794. (This has been added with an in-development subpatch number
of "+ 11", corresponding to the Makefile's TWO_TO_THREE_TRANSITION_COUNT.)
jmarshall added a commit to jmarshall/htslib that referenced this issue Oct 15, 2019
@jmarshall
Add HTS_VERSION #define for use in compile-time #if checks
b790e24 
Add HTS_VERSION and HTS_VERNUM() macros, to aid writing preprocessor
checks to test for the presence of HTSlib facilities, e.g.,

  #if HTS_VERSION >= HTS_VERNUM(1,10,0)  // Check for v1.10 or later

Like the version numbers in version.sh, NEWS, and the manual pages,
this must be updated manually (or via mkrelease) as part of the commit
that merges develop to master during the release process.

When merging the tagged release commit back to develop, this must be
updated again (manually or via tag_release) as described in the comment
in <htslib/hts.h>.

See samtools#794. (This has been added with an in-development subpatch number
of "+ 12", corresponding to the Makefile's TWO_TO_THREE_TRANSITION_COUNT.)
jmarshall added a commit to jmarshall/htslib that referenced this issue Oct 15, 2019
@jmarshall
Add HTS_VERSION #define for use in compile-time #if checks
bda4a55 
Add HTS_VERSION macro to aid writing preprocessor checks to test
for the presence of HTSlib facilities, e.g.,

  #if HTS_VERSION >= 101000  // Check for v1.10 or later

This XYYYZZ encoding of X.Y.Z into a single integer is the same encoding
as used by boost/version.hpp and similar. It would be nice to be able to
hide the encoding behind another macro and write tests like

  #if HTS_VERSION >= HTS_VERNUM(1,10,0)  // Doesn't work

but this is a syntax error when compiled against earlier HTSlibs that
don't define HTS_VERNUM().

Like the version numbers in version.sh, NEWS, and the manual pages,
this must be updated manually (or via mkrelease) as part of the commit
that merges develop to master during the release process.

When merging the tagged release commit back to develop, this must be
updated again (manually or via tag_release) as described in the comment
in <htslib/hts.h>.

Fixes samtools#794. (This has been added as 1.9.90, where .90 indicates an
in-development Git repository version leading up to the next release.)
jmarshall added a commit to jmarshall/htslib that referenced this issue Oct 15, 2019
@jmarshall
Add HTS_VERSION #define for use in compile-time #if checks
debead4 
Add HTS_VERSION and HTS_VERNUM() macros, to aid writing preprocessor
checks to test for the presence of HTSlib facilities, e.g.,

  #if HTS_VERSION >= HTS_VERNUM(1,10,0)  // Check for v1.10 or later

Like the version numbers in version.sh, NEWS, and the manual pages,
this must be updated manually (or via mkrelease) as part of the commit
that merges develop to master during the release process.

When merging the tagged release commit back to develop, this must be
updated again (manually or via tag_release) as described in the comment
in <htslib/hts.h>.

See samtools#794. (This has been added with an in-development subpatch number
of "+ 12", corresponding to the Makefile's TWO_TO_THREE_TRANSITION_COUNT.)
jmarshall added a commit to jmarshall/htslib that referenced this issue Oct 15, 2019
@jmarshall
Add HTS_VERSION #define for use in compile-time #if checks
4d2edaa 
Add HTS_VERSION macro to aid writing preprocessor checks to test
for the presence of HTSlib facilities, e.g.,

  #if HTS_VERSION >= 101000  // Check for v1.10 or later

This XYYYZZ encoding of X.Y.Z into a single integer is the same encoding
as used by boost/version.hpp and similar. It would be nice to be able to
hide the encoding behind another macro and write tests like

  #if HTS_VERSION >= HTS_VERNUM(1,10,0)  // Doesn't work

but this is a syntax error when compiled against earlier HTSlibs that
don't define HTS_VERNUM().

Like the version numbers in version.sh, NEWS, and the manual pages,
this must be updated manually (or via mkrelease) as part of the commit
that merges develop to master during the release process.

When merging the tagged release commit back to develop, this must be
updated again (manually or via tag_release) as described in the comment
in <htslib/hts.h>.

Fixes samtools#794. (This has been added as 1.9.90, where .90 indicates an
in-development Git repository version leading up to the next release.)
@jmarshall jmarshall mentioned this issue Oct 15, 2019
Merged
@jmarshall
Copy link
Member

The common need is for HTSlib-using programs to be able to report the version of HTSlib that they are running against, as it's this that determines the behaviour observed and in particular what library bugs may have been fixed. Hence an hts_version() function whose result is determined by code in the shared library being run against — which might be a later version than the one the program was originally compiled against. See c2e9391, which added the function and removed an embryonic #define.

The slightly-less common need is for programs to be able to enquire about HTSlib's capabilities at compile time, and emit an understandable #error or (if they are overachievers) adjust their code accordingly. Projects that use configure can write a configure test to do a trial compilation of the capability they're interested in (even when cross-compiling), but not everybody is using configure.

When I added hts_version() back in 2013, I anticipated that interesting new HTSlib capabilities that people would want to enquire about would often be accompanied by #defines that they could coincidentally check for (e.g., fancy array resizing is advertised by #ifdef HTS_RESIZE_CLEAR), but this has mostly not been the case — most interesting stuff is in new API functions and invisible to the preprocessor.

So it would be useful to wrap all this up in a preprocessor version macro in a public header (even though that's the antithesis of the autoconf mindset 😄). It's not as simple as just moving something to a public header, as you need to figure out how it gets updated. Unlike hts_version(), whose value is burnt into the library when it is built, you don't want a public header to be dependent on configuration or building — cf #559 (comment) and the following conversation.

See PR #951 for a proposal for a HTS_VERSION macro in htslib/hts.h that is manually updated (or really via the mkrelease script) during the preparation of a release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@jmarshall @jkbonfield
0