-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Building and compiling C code with rustc/cargo #1850
Comments
I have also wanted something like this on occasion. It would certainly make bindings that require 'just a little bit' of C easier. My inclination is to add an attribute like |
Does There are other considerations now that I'm awake and more coherent:
etc. I have needed this in my LevelDB bindings - the source can be trivially compiled and thrown into just about any build system, but it does need some configuration logic depending on the platform it's compiled for. LevelDB actually uniquely defines this issue somewhat, as it touches almost all of the points I'm thinking of. I wrapped it into a Cabal build rather easily, and it is 'complete' in that the Cabal build system is on par with the included one the authors wrote(it's really simple itself.) Basically:
Overall these kinds of requirements will invariably appear as people begin integrating more libraries and bindings into Rust code - I'm definitely at a dead end on binding a few libs because of it. Personally I almost always attempt to distribute these kinds of packages as standalone as possible in this manner, by working them into the toolchain instead of external installs, providing shims/glue, because as the library author, I wish to pay this effort up front, as opposed to paying every time you use the library - complicated build instructions fall into this space. It makes the user experience just much, much better. I realize this is already going long beyond the initial scope of the ticket it may feel, but these are very important issues people are going to run into soon I speculate, so discussion will happen one way or another. :) Overall I think a good initial braindump on the whole scheme consists of:
Relating to the last point I feel Cargo should just be a package manager - it installs things. It should be good at that. But it should support people to have build systems that go beyond crate-level logic, because while Rust has a nice compilation model with logic for this built into the crates/sources itself, the rest of the world doesn't. Almost every package that's based on a system wide library like zmq or mongrel2 (for simple examples) can probably just get away with a Sorry for the length, but this is a semi complicated issue with many facets. I am interested in looking into and implementing it, as it will be crucial to many packages I think, but it crosses between rustc and cargo, brings into question their responsibilities, and potentially requires lots of careful decision making, so I would appreciate what other Rust users (and developers!) think. |
rustc does not support plugins yet, but many of the things it does (#fmt, config, testing) should, in my opinion, be done by plugins (in this case default plugins that are always guaranteed to be there) There's a ticket open about creating some mechanism to set crate attributes via the build system: #612 . There already exists a limited way to set the configuration on the command line. I believe native modules do not strictly need to refer to shared libraries. There is some way to use the I like a lot of the ideas you have here, and it sounds like you have a good grasp on some of the practical problems that actual users are going to run into, so am totally supportive of any improvements you want to make in this area. Let's break these down into smaller, discreet issues that can be tackled independently. You will also want to get feedback from @graydon because he has some opinions on these subjects. |
OK. I will split this into multiple bugs referencing this issue, hopefully summarizing the ideas separately, and basic modes of attack. |
Also, the stuff in #612 looks exactly like what would be needed to give rustc configuration logic of the kind I imagine, (specifying |
There's a lot here but I like the direction, am happy to see people experimenting in the design space. Something along these lines will be necessary, so go for it. |
Building C code from cargo or rustc was discussed in this week's planning meeting so it appears to be something of a priority. |
Awesome! Are there any notes for the meeting and what people brought up? I noticed there was a meeting sections on the wiki with weekly notes, but I'm not sure if it's been updated yet. I'm still willing to push this issue forward and do work on it, but at the moment I've been a little out of the loop as I just got a new job and moved, so you'll have to forgive me while I adjust. I'll hopefully be on IRC more soon and be able to respond to Graydon's comments he made in #1861 as well. |
The discussion is here: https://github.com/mozilla/rust/wiki/Meeting-weekly-2012-03-06 |
I'm going to close this because interfacing with autotools and $CC will be built into rustpkg and the general consensus is to eventually integrate bindgen with rustc directly for automatically generating FFI Rust code inline for C header files. If anyone thinks that there is more use cases that aren't covered, feel free to reopen. |
I assumed this bug would continue to serve the tracking role for those features. Is there a better one? |
I discussed this in #1555. Basically, there are often times when you want to bundle some C code with a package, either because it's a binding and the source is portable, you're writing a shim for say, a C++ library, or just any transient piece of glue you want to distribute (say something that interfaces with
rt
etc.)Cargo doesn't support this right now, as it only compiles crates in the source directory from what I can tell.
rustc
does not understand.c
source files. Native modules work by mapping to shared libraries, but sometimes this is overkill (because the source is small,) and other times it's clunky (sundown and other libraries may be intended to included inline, so it's more work for a user who has to do it out of band anyway.) Sometimes these shims are even required - you need a stable name for the linker to resolve, because the link-time function name is hidden behind a macro. This sort of wrapping occurs in many APIs.Ideally for something like #1555, if we could compile C/C++ code one way or another with a crate, a
sundown
library can be registered with cargo-central, with the source inline as it's only 3 files, rustdoc can be split off and also put in cargo-central too. I think this is a nice way to go, especially because rustdoc won't depend on sundown somehow being installed, but this is just one use case overall I think. It would also make it possible for me to reuse code and write bindings to other libraries easily (like LevelDB, and NaCl) that I've done in the past.There are two ways of accomplishing this broadly speaking, both with merits, I think:
rustc
be able to just accept c files to compile and run through the linker, along with crates. Alternatively this could be specified with crate attributes or something, listing the files to include in the build.cargo
actually take the responsibility of building the C files - this avoids complexity in the frontend but cargo may have to do a lot more. I think this does have merit from the POV of getting complexity out of the frontend.However, I think 1 is the way to go and has the most bang for your buck, since rustc is already doing the compilation, and can give flags that may be necessary to the C compiler (like say,
-fPIC
or not.) This does keep cargo simpler. It also makes it really easy for users:rustc leveldb
or somesuch, for example, where there may be an#cfiles[(...)]
attribute in the crate. You don't need cargo just to build your project, either.This does mean there may need to be more syntax for accommodating native methods that resolve to a link time symbol, not a full blown library. I don't know what the syntax would look like, I'm open to suggestions from others here.
The text was updated successfully, but these errors were encountered: