[rust-dev] RFC: Future of the Build System

Lee Braiden 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 
the start.

>> 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 mailing list