Skip to content

[flutter_tools] Add additional bash entrypoint for running dart sdk directly#57257

Merged
christopherfujino merged 20 commits intoflutter:masterfrom
chris-forks:add-dart-bash-wrapper
May 18, 2020
Merged

[flutter_tools] Add additional bash entrypoint for running dart sdk directly#57257
christopherfujino merged 20 commits intoflutter:masterfrom
chris-forks:add-dart-bash-wrapper

Conversation

@christopherfujino
Copy link
Contributor

@christopherfujino christopherfujino commented May 14, 2020

Description

The bash side of #53470.

The windows parts of this PR were reviewed in #56845.

This PR:

  1. Moves the previous //bin/flutter shell script to //bin/shared.sh.
  2. The main execution code in //bin/shared.sh is wrapped in the function shared::execute().
  3. The definition of the variables PROG_NAME and BIN_DIR and the functions follow_links() and path_uri(), as these will be defined in the entrypoints, before invoking shared::execute().
  4. At the end of shared_execute(), there is a switch-case over the BIN_NAME, or the filename of our entrypoint, which determines whether or not we invoke the dart binary directly or the flutter_tools snapshot we've created.
  5. Creates two new entrypoint scripts, //bin/flutter and //bin/dart, which at this point have all the same code. It defines the variables and functions from step 3, and then invokes shared::execute "$@", passing it the command-line args.
  6. Updates .cirrus.yml to trigger all steps if editing one of the bash scripts in flutter/bin.

To help code review, I uploaded a diff from master's //bin/flutter and this branch's //bin/shared.sh, which should be easier to read than the PR diff.

Note, I merged in this PR, which was already code reviewed. Thus, the changes to *.bat files should be approved already. Feel free to double check however :).

Related Issues

Part of #57063.

Checklist

Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]). This will ensure a smooth and quick review process.

  • I read the [Contributor Guide] and followed the process outlined there for submitting PRs.
  • I signed the [CLA].
  • I read and followed the [Flutter Style Guide], including [Features we expect every widget to implement].
  • I read the [Tree Hygiene] wiki page, which explains my responsibilities.
  • I updated/added relevant documentation (doc comments with ///).
  • All existing and new tests are passing.
  • The analyzer (flutter analyze --flutter-repo) does not report any problems on my PR.
  • I am willing to follow-up on review comments in a timely manner.

Breaking Change

Did any tests fail when you ran them? Please read [Handling breaking changes].

  • No, no existing tests failed, so this is not a breaking change.
  • Yes, this is a breaking change. If not, delete the remainder of this section.
    • I wrote a design doc: https://flutter.dev/go/template Replace this with a link to your design doc's short link
    • I got input from the developer relations team, specifically from: Replace with the names of who gave advice
    • I wrote a migration guide: Replace with a link to your migration guide

@christopherfujino christopherfujino requested review from jonahwilliams and removed request for jonahwilliams May 15, 2020 18:35
@christopherfujino christopherfujino requested review from jonahwilliams and removed request for jonahwilliams May 15, 2020 18:47
@christopherfujino
Copy link
Contributor Author

Argh, looks like I borked CI again, lemme investigate...

christopherfujino and others added 2 commits May 15, 2020 17:24
Co-authored-by: Jonah Williams <[email protected]>
Co-authored-by: Jonah Williams <[email protected]>
@christopherfujino
Copy link
Contributor Author

cc @gspencergoog and @jcollins-g for bash sanity check

Copy link
Contributor

@gspencergoog gspencergoog left a comment

Choose a reason for hiding this comment

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

Also, try and wrap the comments at 80 columns.


# Convert a filesystem path to a format usable by Dart's URI parser.
function path_uri() {
# Reduce multiple leading slashes to a single slash.
Copy link
Contributor

Choose a reason for hiding this comment

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

What about multiple embedded slashes? e.g. "/foo//bar//baz".
Also, what about things like "/foo/../bar/./baz"?

Actually, this looks like a bug in follow_links. Why don't you just fix follow_links to not emit double-leading slashes if $PWD is "/", which should be the only time it will emit a double slash.

@@ -35,158 +34,10 @@ function path_uri() {
echo "$1" | sed -E -e "s,^/+,/,"
Copy link
Contributor

Choose a reason for hiding this comment

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

Same here: I think follow_links just needs to not emit double-slashes.

Co-authored-by: Greg Spencer <[email protected]>
christopherfujino and others added 4 commits May 16, 2020 19:40
Co-authored-by: Greg Spencer <[email protected]>
Co-authored-by: Greg Spencer <[email protected]>
Co-authored-by: Greg Spencer <[email protected]>
Co-authored-by: Greg Spencer <[email protected]>
Copy link
Contributor

@jonahwilliams jonahwilliams left a comment

Choose a reason for hiding this comment

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

LGTM

@jonahwilliams
Copy link
Contributor

(for batch script :) )

# For "flock", the lock is released when the file descriptor goes out of
# scope, i.e. when this function returns. The lock is released via
# a trap when using "shlock".
if hash flock 2>/dev/null; then
Copy link
Contributor

Choose a reason for hiding this comment

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

What about using the mkdir method described in this FAQ, at least as a fallback when flock doesn't exist? It seems more reliable than shlock, and would probably work on platforms without either one: http://mywiki.wooledge.org/BashFAQ/045

It goes something like this:

 lockdir=/tmp/myscript.lock
 if mkdir "$lockdir"
 then
     echo >&2 "successfully acquired lock"

     # Remove lockdir when the script finishes, or when it receives a signal
     trap 'rm -rf "$lockdir"' 0    # remove directory when script finishes

     # Optionally create temporary files in this directory, because
     # they will be removed automatically:
     tmpfile=$lockdir/filelist

 else
     echo >&2 "cannot acquire lock, giving up on $lockdir"
     exit 0
 fi

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@gspencergoog both of your suggestions (this one and the change to follow_links()) seem worth doing. However, is it all right if I make those changes in a follow-up PR so that if it breaks the world, we still have these scripts factored out into multiple entrypoints.

As far as I can tell, the problems you've pointed out won't be exacerbated by this change, right?

Copy link
Contributor

Choose a reason for hiding this comment

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

Sure, that's fine. We should address them, though.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sure, that's fine. We should address them, though.

pinky swear :)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Filed #57512 to track.

Copy link
Contributor

Choose a reason for hiding this comment

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

There are some poorly implemented userland filesystems where the mkdir trick doesn't work, but those are edge cases on an edge case. It's a pretty solid backup for flock.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

There are some poorly implemented userland filesystems where the mkdir trick doesn't work, but those are edge cases on an edge case. It's a pretty solid backup for flock.

sigh, it seems like BASH scripting is all about choosing which edge cases you want to optimize for...

Copy link
Contributor

Choose a reason for hiding this comment

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

There's another case that is an edge case and a problem: If I'm mounting the flutter dir over a file share, and I access it from both a Linux system and a Mac system simultaneously, then the locking won't hold, since one is using flock and one is using shlock (or mkdir). They'll happily overwrite each other then.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is true. Using the same repo from multiple host OSes is not supported anyway (the cached artifacts can't be shared), but we should detect this.

Copy link
Contributor

Choose a reason for hiding this comment

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

BTW, I put up a draft PR to try and address some of this (although it doesn't address the two-hosts problem): #57590

@christopherfujino
Copy link
Contributor Author

Also, try and wrap the comments at 80 columns.

Done

Copy link
Contributor

@gspencergoog gspencergoog left a comment

Choose a reason for hiding this comment

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

32384589-a60f0e74-c078-11e7-9bc1-e5b5287aea9d

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants