[rust-dev] RFC: Future of the Build System
leebraid at gmail.com
Tue Jan 14 15:40:02 PST 2014
On 14/01/14 23:15, Jan Niklas Hasse wrote:
> On Tue, Jan 14, 2014, at 03:07 PM, Lee Braiden wrote:
>>> package management is one job and build is another one. you will use
>>> another package management on another system, while you expect to use
>>> the same build system on another system.
>> That's true IF your package manager only supports third-party binaries.
>> However, if your package manager includes some build process, as most
>> emphatically DO, then I believe that's incorrect.
> Doesn't matter what the build system is, it's just another command to
> execute specified for the debian package.
Well, the problem for package managers is threefold:
1) Builds involve dependencies: which source *packages* need to be
installed for that package to build, and of course, what dependencies
are requiring the CURRENT package to be installed in the first place.
It's not enough to just be able to BUILD a package; a package manager
has to know how, and why it's building something, where it will go when
installed, and what that will MEAN in terms of dependency resolution,
when the package is finally built and installed. Otherwise, it's not a
package MANAGER: it's just front end for downloaders/installers.
2) Some packages, if Rust becomes mainstream at all, will be available
from multiple sources, in multiple versions. For example, rust-std
might be included with a distro, as a standard package. So might
rust-sdl2. But maybe someone with that package installed decides to
install rust-newgame, which requires
rust-sdl2--bobs-greenthreads-patch. Then you have a conflict. If your
build script blindly installs rust-sdl2--bobs-greenthreads-patch over
rust-sdl2, it could break all rust packages that use SDL.
3) Packages take a lot of time to create and maintain. If we want
useful rust packages to reach as many people as possible, they should be
readily available in as many package managers as possible, in a
standard, non-conflicting package.
Now, there are two ways (that I can see so far) to achieve (3):
i) Expect all operating systems' and all distros' package
maintainers to find the resources to package lots of rust libraries and
ii) Make it easy for those maintainers to IMPORT rust libraries and
programs, using information that only we know, and that we will get
multiple emails requesting anyway, if we don't provide it up front, from
>> I wouldn't say *every* distro, etc. Here's an extreme example: Let's say
>> there's a distro which forces every source package to have its filenames
>> start with capital letters. Should we rename our files? I would say
>> definitely no. The distro has to adapt in that case.
That's a good point, and a good example of why we should think through
maximum compatibility carefully. I hadn't thought of that one, but now
that someone's thought of it, it should be easily solved by disallowing
case-dependency in package names. That way, different tools could
auto-capitalize, auto-title-case or whatever they prefer, as long as
they remember to lower-case when building the URL.
But yes, I take your wider point that there'll invariably be something
you don't think of first time around. It's that kind of thing I'm
talking about a version number for -- ensuring an upgrade path, just in
> The same goes for the build system: Debian can't handle executing
> "rustpkg build" instead of "make"? It's their problem! (This is of
> course false: Debian CAN handle exactly that)
Right; building itself (for most things) isn't that hard, even if you're
running rustc instead of rustpkg, I suppose. It's dependencies and
package conflicts that are the real issue, not just building.
Otherwise, package management, DLL hell, RPM hell, etc., would have been
mostly solved as soon as most builds used make.
More information about the Rust-dev