[build] Requesting readable raylib version file in source releases

[orcmid]

This Feature request is inspired by Pull Request #2856.

It would be very hand for the raylib\ source-code folder to carry an identification of the release that is installed. This is different than preprocessor definition. It would be something visible in a file browser and also usable in scripts.

My one thought is a text file or even a file name that reflects the version. I am also thinking that scripts for setting one [or more] environment variable. A *.bat and a *.sh should cover the bases. I'm uncertain what would be helpful in CMake or plain make variations, so have no proposal about that.

The main branch on GitHub could carry a *-dev version identifier.

I have run across this situation while initiating a VCrayVerify sub-project to run through raylib\ examples and realizing that there are breaking changes to be worked around among raylib releases and work-in-progress. There can be breakage in the examples as well, of course, and I want a way to show what raylib version is being used in the output of VCrayVerify operations.

I could handle this manually of course, but I think a solution in the releases and main would be more helpful.

[raysan5]

Despite being a feature that could be useful for some users, I feel it adds an additional level of complexity and maintenance requirement to the sources. Shouldn't #2856 be enough for most use cases? What real need of an additional file is required? I have my doubts... I think most users don't need it.

In any case I keep this issue open for further discussion.

[orcmid]

Issue #2856 is about having a version available to the C compiler preprocessor. I am talking about something that can be seen visually (in file explorer and an editor) and also useable in scripts (by setting environment variables).

I agree that more care is required in maintenance (although only at release time), the same times #2856 preprocessor settings are changed, if and when available.

This has some use for developers. I have a test-fixture use case that had me think of this. I am thinking it is particularly useful in troubleshooting and assuring that a particular version is the one in use when someone reports difficulty with something. My VCrayVerify and possible VCrayTest fixtures would make use of such a thing, including showing that information in the logs from shell scripts while also adapting to the raylib version in hand.

I may experiment with this in some testing I will be doing. It will have to fudge a file and some environment variables I have a case already for VCrayVerify. I can use it around existing-version raylib/examples/ files that depend on C11. There is at least one that depends on the C11-optional atomicity features that VC/C++ does not support yet. (Note that this also relies on some environment-variable version information already available for the VC/C++ being run.)

PS: VCrayApp could have used such information to automatically use the correct list of raylib files to compile and not stumble on filename breaking changes between 3.x and 4.x. As it is, users of that fixture need to make a manual adjustment.

PPS: On the development "branch" I don't think fine-grained versioning is required. People working from clones and master are supposed to know what they are doing, know how to keep up with possible breaking changes there, and know to never use it for their own releases. So just having a "-dev' (or -bis) suffix should suffice.

[raysan5]

@orcmid For now I think this is a very specific use case and I prefer to add a new file for it, isn't it possible to fetch that information from the define in raylib.h? At this moment raylib version info is provided in the following ways:

1. Version string in raylib.h

#define RAYLIB_VERSION  "4.5-dev"

2. Values definition in raylib.h

#define RAYLIB_VERSION_MAJOR 4
#define RAYLIB_VERSION_MINOR 5
#define RAYLIB_VERSION_PATCH 0

3. Constant compilation symbol in rcore.c

RLAPI const char *raylib_version = RAYLIB_VERSION;  // raylib version exported symbol, required for some bindings

I prefer to avoid a 4th method of exposing raylib version for a very specific use case that most users probably don't need.

PS. raylib has no development branch, only master branch reflecting "4.5-dev" because is always the development branch, so, now, with the _MAJOR, _MINOR and _PATCH addition, Am I supposed to keep increasing _PATCH every commit? No way.

[orcmid]

@raysan5

PS. raylib has no development branch, only master branch reflecting "4.5-dev" because is always the development branch, so, now, with the _MAJOR, _MINOR and _PATCH addition, Am I supposed to keep increasing _PATCH every commit? No way.

No, you would use patch only if you did a bug-fix release that involve correction, no feature changes.

[orcmid]

@raysan5

@orcmid ... isn't it possible to fetch that information from the define in raylib.h? At this moment raylib version info is provided in the following ways:

1. Version string in raylib.h

#define RAYLIB_VERSION  "4.5-dev"

I see that. Did it start with 4.0?

I'm not sure how to work with tat. There's no grep and awk in the Windows run-time console applications, so I need to figure out how to fish it out of raylib.h with only the tools on Windows plus the VS Build Tools for VC/C++. I don't think I can do this without having a program for it.

I think I can fudge that though. I will see if I can use the trial program that confirms the setup to also put the version from raylib.h where I can use it.

[chriscamacho]

you could make a very small console app the prints the version string, the build process / github task could later run the tiny app and pipe it into a file...

#include "raylib.h"
#include "stdio.h"
void main(void) { printf(RAYLIB_VERSION); }

[orcmid]

Thanks @chriscamacho

I will do something like that. I was thinking of redirecting into a file as a one-line script that my larger script can use to set RAYLIB_VERSION as an environment variable.

I see now that I have to do this before compiling a cache of the standard raylib files, because that's raylib version dependent. It also has to allow for the fact that older releases of raylib do not have that pre-processor definition.

Thanks for the suggestion. I do need a separate little app that gets compiled and run to establish the version being operated/verified. This will solve a problem I have in VCrayApp also, and I will incorporate this in the next VCrayApp release.