KhronosGroup / KhronosGroup/OpenCOLLADA
Proposal: Provide support for Release information in the API
- Dominant language
- C++
- Stars
- 679
- Forks
- 260
- PR merge metrics
- No merged PRs in 30d
Description
I propose to add a headerfile to the installed API include files that contains preprocessor directives for the used library version, something similar to:
include/opencollada_version.h:
#ifndef OPENCOLLADA_VERSION
#define OPENCOLLADA_VERSION 1.6.68
#define OPENCOLLADA_VERSION_NUMBER 106068 // #.##.###
#define OPENCOLLADA_BUILDTYPE "CUSTOM" // or "RELEASE" when building from the release sources
#endif
- This allows us to take care of library incompatibilities when we need to support multiple incompatible API versions of the library (1.6.63 vs. 1.6.68 for example). Note that due to cross platform builds it is not guaranteed that a specific version of the library is available in the blender build environment, so we need a reliable method to handle this in the source code.
- Furthermore we can do easy library version comparison like #if OPENCOLLADA_VERSION < 106068 ...
- Furthermore you can tag the source as RELEASE or CUSTOM to be sure only the official released sources are marked as "RELEASE" while all other versions including the repository versions are marked as "CUSTOM"
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by locating how installed API headers are generated and how the library version is defined for releases. Review the proposed include/opencollada_version.h contents and the existing release or build metadata. Done means the installed headers expose reliable version, numeric-version, and RELEASE/CUSTOM information for consumers.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- api, build-system, release
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100