You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
My preference would be to let a higher level of build system handle checking the file times, like Bazel or package:build or native assets.
👍 Great thinking about how this integrates in the larger eco system.
I think the FFIgen (and JNIgen) should be able to report the list of dependencies (#1008). We don't want every user of FFIgen (and JNIgen) to manually come up with a list of dependencies.
The logic of checking the files timestamps could maybe live in a shared package that then FFIgen, JNIgen, and native_assets_builder can reuse.
One question to ask is what abstraction to use for listing dependencies:
File paths
Directory paths (which would mean all files transitively in that directory, and it also means that if someone adds a file in such directory it's added).
Glob patterns? (which would mean that any files added to the file system matching such pattern would trigger a rebuild). -> But not every build system wrapping FFIgen/JNIgen might be able consume glob patterns (native assets, package:build, ...)
Pulling some learnings from #977.
👍 Great thinking about how this integrates in the larger eco system.
I think the FFIgen (and JNIgen) should be able to report the list of dependencies (#1008). We don't want every user of FFIgen (and JNIgen) to manually come up with a list of dependencies.
The logic of checking the files timestamps could maybe live in a shared package that then FFIgen, JNIgen, and native_assets_builder can reuse.
One question to ask is what abstraction to use for listing dependencies:
Originally posted by @dcharkes in #977 (comment)
Some more edge cases to consider -
Originally posted by @mannprerak2 in #977 (comment)
I think the first step is to output a list of dependencies.
The text was updated successfully, but these errors were encountered: