-
Notifications
You must be signed in to change notification settings - Fork 365
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cross install seems to be broken #1215
Comments
Not sure how we would support this, I guess we could make it error instead of falling back. Does that work? |
I guess the answer to that would be: no. 😁 Joking aside, I think it would be better to fail instead of leading to wrong results and "weird" errors. Ideally, that should be supported. I am not sure how different that actually is. I can download a tarball from crates.io and build ( |
my question then is, where do we put this binary? Say I do cargo install is basically sugar for
I'm not sure I see the purpose of making this work the same was as we do have something like this in discussion for #716, but its not really the same thing and would most likely not work in that capacity. |
I think there two steps before:
Only then you can build and move. But I agree, the "move" step isn't that useful. Unless you use |
I'm sorry, I still don't understand. There's no need for us to do anything special, we just need to do allow Line 11 in 99b8069
I guess my question is, what does what would the following do? $ cargo install ripgrep
....
Installed ripgrep
$ cross install --target armv7-unknown-linux-gnueabihf
....
??? I think the way to solve this is via |
Great, if that's so simple, then I think it should be done.
It does what
Yes, same as for My use-case: I want to cross compile binaries which are hosted on crates.io. Without the need to resolve the "correct" version first, and without the need to download a tarball. This is already solved by I am no interested in placing this into the default host But still, if one want to cross compile a binary publishes in crates.io, capturing the result in a different location using |
This is affecting us actually. The use case is this https://github.com/ofek/pyapp#building It's basically a wrapper for Python applications that is configured at build time with environment variables. Rather than making users check out the repo we instruct to just install which is much easier. Has a fix for this been merged yet? |
@ofek, what would you want |
I would expect the same interface as Cargo but make |
I've documented this limitation for now ofek/pyapp#12 Hopefully this can be fixed soon 🙂 |
I am unfamiliar with this code base, how difficult would it be to fix the install command and as you said require |
most of it has been done in #1216 , what's left in that pr is basically a rebase needed and making it consume a specific
edit: it doesn't currently support |
Oh, so it will never be possible to use the same install command interface i.e. the limitation I documented will forever persist when using the cross CLI? |
correct, kinda, instead of I'm willing to change the way it works but I don't see a strong enough reason to do it |
My use case is essentially the same as the person who opened this issue, our workflow involves cross compiling crates that have been released. Other than the repository I showed you, another use case we have is because some crates come from repositories that are not public so one cannot clone them and build in the way you are prescribing. |
Maybe I'm not explaining the difference well enough. Instead of
what do you mean here? What would prohibit |
The majority of CI users do not install cross but rather pull down an existing binary from a release to save time and money. Most of these tools extract a single binary like this https://github.com/taiki-e/install-action/blob/main/main.sh (Here is a run for proof where I output the path to both and the executable you're talking about does not exist https://github.com/ofek/hatch-showcase/actions/runs/4953629165/jobs/8861304401#step:9:29) Furthermore, it seems that most users are familiar with just the cross CLI and it would be unnatural to have every project that wants this functionality to document that you actually need a binary that you did not know existed. |
that's a regression in
I think having in my mind, using install for this is a hack for not having access to |
We would very much appreciate it if the lack of exact semantics would be allowed for this specific case of the install command to keep a consistent experience! |
Also I would be fine with testing this feature or if you need help implementing you can tell me what to do |
Is there anything I can do to help move this along? |
Checklist
Describe your issue
cross build
works like expected. But usingcross install
results in:It looks like as it
install
just isn't supported, so it falls back to running "plain cargo", which of course fails.However, running
cross --help
showsinstall
too.What target(s) are you cross-compiling for?
other (specify in description)
Which operating system is the host (e.g computer cross is on) running?
What architecture is the host?
What container engine is cross using?
cross version
0.2.5
Example
Additional information / notes
No response
The text was updated successfully, but these errors were encountered: