github-starred/MonitorControl

Fork 0

mirror of https://github.com/MonitorControl/MonitorControl.git synced 2026-05-15 14:15:55 -06:00

[GH-ISSUE #109] Unable to build master / auto-bump build number #79

New issue

Closed

opened 2026-05-05 04:59:15 -06:00 by gitea-mirror · 5 comments

gitea-mirror commented

2026-05-05 04:59:15 -06:00

Owner

Originally created by @JoniVR on GitHub (Jul 2, 2019).
Original GitHub issue: https://github.com/MonitorControl/MonitorControl/issues/109

I'm unable to build the current master.
I suspect the issue is related to the recent change in both Info.plist files. The $(CURRENT_PROJECT_VERSION) is mentioned in the error.

/Users/jonivanroost/Library/Developer/Xcode/DerivedData/MonitorControl-auqrumfsfpmipbaofbsrxddzggst/Build/Intermediates.noindex/MonitorControl.build/Debug/MonitorControlHelper.build/Script-28F6A5802283515F00A4ADCD.sh: line 8: $(CURRENT_PROJECT_VERSION): syntax error: operand expected (error token is "$(CURRENT_PROJECT_VERSION)")
Command PhaseScriptExecution failed with a nonzero exit code

Can anyone confirm this? Or is it just me?
@the0neyouseek @reitermarkus

We could really use #5

Originally created by @JoniVR on GitHub (Jul 2, 2019). Original GitHub issue: https://github.com/MonitorControl/MonitorControl/issues/109 I'm unable to build the current master. I suspect the issue is related to the recent change in both `Info.plist` files. The `$(CURRENT_PROJECT_VERSION)` is mentioned in the error. ``` /Users/jonivanroost/Library/Developer/Xcode/DerivedData/MonitorControl-auqrumfsfpmipbaofbsrxddzggst/Build/Intermediates.noindex/MonitorControl.build/Debug/MonitorControlHelper.build/Script-28F6A5802283515F00A4ADCD.sh: line 8: $(CURRENT_PROJECT_VERSION): syntax error: operand expected (error token is "$(CURRENT_PROJECT_VERSION)") Command PhaseScriptExecution failed with a nonzero exit code ``` ![image](https://user-images.githubusercontent.com/7591717/60548058-77266f80-9d21-11e9-85a9-25659171f9a3.png) Can anyone confirm this? Or is it just me? @the0neyouseek @reitermarkus We could really use #5

gitea-mirror

2026-05-05 04:59:15 -06:00

closed this issue
added the
bug
label

gitea-mirror commented

2026-05-05 04:59:22 -06:00

Author

Owner

@JoniVR commented on GitHub (Jul 2, 2019):

May have found a solution:
https://stackoverflow.com/a/56481486/6863743

edit: that didn't actually work.
What worked for me was to run

agvtool new-version -all 561

manually in the console to increase the build number and then discard the changes to the 2 updated info.plist files. Now it builds just fine again.. weird

@JoniVR commented on GitHub (Jul 2, 2019): ~May have found a solution: https://stackoverflow.com/a/56481486/6863743~ edit: that didn't actually work. What worked for me was to run ```sh agvtool new-version -all 561 ``` manually in the console to increase the build number and then discard the changes to the 2 updated info.plist files. Now it builds just fine again.. weird

gitea-mirror commented

2026-05-05 04:59:24 -06:00

Author

Owner

@JoniVR commented on GitHub (Aug 27, 2019):

Apparently I'm not the only person facing this issue. See discussion in #116.

@JoniVR commented on GitHub (Aug 27, 2019): Apparently I'm not the only person facing this issue. See discussion in #116.

gitea-mirror commented

2026-05-05 04:59:26 -06:00

Author

Owner

@robertbressi commented on GitHub (Aug 30, 2019):

Adding relevant comment from #116:

The build script Increase Build Number is failing because the value of /usr/libexec/PlistBuddy -c "Print CFBundleVersion" "${INFOPLIST_FILE}" is the string "$(CURRENT_PROJECT_VERSION)" (from the Xcode build settings), which can't be bumped because it's not a number.

I was going to suggest using agvtool to bump the build number, but then I realized two things:

It's not 100% clear what the build number is being used to represent or when it's intended to be bumped (e.g.: once per commit, once per PR, once per formal release); and

@reitermarkus removed agvtool usage back in May 2019

agvtool is nice because you don't have to juggle with one or more Info.plist files, you only have to set CURRENT_PROJECT_VERSION, but based on the answer to my comments above, it may not be suitable.

@robertbressi commented on GitHub (Aug 30, 2019): Adding relevant comment from #116: > The build script **Increase Build Number** is failing because the value of `/usr/libexec/PlistBuddy -c "Print CFBundleVersion" "${INFOPLIST_FILE}"` is the string **"$(CURRENT_PROJECT_VERSION)"** (from the Xcode build settings), which can't be bumped because it's not a number. > > I was going to suggest using **agvtool** to bump the build number, but then I realized two things: >1. It's not 100% clear what the build number is being used to represent or when it's intended to be bumped (e.g.: once per commit, once per PR, once per formal release); and >2. @reitermarkus removed agvtool usage back in May 2019 > > agvtool is nice because you don't have to juggle with one or more Info.plist files, you only have to set CURRENT_PROJECT_VERSION, but based on the answer to my comments above, it may not be suitable.

gitea-mirror commented

2026-05-05 04:59:28 -06:00

Author

Owner

@robertbressi commented on GitHub (Aug 31, 2019):

Build numbers are generally intended to identify when a "formal" build has been made, usually by CI. They aren't really relevant for individual contributors making day-to-day changes to the code. They're great to differentiate releases in an enterprise environment where there could be multiple builds of the same release version kicking around in QA and various stages of testing.

In fact, there are examples of fairly big open-source Swift projects (e.g.: https://github.com/kickstarter/ios-oss) which don't even bother with build number - they just set it to a static number and use version numbers to differentiate different releases of the product to users and developers.

I think, in the meantime before #5 is implemented, you should just get rid of the auto-incrementing build number script and do a manual commit before each release to bump up the build number (optionally) and the version string.

@robertbressi commented on GitHub (Aug 31, 2019): Build numbers are generally intended to identify when a "formal" build has been made, usually by CI. They aren't really relevant for individual contributors making day-to-day changes to the code. They're great to differentiate releases in an enterprise environment where there could be multiple builds of the same release version kicking around in QA and various stages of testing. In fact, there are examples of fairly big open-source Swift projects (e.g.: https://github.com/kickstarter/ios-oss) which don't even bother with build number - they just set it to a static number and use version numbers to differentiate different releases of the product to users and developers. I think, in the meantime before #5 is implemented, you should just get rid of the auto-incrementing build number script and do a manual commit before each release to bump up the build number (optionally) and the version string.

gitea-mirror commented

2026-05-05 04:59:33 -06:00

Author

Owner

@JoniVR commented on GitHub (Sep 15, 2019):

Fixed temporarily by reverting back to using the build number inside the plist. Might need a better solution in the future when we move to CI/CD, going to consider it closed for now.

@JoniVR commented on GitHub (Sep 15, 2019): Fixed temporarily by reverting back to using the build number inside the plist. Might need a better solution in the future when we move to CI/CD, going to consider it closed for now.

gitea-mirror referenced this issue

2026-05-05 07:02:44 -06:00

[PR #79] [MERGED] Reduce tries to 10. #1033