Skip to content

Support optional build numbers in Windows version resources - #12

Open
Quantumyilmaz wants to merge 1 commit into
libxse:mainfrom
QTR-Modding:feature/resource-build-number
Open

Quantumyilmaz wants to merge 1 commit into
libxse:mainfrom
QTR-Modding:feature/resource-build-number

Conversation

@Quantumyilmaz

Copy link
Copy Markdown

Use the optional build number from set_version in the numeric and string Windows version resources, instead of always appending zero. Existing projects keep zero when no build number is set. Reject values outside the Windows 16-bit component range.

@shad0wshayd3

Copy link
Copy Markdown
Contributor

What is the purpose of formatting the value in build_number as a date and then casting it back to a number with tonumber in L184-185?

@Quantumyilmaz

Copy link
Copy Markdown
Author

What is the purpose of formatting the value in build_number as a date and then casting it back to a number with tonumber in L184-185?

Because xmake's build option supports date patterns such as {build = "%j"}. Ofc literal strings like "7" stay unchanged. tonumber is just to check the windows range 0-2^16-1

@qudix

qudix commented Oct 30, 2026

Copy link
Copy Markdown
Contributor

doesn't semver already have a build field?

@Quantumyilmaz

Copy link
Copy Markdown
Author

I want to be able to set the fourth version component directly, like 1.2.3.7.
semver's +7 is build metadata, not a fourth numeric component.

clib currently hardcodes that component to 0.
This PR makes it configurable through xmake's build option...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants