FYI: adding libclang as a build-time dependency

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

FYI: adding libclang as a build-time dependency

Chris Peterson-12
The Stylo team would like to make libclang a build-time dependency so we
can generate C++/Rust bindings as part of the local build. We need
libclang 3.8+ on Mac and Linux and libclang 3.9+ on Windows.

This is Build Config bug 1310852.
_______________________________________________
dev-builds mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-builds
Reply | Threaded
Open this post in threaded view
|

Re: FYI: adding libclang as a build-time dependency

Nathan Froyd-5
On Thu, Oct 27, 2016 at 7:31 PM, Chris Peterson <[hidden email]> wrote:
> The Stylo team would like to make libclang a build-time dependency so we can
> generate C++/Rust bindings as part of the local build.

What is the benefit of doing this, especially for people not working on Stylo?

-Nathan
_______________________________________________
dev-builds mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-builds
Reply | Threaded
Open this post in threaded view
|

Re: FYI: adding libclang as a build-time dependency

Bobby Holley-2
In reply to this post by Chris Peterson-12
On Thursday, October 27, 2016 at 4:41:30 PM UTC-7, Nathan Froyd wrote:
> On Thu, Oct 27, 2016 at 7:31 PM, Chris Peterson <[hidden email]> wrote:
> > The Stylo team would like to make libclang a build-time dependency so we can
> > generate C++/Rust bindings as part of the local build.
>
> What is the benefit of doing this, especially for people not working on Stylo?

For stylo, we generate Rust representations for all sorts of C++ data structures. If those memory layouts are wrong, it's a memory hazard.

If we don't generate the bindings at build time, we would need to check them into the tree, which means that developers would need to manually run the binding generator any time they changed a bound data structure (including all sorts of stuff in xpcom, MFBT, dom, and layout). Forgetting to do this would be sec-critical, and people will most certainly forget. And even if they didn't, it would be a huge PITA.

bholley
_______________________________________________
dev-builds mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-builds
Reply | Threaded
Open this post in threaded view
|

Re: FYI: adding libclang as a build-time dependency

Mike Hommey
On Thu, Oct 27, 2016 at 07:11:10PM -0700, [hidden email] wrote:

> On Thursday, October 27, 2016 at 4:41:30 PM UTC-7, Nathan Froyd wrote:
> > On Thu, Oct 27, 2016 at 7:31 PM, Chris Peterson
> > <[hidden email]> wrote:
> > > The Stylo team would like to make libclang a build-time dependency
> > > so we can generate C++/Rust bindings as part of the local build.
> >
> > What is the benefit of doing this, especially for people not working
> > on Stylo?
>
> For stylo, we generate Rust representations for all sorts of C++ data
> structures. If those memory layouts are wrong, it's a memory hazard.
>
> If we don't generate the bindings at build time, we would need to
> check them into the tree, which means that developers would need to
> manually run the binding generator any time they changed a bound data
> structure (including all sorts of stuff in xpcom, MFBT, dom, and
> layout). Forgetting to do this would be sec-critical, and people will
> most certainly forget. And even if they didn't, it would be a huge
> PITA.

Why are we considering a dependency on libclang instead of one on
rust-bindgen?

Mike
_______________________________________________
dev-builds mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-builds
Reply | Threaded
Open this post in threaded view
|

Re: FYI: adding libclang as a build-time dependency

Bobby Holley-2
On Thu, Oct 27, 2016 at 7:21 PM, Mike Hommey <[hidden email]> wrote:
On Thu, Oct 27, 2016 at 07:11:10PM -0700, [hidden email] wrote:
> On Thursday, October 27, 2016 at 4:41:30 PM UTC-7, Nathan Froyd wrote:
> > On Thu, Oct 27, 2016 at 7:31 PM, Chris Peterson
> > <[hidden email]> wrote:
> > > The Stylo team would like to make libclang a build-time dependency
> > > so we can generate C++/Rust bindings as part of the local build.
> >
> > What is the benefit of doing this, especially for people not working
> > on Stylo?
>
> For stylo, we generate Rust representations for all sorts of C++ data
> structures. If those memory layouts are wrong, it's a memory hazard.
>
> If we don't generate the bindings at build time, we would need to
> check them into the tree, which means that developers would need to
> manually run the binding generator any time they changed a bound data
> structure (including all sorts of stuff in xpcom, MFBT, dom, and
> layout). Forgetting to do this would be sec-critical, and people will
> most certainly forget. And even if they didn't, it would be a huge
> PITA.

Why are we considering a dependency on libclang instead of one on
rust-bindgen?

Because rust-bindgen depends on libclang.
 

Mike


_______________________________________________
dev-builds mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-builds
Reply | Threaded
Open this post in threaded view
|

Re: FYI: adding libclang as a build-time dependency

Mike Hommey
On Thu, Oct 27, 2016 at 07:38:27PM -0700, Bobby Holley wrote:

> On Thu, Oct 27, 2016 at 7:21 PM, Mike Hommey <[hidden email]> wrote:
>
> > On Thu, Oct 27, 2016 at 07:11:10PM -0700, [hidden email] wrote:
> > > On Thursday, October 27, 2016 at 4:41:30 PM UTC-7, Nathan Froyd wrote:
> > > > On Thu, Oct 27, 2016 at 7:31 PM, Chris Peterson
> > > > <[hidden email]> wrote:
> > > > > The Stylo team would like to make libclang a build-time dependency
> > > > > so we can generate C++/Rust bindings as part of the local build.
> > > >
> > > > What is the benefit of doing this, especially for people not working
> > > > on Stylo?
> > >
> > > For stylo, we generate Rust representations for all sorts of C++ data
> > > structures. If those memory layouts are wrong, it's a memory hazard.
> > >
> > > If we don't generate the bindings at build time, we would need to
> > > check them into the tree, which means that developers would need to
> > > manually run the binding generator any time they changed a bound data
> > > structure (including all sorts of stuff in xpcom, MFBT, dom, and
> > > layout). Forgetting to do this would be sec-critical, and people will
> > > most certainly forget. And even if they didn't, it would be a huge
> > > PITA.
> >
> > Why are we considering a dependency on libclang instead of one on
> > rust-bindgen?
> >
>
> Because rust-bindgen depends on libclang.

So what? What developers need is rust-bindgen, not libclang. They can
get rust-bindgen through different means. That may have required
building libclang, or installing libclang development files, or
installing a prebuilt rust-bindgen, or whatever, and the build system
doesn't have to care about that.

In fact, rust-bindgen could (hypothetically) switch to a different C/C++
parser, and the build system would still depend on rust-bindgen, but not
libclang.

So again, why are we considering a dependency on libclang instead of one
on rust-bindgen?

Mike
_______________________________________________
dev-builds mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-builds
Reply | Threaded
Open this post in threaded view
|

Re: FYI: adding libclang as a build-time dependency

Bobby Holley-2
On Thu, Oct 27, 2016 at 7:45 PM, Mike Hommey <[hidden email]> wrote:
On Thu, Oct 27, 2016 at 07:38:27PM -0700, Bobby Holley wrote:
> On Thu, Oct 27, 2016 at 7:21 PM, Mike Hommey <[hidden email]> wrote:
>
> > On Thu, Oct 27, 2016 at 07:11:10PM -0700, [hidden email] wrote:
> > > On Thursday, October 27, 2016 at 4:41:30 PM UTC-7, Nathan Froyd wrote:
> > > > On Thu, Oct 27, 2016 at 7:31 PM, Chris Peterson
> > > > <[hidden email]> wrote:
> > > > > The Stylo team would like to make libclang a build-time dependency
> > > > > so we can generate C++/Rust bindings as part of the local build.
> > > >
> > > > What is the benefit of doing this, especially for people not working
> > > > on Stylo?
> > >
> > > For stylo, we generate Rust representations for all sorts of C++ data
> > > structures. If those memory layouts are wrong, it's a memory hazard.
> > >
> > > If we don't generate the bindings at build time, we would need to
> > > check them into the tree, which means that developers would need to
> > > manually run the binding generator any time they changed a bound data
> > > structure (including all sorts of stuff in xpcom, MFBT, dom, and
> > > layout). Forgetting to do this would be sec-critical, and people will
> > > most certainly forget. And even if they didn't, it would be a huge
> > > PITA.
> >
> > Why are we considering a dependency on libclang instead of one on
> > rust-bindgen?
> >
>
> Because rust-bindgen depends on libclang.

So what? What developers need is rust-bindgen, not libclang. They can
get rust-bindgen through different means. That may have required
building libclang, or installing libclang development files, or
installing a prebuilt rust-bindgen, or whatever, and the build system
doesn't have to care about that.

In fact, rust-bindgen could (hypothetically) switch to a different C/C++
parser, and the build system would still depend on rust-bindgen, but not
libclang.

So again, why are we considering a dependency on libclang instead of one
on rust-bindgen?

If that kind of abstraction makes things easier somehow, that's fine by me. I care about the observables.

I'm kind of skeptical though. rust-bindgen is a very small rust crate, and doesn't publish any prebuilt binaries to speak of. libclang is huge and has prebuilt binaries that are accessible via package managers. Naively, it would seem most practical to require libclang, vendor rust-bindgen in tree along with all our other rust dependencies, built rust-bindgen with gecko, and use it to generate the bindings.
 

Mike


_______________________________________________
dev-builds mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-builds
Reply | Threaded
Open this post in threaded view
|

Re: FYI: adding libclang as a build-time dependency

Sylvestre Ledru
In reply to this post by Chris Peterson-12

Following Clang upstream changes is not a trivial thing, what is the plan? Support the last two upstream releases?
Thanks


Le 28 oct. 2016 01:35, "Chris Peterson" <[hidden email]> a écrit :
The Stylo team would like to make libclang a build-time dependency so we can generate C++/Rust bindings as part of the local build. We need libclang 3.8+ on Mac and Linux and libclang 3.9+ on Windows.

This is Build Config bug 1310852.
_______________________________________________
dev-builds mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-builds

_______________________________________________
dev-builds mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-builds
Reply | Threaded
Open this post in threaded view
|

Re: FYI: adding libclang as a build-time dependency

Xidorn Quan
In reply to this post by Mike Hommey
On Friday, October 28, 2016 at 1:57:39 PM UTC+11, Bobby Holley wrote:

> On Thu, Oct 27, 2016 at 7:45 PM, Mike Hommey <[hidden email]> wrote:
>
>
> On Thu, Oct 27, 2016 at 07:38:27PM -0700, Bobby Holley wrote:
>
> > On Thu, Oct 27, 2016 at 7:21 PM, Mike Hommey <[hidden email]> wrote:
>
> >
>
> > > On Thu, Oct 27, 2016 at 07:11:10PM -0700, [hidden email] wrote:
>
> > > > On Thursday, October 27, 2016 at 4:41:30 PM UTC-7, Nathan Froyd wrote:
>
> > > > > On Thu, Oct 27, 2016 at 7:31 PM, Chris Peterson
>
> > > > > <[hidden email]> wrote:
>
> > > > > > The Stylo team would like to make libclang a build-time dependency
>
> > > > > > so we can generate C++/Rust bindings as part of the local build.
>
> > > > >
>
> > > > > What is the benefit of doing this, especially for people not working
>
> > > > > on Stylo?
>
> > > >
>
> > > > For stylo, we generate Rust representations for all sorts of C++ data
>
> > > > structures. If those memory layouts are wrong, it's a memory hazard.
>
> > > >
>
> > > > If we don't generate the bindings at build time, we would need to
>
> > > > check them into the tree, which means that developers would need to
>
> > > > manually run the binding generator any time they changed a bound data
>
> > > > structure (including all sorts of stuff in xpcom, MFBT, dom, and
>
> > > > layout). Forgetting to do this would be sec-critical, and people will
>
> > > > most certainly forget. And even if they didn't, it would be a huge
>
> > > > PITA.
>
> > >
>
> > > Why are we considering a dependency on libclang instead of one on
>
> > > rust-bindgen?
>
> > >
>
> >
>
> > Because rust-bindgen depends on libclang.
>
>
>
> So what? What developers need is rust-bindgen, not libclang. They can
>
> get rust-bindgen through different means. That may have required
>
> building libclang, or installing libclang development files, or
>
> installing a prebuilt rust-bindgen, or whatever, and the build system
>
> doesn't have to care about that.
>
>
>
> In fact, rust-bindgen could (hypothetically) switch to a different C/C++
>
> parser, and the build system would still depend on rust-bindgen, but not
>
> libclang.
>
>
>
> So again, why are we considering a dependency on libclang instead of one
>
> on rust-bindgen?
>
>
> If that kind of abstraction makes things easier somehow, that's fine by me. I care about the observables.
>
>
> I'm kind of skeptical though. rust-bindgen is a very small rust crate, and doesn't publish any prebuilt binaries to speak of. libclang is huge and has prebuilt binaries that are accessible via package managers. Naively, it would seem most practical to require libclang, vendor rust-bindgen in tree along with all our other rust dependencies, built rust-bindgen with gecko, and use it to generate the bindings.

Another thing is that, rust-bindgen hasn't been stable enough for being delivered via prebuilt version.

We constantly find issues on it and patch it when necessary. This would likely continue to happen in a reasonable time. Sometimes latest code may require bindings generated from the latest revision of rust-bindgen to work.

Given this, I believe it would be better to pin its revision in-tree as part of the build, rather than deliver a prebuilt version separately. Otherwise, people may need to upgrade it frequently to have it work with latest source code.

In addition, I think it makes the most of sense to make rust-bindgen a build dependency of servo/geckolib (or probably servo/style) directly, so that we do not need an additional python script to call a separate binary, and play with the path. We can do that altogether inside build.rs.

- Xidorn
_______________________________________________
dev-builds mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-builds
Reply | Threaded
Open this post in threaded view
|

Re: FYI: adding libclang as a build-time dependency

Bobby Holley-2
In reply to this post by Sylvestre Ledru
On Thu, Oct 27, 2016 at 11:15 PM, Sylvestre Ledru <[hidden email]> wrote:

Following Clang upstream changes is not a trivial thing, what is the plan? Support the last two upstream releases?

So far we need 3.8+ on mac/linux and 3.9+ on windows. I'm not aware of any reason (so far) why we would add more restrictions than that.
 

Thanks


Le 28 oct. 2016 01:35, "Chris Peterson" <[hidden email]> a écrit :
The Stylo team would like to make libclang a build-time dependency so we can generate C++/Rust bindings as part of the local build. We need libclang 3.8+ on Mac and Linux and libclang 3.9+ on Windows.

This is Build Config bug 1310852.
_______________________________________________
dev-builds mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-builds

_______________________________________________
dev-builds mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-builds



_______________________________________________
dev-builds mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-builds
Reply | Threaded
Open this post in threaded view
|

Re: FYI: adding libclang as a build-time dependency

Gregory Szorc-3
In reply to this post by Xidorn Quan
On Fri, Oct 28, 2016 at 3:04 AM, Xidorn Quan <[hidden email]> wrote:
On Friday, October 28, 2016 at 1:57:39 PM UTC+11, Bobby Holley wrote:
> On Thu, Oct 27, 2016 at 7:45 PM, Mike Hommey <[hidden email]> wrote:
>
>
> On Thu, Oct 27, 2016 at 07:38:27PM -0700, Bobby Holley wrote:
>
> > On Thu, Oct 27, 2016 at 7:21 PM, Mike Hommey <[hidden email]> wrote:
>
> >
>
> > > On Thu, Oct 27, 2016 at 07:11:10PM -0700, [hidden email] wrote:
>
> > > > On Thursday, October 27, 2016 at 4:41:30 PM UTC-7, Nathan Froyd wrote:
>
> > > > > On Thu, Oct 27, 2016 at 7:31 PM, Chris Peterson
>
> > > > > <[hidden email]> wrote:
>
> > > > > > The Stylo team would like to make libclang a build-time dependency
>
> > > > > > so we can generate C++/Rust bindings as part of the local build.
>
> > > > >
>
> > > > > What is the benefit of doing this, especially for people not working
>
> > > > > on Stylo?
>
> > > >
>
> > > > For stylo, we generate Rust representations for all sorts of C++ data
>
> > > > structures. If those memory layouts are wrong, it's a memory hazard.
>
> > > >
>
> > > > If we don't generate the bindings at build time, we would need to
>
> > > > check them into the tree, which means that developers would need to
>
> > > > manually run the binding generator any time they changed a bound data
>
> > > > structure (including all sorts of stuff in xpcom, MFBT, dom, and
>
> > > > layout). Forgetting to do this would be sec-critical, and people will
>
> > > > most certainly forget. And even if they didn't, it would be a huge
>
> > > > PITA.
>
> > >
>
> > > Why are we considering a dependency on libclang instead of one on
>
> > > rust-bindgen?
>
> > >
>
> >
>
> > Because rust-bindgen depends on libclang.
>
>
>
> So what? What developers need is rust-bindgen, not libclang. They can
>
> get rust-bindgen through different means. That may have required
>
> building libclang, or installing libclang development files, or
>
> installing a prebuilt rust-bindgen, or whatever, and the build system
>
> doesn't have to care about that.
>
>
>
> In fact, rust-bindgen could (hypothetically) switch to a different C/C++
>
> parser, and the build system would still depend on rust-bindgen, but not
>
> libclang.
>
>
>
> So again, why are we considering a dependency on libclang instead of one
>
> on rust-bindgen?
>
>
> If that kind of abstraction makes things easier somehow, that's fine by me. I care about the observables.
>
>
> I'm kind of skeptical though. rust-bindgen is a very small rust crate, and doesn't publish any prebuilt binaries to speak of. libclang is huge and has prebuilt binaries that are accessible via package managers. Naively, it would seem most practical to require libclang, vendor rust-bindgen in tree along with all our other rust dependencies, built rust-bindgen with gecko, and use it to generate the bindings.

Another thing is that, rust-bindgen hasn't been stable enough for being delivered via prebuilt version.

We constantly find issues on it and patch it when necessary. This would likely continue to happen in a reasonable time. Sometimes latest code may require bindings generated from the latest revision of rust-bindgen to work.

Given this, I believe it would be better to pin its revision in-tree as part of the build, rather than deliver a prebuilt version separately. Otherwise, people may need to upgrade it frequently to have it work with latest source code.

If we have to build rust-bindgen because the versions in distros aren't sufficient, then that should be a valid reason to require libclang.

Slightly off topic: since rust-bindgen isn't stable enough, does this mean we'll be vendoring it in mozilla-central? (I think it will.)

Another benefit of requiring libclang is we can start leaning more heavily on the Clang tooling ecosystem. I'd love to have more widespread use of things such as automatic rewriting of source code to conform with our style conventions. I'm not sure if this requires libclang per se. But having Clang/libclang everywhere gets us one step closer.
 

In addition, I think it makes the most of sense to make rust-bindgen a build dependency of servo/geckolib (or probably servo/style) directly, so that we do not need an additional python script to call a separate binary, and play with the path. We can do that altogether inside build.rs.

- Xidorn
_______________________________________________
dev-builds mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-builds


_______________________________________________
dev-builds mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-builds
Reply | Threaded
Open this post in threaded view
|

Re: FYI: adding libclang as a build-time dependency

