EDIT: ahh scrap that I thought this was a build number, but it isn’t, it’s a representation of the Project Version.
Is there an automatic build number available? If not how do people deal with it?
Just looking into using the versionNumber, however it doesn’t seem to increase with each build although it’s a high number so it seems it did at one point. Is there some code I need or Projucer setting required to make it increment?
__DATE__
can act as build identifier
I discovered Time:: getCompilationDate() recently:
https://docs.juce.com/master/classTime.html#a4bcdd6953120779dfba089902a91983d
Matt
Problem with that one is that it’s only updated when the .obj with the implementation is rebuild. Which might not be when you expect it to be because all of the source files to generate the obj might still be the same on the next build. Cool to have it, but not the same as “the date this binary was linked”.
If you’re always doing clean rebuilds, then this isn’t a problem though.
JUCE modules are always rebuilt. In CMake speak, they are interface targets, so they will always be recompiled each time the project is built.
Hmm, I don’t yet use cmake - at least not for JUCE based projects and I had a situation in which a prerelese build expiry screen which was triggered due to a calculation involving this function appeared before it was intended to appear. A clean rebuild resolved this.
But despite this: are you sure? I have some rather huge JUCE modules and if they are rebuild each time I hit CMD+R, I’d have to restructure them to be regular (i.e non-interface) static libraries. Otherwise the turnaround times would be a huge productivity damper.
Yes, in both cmake and the projucer this is how the JUCE build process works. If you have custom modules that don’t actually reference JUCE types, I would highly recommend making them regular C++ libraries instead.
I’m in the same camp as @TurboCyber, with both Projucer and cmake my experience is that building from scratch takes a lot longer than making a change to either the top level or one of my custom modules, but of course this is just anecdata and I’ve no actual concrete knowledge to explain my experience.
Perhaps it’s just something Xcode is doing?
Maybe I missed the actual answer in this older thread, but I don’t think it was ever answered.
I’m looking for the same thing. I want a simple way to auto increment build number using CMake for an iOS app.
Anyone doing this?
Increment based on what? The git tag?
If that’s your strategy, I would recommend the bumpversion tool. Simply hard-code your desired version number into your CMakeLists.txt (or another text file that CMake reads), and then make it a policy to run bumpversion any time the version should be bumped. You can define arbitrary ways to encode the version into certain source files, so you can update it everywhere it’s used in one command.
But ultimately, it boils down to hard-coding the version as a string literal somewhere within the source tree. I would not recommend trying to do something like git describe during CMake configure.
Thanks, I’ll look into that.
It occurs to me that while I mentioned using CMake, because it’s an iOS app, I’m really using CMake for configuration and Xcode for actual building. It’s the AppStore & TestFlight that want build numbers so for some reason I thought there might be some Xcode answer to auto incrementing each time the app is built.
There probably is a way… You can set low-level XCode properties using a custom .xcconfig file, and you can also set them through cmake target properties.
