6 ms·
> no autoconf Mentioning this in the same breath as "no segfaults" seems odd, does Rust use some other build configuration tool, or does it just not have the n
by avar 11y ago
> no autoconf
Mentioning this in the same breath as "no segfaults" seems odd, does Rust use some other build configuration tool, or does it just not have the need for compile-time configuration detection? If it's the latter how does that even work?
Are there no optional libraries? No outdated libraries whose version you have to detect? No obscure platforms whose architecture you have to detect for unsafe inline code etc.?
Because if you can have any of those or any number of other cases where you need compile-time detection of configuration options you're going to need something like autoconf.
- eatsfoobars 11y agoBuild scripts[1] written in Rust are used for this. [1]: http://doc.crates.io/build-script.html http://doc.crates.io/build-script.html
- Tuna-Fish 11y ago> does Rust use some other build configuration tool Yes. Rust ships with cargo, which is probably the best build configuration tool ever written, and I've tried a lot of them, for a lot of different languages. It has clean, non-hacky solutions to all of the cases you listed, and a lot more besides those.
- dozzie 11y agoOh, far from that. Last time I checked Cargo didn't understand the difference between downloading things (dependencies) and compilation. Even its building process didn't have that separated, and happily downloaded a random pre-built ELF binary to build itself.
- steveklabnik 11y agoI'm not sure what you mean by not understanding it. It is true that if you don't have dependencies, "cargo build" will go get them, but if you don't, then it shouldn't. There have been some bugs that caused it to over-download, but those were bugs. > happily downloaded a random pre-built ELF binary to build itself. Yes, Cargo builds itself with Cargo, so you need to get a previous Cargo. The binary is very much not 'random'.
- dozzie 11y ago> It is true that if you don't have dependencies, "cargo build" will go get them, but if you don't, then it shouldn't. The main problem is you can't download dependencies separately from compiling your code. It should never be the same step. Even pip had it mostly correct, by providing an option to disable network communication. It is somewhat mitigated by documentation mentioning where the downloaded dependencies are put, so you can do all that manually. This sucks balls heavily. > Yes, Cargo builds itself with Cargo, so you need to get a previous Cargo. The binary is very much not 'random'. It's fetched outside of regular downloading you do on tarball. You have no control over where is it downloaded from. It means it's pretty much random for your purposes. Heck, it would be even unexpected, if I wasn't used to developers not understanding the difference between building and downloading software. But this is not the main point. Cargo should not need already compiled Cargo to build itself. This is ridiculous. I understand that every good compiler is built with the very same compiler you're building, but look at how they do that: by bootstrapping. Not so much with Cargo. Who ever thought it as a valid idea?
- steveklabnik 11y ago> It should never be the same step. This is just going to be a preference then. I much prefer not having to type two things to do what's conceptually one: please build my code. "cargo fetch" means you don't have to do the download step manually. IE, you _can_ do it in two commands if you'd like. > It means it's pretty much random for your purposes. We are just going to have to agree to disagree on this one. First of all, you _already_ need an equally 'random' binary: rustc itself. Which is also bootstrapped. Second, it's not clear to me why bootstrapping is valid for a compiler, but not for any other kind of project. Cargo is a build system, written in Rust, so it uses Rust's build system.
- dozzie 11y ago> This is just going to be a preference then. No, it is not. * It's not always that you have internet connection when building your code. * It's not always that you have access to the website code is downloaded from (websites break, and companies have different policies about internet), and even if you do, you don't always have it direct (e.g. proxy). * And at the last, people will build code for various purposes, including building packages. Building a package should be a repeatable operation and should always use only clean source (no artifacts from previous builds), and downloading random things on every build from clean source is very easy way to break the process. >> It means it's pretty much random for your purposes. > We are just going to have to agree to disagree on this one. First of all, you _already_ need an equally 'random' binary: rustc itself. No. I downloaded Rust compiler myself (or had it installed from a package). I controlled that, it didn't hit me in my face unexpectedly. > Which is also bootstrapped. s/also//. Cargo is not bootstrapped, because it needs pre-built Cargo to build itself. Compare this to Rust compiler: you start with nothing but C(++? I don't remember) compiler, and end with Rust compiler. No intermediate download involved. > Second, it's not clear to me why bootstrapping is valid for a compiler, but not for any other kind of project. Cargo is a build system, written in Rust, so it uses Rust's build system. It's not invalid, quite the contrary. It's just Cargo doesn't boostrap itself out of clean code. It's that simple. I wouldn't have as big problem with it if its build process produced an intermediate, crippled Cargo binary. I would then complain about requiring external dependencies to be downloaded (in contrast to included), but that would be difference on strategy preferences.
- burntsushi 11y agoIn addition to what eatsfoobars said, you can also use attributes for conditional compilation depending on a number of things (pointer size, platform, etc.) e.g., https://github.com/BurntSushi/walkdir/blob/master/src/same_file.rs#L19-L37 https://github.com/BurntSushi/walkdir/blob/master/src/same_f...
- jandrese 11y agoNo autoconf seems like a given. The whole reason for autoconf is to deal with the myriad different versions of C compilers/environments, a problem a brand new language with only a single compiler will not have. We will see what happens when a vendor write their own Rust compiler that has its own idiosyncrasies.
- shadowmint 11y agoRust build scripts for crates that rely on external (ie. C ABI) libraries are completely naive, and rely almost exclusively on either the automake tools, cmake or (most often) simply that the right version of the library dependency is already magically present on the system due to apt-get or some other user configuration. Compiling pure rust relies on the single compiler toolchain which is assumed to be present by cargo, and universal on all platforms. That's pretty solid. ...but rust = no autoconf is somewhat misleading; rust that uses c libraries has to solve all the same problems that anything else using c libraries has to; but unlike python or node, there is no help (ie. gyp or distutils) for you if you need to do this. Perhaps eventually something clever will come along to fill the gap, but it's something of a pain point at the moment, especially on windows.
- mcguire 11y agoThe system Rust uses is closer to imake than autoconf: the compiler knows what system its building for and sets attributes to let the code know what it should use. (The imake style is a little less flexible than autoconf, but no less insane. Six of one, half a dozen of the other.) For example: cfg_if! { if #[cfg(windows)] { mod windows; pub use windows::*; } else { mod unix; pub use unix::*; } } The 13 struct stat's in libc: https://github.com/rust-lang-nursery/libc/search?utf8=%E2%9C%93&q=struct+stat https://github.com/rust-lang-nursery/libc/search?utf8=%E2%9C... Cargo supports versioning libraries (and seemingly does so sanely!). Obscure platform support is obscure.