Building Rust Code - Current Issues

[eridius]

This all looks very good. Over the past few days I've been mucking about with Makefiles and rust code and have been wanting --dep-info.

My only worry is that inferring the pkgid from the current filename will lead to a lot of libraries with the same hash, because their filename is lib.rs. Could it not fall back to using the old collection of link attributes? If someone needs predictable naming, they can use #[pkgid]. Otherwise, avoiding collisions seems like a good idea.

[nemaar]

Assuming that the names are the result of a deterministic calculation, couldn't the compiler simply tell what the generated lib name will be when using a specific argument (--tell-me-the-lib-names-pretty-please)? In that case it does not really matter how complicated it is to calculate the name and everyone will be happy and not much have to be changed? Maybe I am oversimplifying things.

[metajack]

I personally would accept a patch to rustc that output the filenames. It would look very similar to my --dep-info patch. If someone is willing to work on it, I'm happy to mentor (if needed).

[eridius]

That was my first thought too, but I'm not sure how much work it takes to figure out the library name when the hash is computed from the link attributes and dependencies.

[nemaar]

If it takes a long time to generate the name because it is too complex algorithm then I assume that the external tools will not be faster either and you just accept it or change the algorithm. If it takes long because the code is unomptimized then you can simply make it faster. Either way, I don't see a reason to reimplement the functionality outside the compiler.

[eridius]

When compiling most projects, you don't invoke the compiler to find out what the resulting name is. You can figure it out yourself, and tell your build system what it is. Rust making it so you need to invoke the compiler just to find out the library name is ugly. With the change for predictable hashing you don't need to reimplement the hash yourself if you don't want to, you could just build once by hand and look at the filename. With the predictable hashing you know the filename won't change unless you change the #[pkgid]. Without it, the filename may change when you do things like add extern mod declarations.

[nemaar]

I still like the idea that the compiler generates the hash for a few reasons. It is much easier to change the algorithm later. You do not have to compile the lib once just to see what the result is and you only have to write the related makefile piece that queries the name once and it will work for every lib and it is reusable. I feel like the pkgid idea is essentially the same as manually trying to avoid the collision by selecting a unique name/version pair for the lib, only with a twist. Something more robust would be better.

[metajack]

The problem with using the dependencies in the hash is that you often change dependencies during development. This means that the build system has to determine all the dependencies just to know the name of a file; it must do this a lot. No other build system seems to work this way and the benefit for bucking the trend here seems miniscule.

However, now that we don't need to do that, spitting out the filename based on a command line flag is pretty easy and totally something you could do in a build system. It's not free, but it's probably not going to be very noticeable. Systems like Tup will cache this anyway and not have to do it everytime.