keymanapp
fix(ios): sample build script --debug detection
![keymanapp-test-bot[bot] avatar](https://avatars.githubusercontent.com/in/133554?v=4 "Published by a pub.dev verified publisher"){kind=small}
Currently falling over here:
[10:57:58 ](https://build.palaso.org/buildConfiguration/Keyman_iOS_TestSamplesAndTestProjects/448031?buildTab=log&linesState=978&logView=flowAware&focusLine=978)
cp: cannot stat '/Users/mcdurdin/buildAgent/work/99b311828f4ee7c/keyman/ios/build/Build/Products/Debug/KeymanEngine.xcframework': No such file or directory
The CI build for the samples calls the main samples' build script directly. That script triggers the iOS engine build script via dependency... and that call doesn't include the --debug flag. As a result, the Debug/ folder artifacts don't exist - just the Release/ ones.
I'm not sure what the best way is to work around the issue at the moment - we can't pass --debug as an option on dependency builds, after all - so I've put this PR into draft mode for the time being.
I'm not sure what the best way is to work around the issue at the moment - we can't pass
--debugas an option on dependency builds, after all - so I've put this PR into draft mode for the time being.
Debug flag is supposed to be handled for dependency builds, I thought. If not, we should fix that separately.
# `builder_is_debug_build` appears to fail here, while referring to the option does not?
# Perhaps it's due to being within a function?
if builder_has_option --debug; then
Let's get this fixed in builder, will open an issue
The one thing I don't like about the fix is that it results in less-documented build scripts - I'd originally specified the --debug option in those places so that they could have better-specialized descriptions.
That said... I guess it's a bit late in the release cycle to tweak that, eh?
The one thing I don't like about the fix is that it results in less-documented build scripts - I'd originally specified the
--debugoption in those places so that they could have better-specialized descriptions.That said... I guess it's a bit late in the release cycle to tweak that, eh?
It's best if the build scripts don't need more information about --debug. We really want them to be consistent throughout.
The description "Activates developer-friendly debug mode for unit tests where applicable" shouldn't be necessary. "--debug" means developer-friendly debug mode, that's its entire purpose. And "for unit tests" should be self-evident. If it isn't, then we should look at updating our wikis (not that we have one for build.sh at present).
The one thing I don't like about the fix is that it results in less-documented build scripts - I'd originally specified the
--debugoption in those places so that they could have better-specialized descriptions.That said... I guess it's a bit late in the release cycle to tweak that, eh?
It's best if the build scripts don't need more information about
--debug. We really want them to be consistent throughout.The description "Activates developer-friendly debug mode for unit tests where applicable" shouldn't be necessary. "--debug" means developer-friendly debug mode, that's its entire purpose. And "for unit tests" should be self-evident. If it isn't, then we should look at updating our wikis (not that we have one for build.sh at present).
Eh, given our success rate of thinking things in code are self-evident within the team, I'm not terribly optimistic about external developers finding all the implications of --debug self-evident per project.
I think you are missing the point. build.sh is intended to be consistent across projects. If it isn't, then we should try and make it so. This is especially the case for a common flag like --debug
