They used to be a different crate. I merged them so that we can do replacements with safer wrappers and have fewer coherence issues.
Perhaps we can make triggering local build time bindgen regen more explicit? On Dec 14, 2016 2:57 PM, "Xidorn Quan" <m...@upsuper.org> wrote: > I'm thinking about splitting those parts into a separate crate because > currently servo/style component's build script is doing two different > things: 1. generate property code, 2. do bindgen. And mixing these > things may lead to many unnecessary rebuild. > > In the current build-time bindgen code, all headers directly or > indirectly included by header processed are listed as > "cargo:rerun-if-changed", but majority of them may not actually affect > the output of bindgen, and in that case, we don't really need to rebuild > the style crate and anything depends on it. > > For solving that problem, I filed an issue [1] to cargo suggesting that > we should have a mechanism for build script to inform cargo not to > rebuild the crate simply because of build script. With that mechanism, > we can compare the output of bindgen and see whether it is same as the > existing code, and tell cargo not to rebuild if the code doesn't change. > > However, even if we have that mechanism, we cannot really tell whether > rebuild is necessary for build script of style component, because we > also generate property code there, and it seems to me detecting whether > that code changes costs more work and doesn't make much sense, because > unlike bindings generated from C++ code, changes to the template or > property data likely actually need a rebuild. > > Given these, I guess the best solution would be to split the gecko > binding things out into a separate crate with its own build script. > > Thoughts? > > [1] https://github.com/rust-lang/cargo/issues/3404 > > - Xidorn > _______________________________________________ > dev-servo mailing list > dev-servo@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-servo > _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
