Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore(common): maintenance on build scripts - cd #11329

Merged
merged 8 commits into from
May 3, 2024

Conversation

mcdurdin
Copy link
Member

@mcdurdin mcdurdin commented May 1, 2024

Fixes #11324.

  • Always cd "$THIS_SCRIPT_PATH"
  • Remove unnecessary cd from all build.sh
  • Remove unnecessary set -eu from all build.sh (and # set -x)
  • Replace old build-utils.sh incantation in a few build.sh scripts
  • Builder scripts all now use resources/build/builder.inc.sh, and other scripts use build-utils.sh: if you don't call builder_describe and builder_parse, then you are not a builder script!

@keymanapp-test-bot skip

@@ -5,13 +5,10 @@
THIS_SCRIPT="$(readlink -f "${BASH_SOURCE[0]}")"
. "${THIS_SCRIPT%/*}/../../../resources/build/build-utils.sh"
## END STANDARD BUILD SCRIPT INCLUDE
EX_USAGE=64
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unused legacy cruft!

@mcdurdin mcdurdin marked this pull request as draft May 1, 2024 03:57
@mcdurdin
Copy link
Member Author

mcdurdin commented May 1, 2024

Okay, one problem here is that build-utils.sh is used for both builder scripts and other utility scripts, some of which are supposed to not change folder (e.g. mkver.inc.sh).

Two ways to fix:

  • Have a separate include that is intended to be just for builder scripts. This involves some shuffling:
    • Rename build-utils.sh to build-utils.inc.sh. (this is just tidy up)
    • Builder scripts should source a new resources/build/builder.inc.sh, and other scripts should source resources/build/build-utils.inc.sh.
    • resources/builder.inc.sh remains unchanged (perhaps rename to disambiguate with resources/build/builder.inc.sh)
  • Or, add a BUILDER_NO_CD flag to scripts that care about initial folder
    • alt. could pushd/popd but that looks uglier.

@rc-swag
Copy link
Contributor

rc-swag commented May 1, 2024

Okay, one problem here is that build-utils.sh is used for both builder scripts and other utility scripts, some of which are supposed to not change folder (e.g. mkver.inc.sh).

Two ways to fix:

It took me a while to even understand the problem you are solving.
Let me just put it in my words to see if it makes sense. If you add the line cd "$THIS_SCRIPT_PATH" to builder.inc.sh. builder.inc.sh is sourced in build-utils.inc.sh. So now all the subprojects that are sourcing build-utils.inc.sh will have the directory changed to the script path pf the calling script. This is not desirable eg mkver.inc.sh in which you want it to be the directory it is currently in at the time you source build-utils.inc.sh .
I would go with BUILDER_NO_CD flag. That is because adding another script just to not do a cd seems confusing.
What about If $THIS_SCRIPT_PATH was called $EXECUTE_PATH then for those scripts like that do not want to change directory set the $EXECUTE_PATH to pwd directory.

@mcdurdin
Copy link
Member Author

mcdurdin commented May 1, 2024

Let me just put it in my words to see if it makes sense. If you add the line cd "$THIS_SCRIPT_PATH" to builder.inc.sh. builder.inc.sh is sourced in build-utils.inc.sh. So now all the subprojects that are sourcing build-utils.inc.sh will have the directory changed to the script path pf the calling script. This is not desirable eg mkver.inc.sh in which you want it to be the directory it is currently in at the time you source build-utils.inc.sh .

Yep.

I would go with BUILDER_NO_CD flag. That is because adding another script just to not do a cd seems confusing.
What about If $THIS_SCRIPT_PATH was called $EXECUTE_PATH then for those scripts like that do not want to change directory set the $EXECUTE_PATH to pwd directory.

I kinda started to go this way then realised I'd need to fixup all the random scripts that include build-utils.sh to do this, and it would still leave us in the spot where api contract for builder scripts is vague. So I ended up:

  1. Creating resources/build/builder.inc.sh which imports build-utils.sh and also does the cd
  2. Updating all builder-compliant scripts to use that one
  3. Remaining scripts continue to use build-utils.sh
  4. resources/builder.inc.sh may be renamed in future to avoid confusion

@rc-swag
Copy link
Contributor

rc-swag commented May 2, 2024

4. resources/builder.inc.sh may be renamed in future to avoid confusion

Yes I think that needs to happen, something that helps reflect what it does the resources/build/builder.inc.sh doesn't. Actually it is really the other way around isn't?. the later is an extension

@mcdurdin
Copy link
Member Author

mcdurdin commented May 2, 2024

  1. resources/builder.inc.sh may be renamed in future to avoid confusion

Yes I think that needs to happen, something that helps reflect what it does the resources/build/builder.inc.sh doesn't. Actually it is really the other way around isn't?. the later is an extension

I think resources/builder.inc.sh should become resources/build/builder.implementation.inc.sh or something like that (better not to have it in resources/ directly).

@mcdurdin mcdurdin force-pushed the chore/common/11324-this-script-path branch from 959137a to e1e7448 Compare May 2, 2024 04:45
Fixes #11324.

* Always `cd "$THIS_SCRIPT_PATH"`
* Remove unnecessary `cd` from all build.sh
* Remove unnecessary `set -eu` from all build.sh (and `# set -x`)
* Replace old build-utils.sh incantation in a few build.sh scripts
Note: there is a bit of potential confusion about the difference between
/resources/builder.inc.sh (the full implementation for builder scripts),
and /resources/build/builder.inc.sh (the source script that builder
scripts should always use).

This allows us to make assumptions that will always be true for builder
scripts that may not be true for other scripts, such as setting base
folder.
builder_describe and builder_parse should come before other tests, so
that (a) scripts can return --help details, and (b) so that
builder.inc.sh can tell that the script is a valid builder script, even
if environment means that the script will not otherwise run.
This prevents issues where Windows-style path pollutes path strings
with $KEYMAN_ROOT variable. It typically will only be readonly if we are
setting the variable in our own scripts
@mcdurdin mcdurdin force-pushed the chore/common/11324-this-script-path branch from e1e7448 to 41af900 Compare May 2, 2024 08:54
@mcdurdin mcdurdin marked this pull request as ready for review May 2, 2024 22:49
@@ -23,6 +18,11 @@ builder_describe "Keyman common Linux modules" \

builder_parse "$@"

if [[ $BUILDER_OS != linux ]]; then
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A builder script must always call builder_describe and builder_parse, so do our platform checks after that. This allows the script to be called with --help even when on the wrong platform, so user can get info about it.

Comment on lines +21 to +24
if [[ $BUILDER_OS != mac ]]; then
builder_echo grey "Platform is not macOS; skipping common/mac"
exit 0
fi
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A builder script must always call builder_describe and builder_parse, so do our platform checks after that. This allows the script to be called with --help even when on the wrong platform, so user can get info about it.

Copy link
Contributor

@jahorton jahorton left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Noting some of the previous conversation and the documentation I saw in the file-changes, I think we have a few removals of change-directory that need to get restored.

common/linux/build.sh Show resolved Hide resolved
ios/samples/KMSample1/build.sh Outdated Show resolved Hide resolved
ios/samples/KMSample2/build.sh Outdated Show resolved Hide resolved
mac/build.sh Outdated Show resolved Hide resolved
Copy link
Contributor

@rc-swag rc-swag left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

@mcdurdin mcdurdin merged commit c997965 into master May 3, 2024
25 checks passed
@mcdurdin mcdurdin deleted the chore/common/11324-this-script-path branch May 3, 2024 23:15
@keyman-server
Copy link
Collaborator

Changes in this pull request will be available for download in Keyman version 18.0.28-alpha

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

Successfully merging this pull request may close these issues.

chore(common): use cd "$THIS_SCRIPT_PATH" in build-utils.sh
4 participants