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
Currently you need to provide extension to the binary file yourself, and its ugly. It seems like there are no convenient way to predict path to the binary, and the only option to get it is to pass --message-format=json argument to cargo build and listen for compiler-artifact message where package_id is the same as package we are trying to build (and target matches). Then its possible to extract path to the output binary via filenames and executable fields. But for example compiling target with type cdylib for Windows outputs 5 different files in filenames. Need to think how to properly handle this.
The text was updated successfully, but these errors were encountered:
Currently you need to provide extension to the binary file yourself, and its ugly. It seems like there are no convenient way to predict path to the binary, and the only option to get it is to pass
--message-format=json
argument tocargo build
and listen forcompiler-artifact
message wherepackage_id
is the same as package we are trying to build (and target matches). Then its possible to extract path to the output binary viafilenames
andexecutable
fields. But for example compiling target with typecdylib
for Windows outputs 5 different files infilenames
. Need to think how to properly handle this.The text was updated successfully, but these errors were encountered: