https://pantsbuild.org/ logo
Join Slack
Powered by
we do actually provide an `ar` via binutils, which...
# development
a
we do actually provide an 
ar
via binutils, which we have in the pantsbuild s3 as a binary tool
so we could actually make this PR much better by using that version of 
ar
. i'll make a TODO
h
wouldn't that make the ability to build pants dependent on the state of the pantsbuild s3 bucket?
a
already true because we download protoc and go
see 
cargo.sh
in the PR
great great catch though
h
I've been meaning to look into 
cargo.sh
a
it's...a lot
h
I want to start adding rust support to pants in the near future
a
i have an implementation in v2 if you want to see a crappy attempt
h
actually yeah link me to what you have
a
h
I don't expect to start on it for a few more days
a
it relies on some changes to upstream pants which are basically just adding the rust TargetAdaptor subclass
h
but it would obviously be nice if pants could build its rust components itself
a
there's thrift support in there too
yes absolutely
h
so I wanted to see what the custom cargo.sh was actually doing, seeing if we could move that complexity somewhere else
a
basically, we have things that we could put into 
<http://build.rs|build.rs>
scripts, but haven't yet for whatever reason
h
there's no point in doing that moving before pants can build rust
a
i think we would want to look into extracting our shell scripts e.g. 
cargo.sh
and 
bootstrap_rust.sh
and 
bootstrap_cffi.sh
or whatever into common rust crates that provide 
build-dependencies
i actually disagree with that ordering
h
well, I guess there's a point in having more standardized behavior
a
oh
i 50% agree with this:
there's no point in doing that moving before pants can build rust
it can be done in parallel
but otherwise yes
h
I mean, even if we still have to invoke a specific version of 
cargo
explicitly to build pants (because pants can't do it itself), there's still value in not having shell scripts around
a
yes
h
<http://build.rs|build.rs>
is the canonical place for rust setup stuff to live
a
the implementation i have does exactly that
yes
h
cool thanks for linking I'll definitely take a look at that over the next several days
a
and it means others can use those tools too if we publish crates that can be used in 
<http://build.rs|build.rs>
scripts
feel free to totally design this however you want, but definitely also feel free to use me as a resource if i can unblock you when you start work on this
and/or if you want to ideate
h
your work is a few months old, so it's older than @hundreds-father-404ā€™s new target API
a
that's correct
h
so it probably makes sense to start from scratch, but it's useful to have that source file around as a resource
a
i mentioned in another thread that it would be easier to review now because of the progress on the target api, once it has been updated to use the target api
oh absolutely start from scratch
sorry yes absolutely
h
I see you went with the 
./pants cargo
idea, I was thinking about whether or not that made sense myself
a
you can have cargo projects depend on each other in pants and outside of pants with zero changes it's incredibly tight
h
oh heh that actually predates renaming 
@console_rule
to 
@goal_rule
ā— 1
a
yes
the current ruleset composes cargo projects in the process execution venv in the same directories as they are in the buildroot
so you can have individually cacheable builds that work the same way in and out of pants v2
which, btw, i think is something that we want. it means people can sprinkle pants on top of their rust project if they want to add python, for example
šŸ‘ 1
i think that's the biggest thing to gain from those rust rules, along with weird cargo execution command lines
no need to study them
h
solid. I'm gonna go to bed now, but happy to talk more about rust stuff in the next few days
a
absolutely! thanks so much
Open in Slack
PreviousNext
Powered by