Hi Hartmut,
Hartmut Goebel writes:
> Hi.,
>
> these day I had spent some more hours struggling with rust ans cargo,
> trying to get "pre-built" crates.
>
> Summery; Cargo is cruft, no solution found yet.
>
> I tried reusing a crate from the very same place it was built (see
> enclosed script).
On Mon, Jun 07, 2021 at 08:48:11PM +0200, Leo Prikler wrote:
> (Note, though, that a Go update would need to go through staging – not
> an ideal situation either.)
I have "cheated" regarding this in the past. Although changing the Go
package should qualify for staging, it's so cheap to build Go
Am 08.06.21 um 11:15 schrieb Efraim Flashner (referring to Debian)
My understanding is that they pool together all the sources that they
have and then build all the rust packages in one go.
Maybe, I have no clue. Anyhow given my experience with sequoia, I doubt
this will reduce build-times:
On Mon, Jun 07, 2021 at 06:41:41PM +0200, Hartmut Goebel wrote:
> Am 07.06.21 um 18:26 schrieb Hartmut Goebel:
> > > Another path we should checkout is to see what Debian does. My
> > > understanding is that they figured something out. Worth a shot, but
> > > I’d rather the problem be fixed
> Our issue is a different one: Its about being able to reuse already
> compiled binaries - keeping current behavior of rust binaries being
> statically linked.
>
> While this looks like being the same as dynamic library support, it
> is not: While for dynamic libraries you meet to ensure the
Am 07.06.21 um 18:26 schrieb Hartmut Goebel:
Another path we should checkout is to see what Debian does. My
understanding is that they figured something out. Worth a shot, but
I’d rather the problem be fixed upstream. It will just take
collaboration.
I did not check their tollchain lately,
Hi John.
Am 07.06.21 um 17:13 schrieb John Soo:
Rust has a very well documented rfc process and we can at least bring
it up that way. I brought up the possibility of collaboration between
rust and functional package managers on the rust Zulip, even. They
seemed to like the idea.
I'd be
Oh my goodness, I’m so sorry for the top quote.
Hi Hartmut and Pjotr,
My feeling on this is that we should partner with the Rust community to make
shared library support from cargo a priority. Specifying an output directory is
currently a nightly feature, that could be helpful.
In general Rust tooling does not compose with existing tools. I
Am 07.06.21 um 10:28 schrieb Pjotr Prins:
Exactly my idea. One challenge will be that the source of dependencies
need to be available - think of it as include files. One thing we
could do as ship them as part of the Guix package. Or have a separate
one for sources. We do that for include files
On Mon, Jun 07, 2021 at 09:10:48AM +0200, Hartmut Goebel wrote:
> Am 06.06.21 um 20:38 schrieb Pjotr Prins:
> > Since that community is about not invented here - maybe we can incense
> > someone to pick it up. Needs a mature programmer though.
>
> One solution that came to my mind is to not use
Am 06.06.21 um 20:38 schrieb Pjotr Prins:
Since that community is about not invented here - maybe we can incense
someone to pick it up. Needs a mature programmer though.
One solution that came to my mind is to not use Cargo, but instead parse
Cargo.toml and issue the appropriate "rustc"
Hi.,
these day I had spent some more hours struggling with rust ans cargo,
trying to get "pre-built" crates.
Summery; Cargo is cruft, no solution found yet.
I tried reusing a crate from the very same place it was built (see
enclosed script). Anyhow, this does not work since cargo uses a
13 matches
Mail list logo
