Resolve relative paths in additional_includes and additional_lib_directories

[dariyooo]

With source: source, path is resolved against the pubspec, but additional_includes and additional_lib_directories are passed through as-is. native_toolchain_c then resolves them against its build directory (.dart_tool/hooks_runner/shared/sqlite3/build/<checksum>/), so relative entries can never point at anything useful and only absolute paths work today.

This resolves both against the pubspec, matching path. Absolute entries pass through unchanged. Not breaking, since relative values are currently unusable.

The base is read from input.json['user_defines']['workspace_pubspec']['base_path'] because HookInputUserDefines.path() only resolves a single string.

Test added to test/hook/description_test.dart.

[simolus3]

Note that these options are intended to be used internally only.

If you want to add extensions, is it a requirement for you to link those statically? Dynamically loading extensions through a separate asset is much simpler, doesn't require changes to this package, and allows us to refine the build in the future (exposing new options puts constraints on that).

[simolus3]

It looks like there is no better way to do this at the moment, but us crawling through undocumented JSON structures doesn't seem great. I've opened dart-lang/native#3515 to ask for a proper API.

[dariyooo]

If you want to add extensions, is it a requirement for you to link those statically?

Sadly, I do not really see another option. l also thought about just compiling a complete sqlite dynamic library that has all symbols in it but I also do not see a way to load that.

[simolus3]

Out of interest, what extension are you trying to load (if it's public)? Most extensions can be configured to call SQLite APIs through function pointers, which means you don't need SQLite and the extension to be linked together statically.