Hi all,
I am working on ripgrep and I was wondering if we could add a key to inputs for
cargo inputs instead of using the arguments field. Is there a downside to
saying something like
`(inputs
(("rust-loom" ,rust-loom-0.2 #rust-build)
("rust-quickcheck" ,rust-quickcheck-0.9 #rust-dev
Hi Chris,
Chris Marusich skribis:
> Ludovic Courtès writes:
>
>> What I would have liked is to somehow replace the #:cargo-inputs
>> argument (which is build-system-specific and thus “opaque”) with regular
>> ‘native-inputs’ or ‘inputs’ field.
>
> That would be nice. However, it doesn't seem p
Hi Martin,
Martin Becze skribis:
> Also see patch 38465
> (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38465) for a complete
> example. I would like too know if there is an problem with this patch
> to, before I start packaging the other rust programs this way.
It’d be great if the people in
On 2019-12-09 04:45, Chris Marusich wrote:
> input in order to actually build the program. In this model, I guess
> every "*-src" package would have no inputs and just one output. I guess
> any package that produces an artifact, for example the "ripgrep"
> package, would list a bunch of "*-src"
Hi,
Ludovic Courtès writes:
> What I would have liked is to somehow replace the #:cargo-inputs
> argument (which is build-system-specific and thus “opaque”) with regular
> ‘native-inputs’ or ‘inputs’ field.
That would be nice. However, it doesn't seem possible to express
Cargo's "dependencies"
Hi,
Efraim Flashner skribis:
> On Sun, Nov 17, 2019 at 10:22:21PM +0100, Ludovic Courtès wrote:
>> Hi,
>>
>> Efraim Flashner skribis:
>>
>> > The big problems are the recursive dependencies, the partial
>> > dependencies and the versioning. There are some that are easy to figure
>> > out, ser
On Sun, Nov 17, 2019 at 10:22:21PM +0100, Ludovic Courtès wrote:
> Hi,
>
> Efraim Flashner skribis:
>
> > The big problems are the recursive dependencies, the partial
> > dependencies and the versioning. There are some that are easy to figure
> > out, serde always needs serde-derive, winapi alwa
Hi,
Efraim Flashner skribis:
> The big problems are the recursive dependencies, the partial
> dependencies and the versioning. There are some that are easy to figure
> out, serde always needs serde-derive, winapi always needs the
> winapi-[i686|x86_64] crates, rayon -> rayon-core, etc.
Do you m
On Sat, Nov 16, 2019 at 10:33:32PM +0100, Ludovic Courtès wrote:
> Hello!
>
> Martin Becze skribis:
>
> > Sorry for digging up and old issue, but i just saw commit
> > 86e443c71d4d19e6f80cad9ca15b9c3a301c738c
> >
> >> It makes for a very large package definition, but we
> > wouldn't have to ensu
> What I would have liked is to somehow replace the #:cargo-inputs
> argument (which is build-system-specific and thus “opaque”) with regular
> ‘native-inputs’ or ‘inputs’ field.
That would be lovely! I always wondered why "#:cargo-inputs" existed.
Hello!
Martin Becze skribis:
> Sorry for digging up and old issue, but i just saw commit
> 86e443c71d4d19e6f80cad9ca15b9c3a301c738c
>
>> It makes for a very large package definition, but we
> wouldn't have to ensure thousands of other rust libraries built so we
>
> The whole point of package man
> It is quite frustrating to have to specify transitive dependencies at
> the top level. I’m not sure what else is to be done, though.
How about having something like "propagated-input" for rust source
dependencies? The top level package could use the source deps as
development-inputs so the
Hi all,
I agree with this:
> The whole point of package management is that you can use module
> building blocks. By having to specify the sub-dependencies in a top
> level definition kinda breaks the whole modular thing.
It is quite frustrating to have to specify transitive dependencies at the t
Sorry for digging up and old issue, but i just saw commit
86e443c71d4d19e6f80cad9ca15b9c3a301c738c
> It makes for a very large package definition, but we
wouldn't have to ensure thousands of other rust libraries built so we
The whole point of package management is that you can use module
building
On Fri, Oct 11, 2019 at 12:33:18AM +0200, Ludovic Courtès wrote:
> Hello!
>
> Efraim Flashner skribis:
>
> > I'd like to challenge the assumption that packages are both libraries
> > and source. A 'library' in rust compiles into one of three types: a
> > static library (libfoo.a), a shared libra
Hello!
Efraim Flashner skribis:
> I'd like to challenge the assumption that packages are both libraries
> and source. A 'library' in rust compiles into one of three types: a
> static library (libfoo.a), a shared library (libfoo.so), or a
> 'rust-library' (libfoo.rlib).
Why don’t we create .so f
I've spent a lot of time over the past few months hacking at packaging
rust crates. I've found it time-consuming, soothing and, ultimately,
likely a waste of time. When we started with the cargo-build-system the
premise was 'packages are both libraries and source, we need them in
source form to bui
17 matches
Mail list logo
