[flutter_tools] Add additional bash entrypoint for running dart sdk directly#57257
Conversation
95737fb to
db8096d
Compare
|
Argh, looks like I borked CI again, lemme investigate... |
c9835be to
afd26c4
Compare
afd26c4 to
5fa4c52
Compare
Co-authored-by: Jonah Williams <[email protected]>
Co-authored-by: Jonah Williams <[email protected]>
|
cc @gspencergoog and @jcollins-g for bash sanity check |
gspencergoog
left a comment
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
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,^/+,/," | |||
There was a problem hiding this comment.
Same here: I think follow_links just needs to not emit double-slashes.
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]>
Co-authored-by: Greg Spencer <[email protected]>
|
(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 |
There was a problem hiding this comment.
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
fiThere was a problem hiding this comment.
@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?
There was a problem hiding this comment.
Sure, that's fine. We should address them, though.
There was a problem hiding this comment.
Sure, that's fine. We should address them, though.
pinky swear :)
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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...
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
BTW, I put up a draft PR to try and address some of this (although it doesn't address the two-hosts problem): #57590
Done |

Description
The bash side of #53470.
The windows parts of this PR were reviewed in #56845.
This PR:
//bin/fluttershell script to//bin/shared.sh.//bin/shared.shis wrapped in the functionshared::execute().PROG_NAMEandBIN_DIRand the functionsfollow_links()andpath_uri(), as these will be defined in the entrypoints, before invokingshared::execute().shared_execute(), there is a switch-case over theBIN_NAME, or the filename of our entrypoint, which determines whether or not we invoke the dart binary directly or theflutter_toolssnapshot we've created.//bin/flutterand//bin/dart, which at this point have all the same code. It defines the variables and functions from step 3, and then invokesshared::execute "$@", passing it the command-line args..cirrus.ymlto trigger all steps if editing one of the bash scripts influtter/bin.To help code review, I uploaded a diff from master's
//bin/flutterand 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
*.batfiles 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.///).flutter analyze --flutter-repo) does not report any problems on my PR.Breaking Change
Did any tests fail when you ran them? Please read [Handling breaking changes].