webcrypto:setup: CMake Error: The source directory does not exist

[xvrh]

I try to use this library in a small dart script (inside a flutter project), and I got:

Unsupported operation: package:webcrypto cannot be used from Dart or `pub run test` unless `flutter pub run webcrypto:setup` has been run for the current root project.

So I try:

> flutter pub run webcrypto:setup   
Building with assumed project root in:
/Users/xavier/projects/app/
Using package:webcrypto from /Users/xavier/.pub-cache/hosted/pub.dartlang.org/webcrypto-0.5.2
Generating build system with cmake
CMake Error: The source directory "/Users/xavier/.pub-cache/hosted/pub.dartlang.org/src" does not exist.
Specify --help for usage, or press the help button on the CMake GUI.
Generating with cmake failed, ensure you have dependencies!

Webcrypto version: 0.5.2

> flutter --version
Flutter 2.0.3 • channel stable • https://github.com/flutter/flutter.git
Framework • revision 4d7946a68d (6 days ago) • 2021-03-18 17:24:33 -0700
Engine • revision 3459eb2436
Tools • Dart 2.12.2

> cmake --version
cmake version 3.16.1

[xvrh]

It seems the code here https://github.com/google/webcrypto.dart/blob/master/bin/setup.dart#L64 is incorrect

The rootUri can be something likefile:///Users/xavier/.pub-cache/hosted/pub.dartlang.org/webcrypto-0.5.2

And

Uri.parse('file:///Users/xavier/.pub-cache/hosted/pub.dartlang.org/webcrypto-0.5.2').resolve('src');

gives file:///Users/xavier/.pub-cache/hosted/pub.dartlang.org/src

[prijindal]

To forcefully run this, in your file:

~/.pub-cache/hosted/pub.dartlang.org/webcrypto-0.5.2/bin/setup.dart

on line 64, replace

webcryptoRoot.resolve('src').toFilePath(),

with

webcryptoRoot.resolve('webcrypto-0.5.2/src').toFilePath(),

It is a temporary fix

[jonasfj]

Thanks for the report, I wonder how this worked locally on my machine.

[prijindal]

For a one liner fix with bash:

grep -rl "pkg\['rootUri'\]" $PUB_CACHE/hosted/pub.dartlang.org/webcrypto-0.5.2/bin/setup.dart | xargs sed -i "s/pkg\['rootUri'\]/pkg['rootUri']\+\"\/\"/g"

Make sure PUB_CACHE is setup in your path, or replace above appropriately

[maltemedocs]

Hey, I ran into a similar and I think linked bug, but please tell me if this should be a separate github issue.

But first, the command I'd use to fix the line 64 is this:

sed -i "64s#.*#webcryptoRoot.resolve('webcrypto-0.5.2/src').toFilePath(),#" ~/.pub-cache/hosted/pub.dartlang.org/webcrypto-0.5.2/bin/setup.dart

@prijindal, that's what you described to do manually in #20 (comment) - I am not sure in which way the grep command in your last comment would help instead.

But the cmake command did fail anyway for me:

flutter pub run webcrypto:setup Building with assumed project root in:
/home/user/project/
Using package:webcrypto from /home/user/snap/flutter/common/flutter/.pub-cache/hosted/pub.dartlang.org/webcrypto-0.5.2
Generating build system with cmake
CMake Error: The source directory "/home/user/project/.dart_tool/webcrypto" does not exist.
Specify --help for usage, or press the help button on the CMake GUI.
Generating with cmake failed, ensure you have dependencies!
pub finished with exit code 1

This makes no sense, because .dart_tool/webcrypto is not a source directory, it's the target. But the error seems to be in the setup.dart file, because running the cmake command manually from the project directory at that point works:

cmake -S /home/user/snap/flutter/common/flutter/.pub-cache/hosted/pub.dartlang.org/webcrypto-0.5.2/src/ -B .dart_tool/webcrypto 

Now, with the modification of the setup.dart file and the cmake being run once manually, flutter pub run webcrypto:setup and subsequently the tests did succeed.

Hope this helps some passersby to get the tests to work.

[maltemedocs]

For the log: the workaround in #20 (comment) needed to be adapted for 0.5.3, the line number changed from 64 to 66, as well as the path to 0.5.3:

sed -i "66s#.*#webcryptoRoot.resolve('webcrypto-0.5.3/src').toFilePath(),#" ~/.pub-cache/hosted/pub.dartlang.org/webcrypto-0.5.3/bin/setup.dart

But with the small fix in #40 merged this should be solved in general, without needing this workaround.