Bobby Holley-2
On Tue, Nov 1, 2016 at 11:18 AM, Gregory Szorc <[hidden email]> wrote:
On Fri, Oct 28, 2016 at 3:04 AM, Xidorn Quan <[hidden email]> wrote:
On Friday, October 28, 2016 at 1:57:39 PM UTC+11, Bobby Holley wrote:
> On Thu, Oct 27, 2016 at 7:45 PM, Mike Hommey <[hidden email]> wrote:
>
>
> On Thu, Oct 27, 2016 at 07:38:27PM -0700, Bobby Holley wrote:
>
> > On Thu, Oct 27, 2016 at 7:21 PM, Mike Hommey <[hidden email]> wrote:
>
> >
>
> > > On Thu, Oct 27, 2016 at 07:11:10PM -0700, [hidden email] wrote:
>
> > > > On Thursday, October 27, 2016 at 4:41:30 PM UTC-7, Nathan Froyd wrote:
>
> > > > > On Thu, Oct 27, 2016 at 7:31 PM, Chris Peterson
>
> > > > > <[hidden email]> wrote:
>
> > > > > > The Stylo team would like to make libclang a build-time dependency
>
> > > > > > so we can generate C++/Rust bindings as part of the local build.
>
> > > > >
>
> > > > > What is the benefit of doing this, especially for people not working
>
> > > > > on Stylo?
>
> > > >
>
> > > > For stylo, we generate Rust representations for all sorts of C++ data
>
> > > > structures. If those memory layouts are wrong, it's a memory hazard.
>
> > > >
>
> > > > If we don't generate the bindings at build time, we would need to
>
> > > > check them into the tree, which means that developers would need to
>
> > > > manually run the binding generator any time they changed a bound data
>
> > > > structure (including all sorts of stuff in xpcom, MFBT, dom, and
>
> > > > layout). Forgetting to do this would be sec-critical, and people will
>
> > > > most certainly forget. And even if they didn't, it would be a huge
>
> > > > PITA.
>
> > >
>
> > > Why are we considering a dependency on libclang instead of one on
>
> > > rust-bindgen?
>
> > >
>
> >
>
> > Because rust-bindgen depends on libclang.
>
>
>
> So what? What developers need is rust-bindgen, not libclang. They can
>
> get rust-bindgen through different means. That may have required
>
> building libclang, or installing libclang development files, or
>
> installing a prebuilt rust-bindgen, or whatever, and the build system
>
> doesn't have to care about that.
>
>
>
> In fact, rust-bindgen could (hypothetically) switch to a different C/C++
>
> parser, and the build system would still depend on rust-bindgen, but not
>
> libclang.
>
>
>
> So again, why are we considering a dependency on libclang instead of one
>
> on rust-bindgen?
>
>
> If that kind of abstraction makes things easier somehow, that's fine by me. I care about the observables.
>
>
> I'm kind of skeptical though. rust-bindgen is a very small rust crate, and doesn't publish any prebuilt binaries to speak of. libclang is huge and has prebuilt binaries that are accessible via package managers. Naively, it would seem most practical to require libclang, vendor rust-bindgen in tree along with all our other rust dependencies, built rust-bindgen with gecko, and use it to generate the bindings.

Another thing is that, rust-bindgen hasn't been stable enough for being delivered via prebuilt version.

We constantly find issues on it and patch it when necessary. This would likely continue to happen in a reasonable time. Sometimes latest code may require bindings generated from the latest revision of rust-bindgen to work.

Given this, I believe it would be better to pin its revision in-tree as part of the build, rather than deliver a prebuilt version separately. Otherwise, people may need to upgrade it frequently to have it work with latest source code.

If we have to build rust-bindgen because the versions in distros aren't sufficient, then that should be a valid reason to require libclang.

Slightly off topic: since rust-bindgen isn't stable enough, does this mean we'll be vendoring it in mozilla-central? (I think it will.)

I think so as well. We are constantly adding features to it to support new things we want to do with stylo.

Another benefit of requiring libclang is we can start leaning more heavily on the Clang tooling ecosystem. I'd love to have more widespread use of things such as automatic rewriting of source code to conform with our style conventions. I'm not sure if this requires libclang per se. But having Clang/libclang everywhere gets us one step closer.
 

In addition, I think it makes the most of sense to make rust-bindgen a build dependency of servo/geckolib (or probably servo/style) directly, so that we do not need an additional python script to call a separate binary, and play with the path. We can do that altogether inside build.rs.

- Xidorn
_______________________________________________
dev-builds mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-builds


_______________________________________________
dev-builds mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-builds



_______________________________________________
dev-builds mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-builds