Closed kayagokalp closed 1 month ago
Yep, this is one of the first problems I ran into after starting at fuel. There is any issue for this in the fuels repo here
From memory it is also one of the main blockers for why we don't support windows as we need relative paths to resolve in the abigen! macro. I'm not sure what the best approach here is still. Ideally we would could use the functionality for what include_str!
provides. It could be worth searching if there are external crates that provide that functionality without being a macro, or looking at the source code of the macro itself to see if it can be ported to a regular function.
Utilising a build.rs
file is not a bad last resort but it would be nice to try and see if we could avoid it.
Yep, this is one of the first problems I ran into after starting at fuel. There is any issue for this in the fuels repo here
From memory it is also one of the main blockers for why we don't support windows as we need relative paths to resolve in the abigen! macro. I'm not sure what the best approach here is still. Ideally we would could use the functionality for what
include_str!
provides. It could be worth searching if there are external crates that provide that functionality without being a macro, or looking at the source code of the macro itself to see if it can be ported to a regular function.Utilising a
build.rs
file is not a bad last resort but it would be nice to try and see if we could avoid it.
Exactly 💯 I really want to do this without build.rs as well :) I wonder if ordered macro expansions possible without changing rust compiler, because with that we would be able to use include str 🤔
Could we force the ordering by making fuels-macros
depend on something else? My thinking is that this new dependency (or even dev-dependency) would be expanded before fuels-macros
, which could hopefully correct any path mangling?
It could be worth searching if there are external crates that provide that functionality without being a macro
If I'm reading this correctly, for file paths the evil way would be to inject a unique string into the source as a comment or attribute, then walk the filesystem looking for that unique string 🙃
We have an interesting problem,
abigen!
macro from sdk needs either a file location, or a raw abi string. Using file location fails becuase cargo flattens all packages before releasing them and changing the location we hold our abi file in. Using raw str is troublesome and error prone. We discussed usinginclude_str!
macro from std but then the problem is the order of macro expansions. We cannot ensure thatnclude_str!
is expanded beforeabigen!
.We can create a
build.rs
file that updates the contents of the proxy abi raw str embedded in the code to come to a middle ground, where we use raw str for abigen macro but do not need to update it manually.