Commit Graph

15 Commits

Author SHA1 Message Date
Alex Crichton acc5e32e53 Register new snapshots 2013-12-03 14:31:54 -08:00
bors 4252a24ae1 auto merge of #10528 : alexcrichton/rust/static-linking-v2, r=pcwalton
In this series of commits, I've implemented static linking for rust. The scheme I implemented was the same as my [mailing list post](https://mail.mozilla.org/pipermail/rust-dev/2013-November/006686.html).

The commits have more details to the nitty gritty of what went on. I've rebased this on top of my native mutex pull request (#10479), but I imagine that it will land before this lands, I just wanted to pre-emptively get all the rebase conflicts out of the way (becuase this is reorganizing building librustrt as well).

Some contentious points I want to make sure are all good:

* I've added more "compiler chooses a default" behavior than I would like, I want to make sure that this is all very clearly outlined in the code, and if not I would like to remove behavior or make it clearer.
* I want to make sure that the new "fancy suite" tests are ok (using make/python instead of another rust crate)

If we do indeed pursue this, I would be more than willing to write up a document describing how linking in rust works. I believe that this behavior should be very understandable, and the compiler should never hinder someone just because linking is a little fuzzy.
2013-11-30 14:41:40 -08:00
bors 9bf62f71bc auto merge of #10727 : erickt/rust/json, r=huonw
This PR does some small modernizations to the json library. First is to remove the `@` boxes, second is to rename the constructors to `new`.
2013-11-30 06:06:42 -08:00
Erick Tryzelaar a7b311ac61 extra: missed a couple `@` in json 2013-11-29 21:26:03 -08:00
Alex Crichton e338a4154b Add generation of static libraries to rustc
This commit implements the support necessary for generating both intermediate
and result static rust libraries. This is an implementation of my thoughts in
https://mail.mozilla.org/pipermail/rust-dev/2013-November/006686.html.

When compiling a library, we still retain the "lib" option, although now there
are "rlib", "staticlib", and "dylib" as options for crate_type (and these are
stackable). The idea of "lib" is to generate the "compiler default" instead of
having too choose (although all are interchangeable). For now I have left the
"complier default" to be a dynamic library for size reasons.

Of the rust libraries, lib{std,extra,rustuv} will bootstrap with an
rlib/dylib pair, but lib{rustc,syntax,rustdoc,rustpkg} will only be built as a
dynamic object. I chose this for size reasons, but also because you're probably
not going to be embedding the rustc compiler anywhere any time soon.

Other than the options outlined above, there are a few defaults/preferences that
are now opinionated in the compiler:

* If both a .dylib and .rlib are found for a rust library, the compiler will
  prefer the .rlib variant. This is overridable via the -Z prefer-dynamic option
* If generating a "lib", the compiler will generate a dynamic library. This is
  overridable by explicitly saying what flavor you'd like (rlib, staticlib,
  dylib).
* If no options are passed to the command line, and no crate_type is found in
  the destination crate, then an executable is generated

With this change, you can successfully build a rust program with 0 dynamic
dependencies on rust libraries. There is still a dynamic dependency on
librustrt, but I plan on removing that in a subsequent commit.

This change includes no tests just yet. Our current testing
infrastructure/harnesses aren't very amenable to doing flavorful things with
linking, so I'm planning on adding a new mode of testing which I believe belongs
as a separate commit.

Closes #552
2013-11-29 18:36:13 -08:00
Erick Tryzelaar f7b739c34c extra: Rename json constructors into *::init 2013-11-29 11:19:19 -08:00
Patrick Walton c54427ddfb libstd: Change `Path::new` to `Path::init`. 2013-11-29 10:55:13 -08:00
Alex Crichton ab387a6838 Register new snapshots 2013-11-28 20:27:56 -08:00
Marvin Löbel 24b316a3b9 Removed unneccessary `_iter` suffixes from various APIs 2013-11-26 10:02:26 +01:00
Corey Richardson 6fbe2a0c8b rustdoc: pass through --cfg to rustc
Closes #10623
2013-11-24 23:33:44 -05:00
Alex Crichton 49ee49296b Move std::rt::io to std::io 2013-11-11 20:44:07 -08:00
Andrei Formiga 455de85163 Specify package_id for rust libs, to avoid spurious warnings 2013-11-08 17:42:46 -03:00
Alex Crichton f19d083362 Fill out the remaining functionality in io::file
This adds bindings to the remaining functions provided by libuv, all of which
are useful operations on files which need to get exposed somehow.

Some highlights:

* Dropped `FileReader` and `FileWriter` and `FileStream` for one `File` type
* Moved all file-related methods to be static methods under `File`
* All directory related methods are still top-level functions
* Created `io::FilePermission` types (backed by u32) that are what you'd expect
* Created `io::FileType` and refactored `FileStat` to use FileType and
  FilePermission
* Removed the expanding matrix of `FileMode` operations. The mode of reading a
  file will not have the O_CREAT flag, but a write mode will always have the
  O_CREAT flag.

Closes #10130
Closes #10131
Closes #10121
2013-11-03 15:15:42 -08:00
Alex Crichton 9c1851019f Remove all blocking std::os blocking functions
This commit moves all thread-blocking I/O functions from the std::os module.
Their replacements can be found in either std::rt::io::file or in a hidden
"old_os" module inside of native::file. I didn't want to outright delete these
functions because they have a lot of special casing learned over time for each
OS/platform, and I imagine that these will someday get integrated into a
blocking implementation of IoFactory. For now, they're moved to a private module
to prevent bitrot and still have tests to ensure that they work.

I've also expanded the extensions to a few more methods defined on Path, most of
which were previously defined in std::os but now have non-thread-blocking
implementations as part of using the current IoFactory.

The api of io::file is in flux, but I plan on changing it in the next commit as
well.

Closes #10057
2013-11-03 15:15:42 -08:00
Chris Morgan 0369a41f0e Rename files to match current recommendations.
New standards have arisen in recent months, mostly for the use of
rustpkg, but the main Rust codebase has not been altered to match these
new specifications. This changeset rectifies most of these issues.

- Renamed the crate source files `src/libX/X.rs` to `lib.rs`, for
  consistency with current styles; this affects extra, rustc, rustdoc,
  rustpkg, rustuv, std, syntax.

- Renamed `X/X.rs` to `X/mod.rs,` as is now recommended style, for
  `std::num` and `std::terminfo`.

- Shifted `src/libstd/str/ascii.rs` out of the otherwise unused `str`
  directory, to be consistent with its import path of `std::ascii`;
  libstd is flat at present so it's more appropriate thus.

While this removes some `#[path = "..."]` directives, it does not remove
all of them, and leaves certain other inconsistencies, such as `std::u8`
et al. which are actually stored in `src/libstd/num/` (one subdirectory
down). No quorum has been reached on this issue, so I felt it best to
leave them all alone at present. #9208 deals with the possibility of
making libstd more hierarchical (such as changing the crate to match the
current filesystem structure, which would make the module path
`std::num::u8`).

There is one thing remaining in which this repository is not
rustpkg-compliant: rustpkg would have `src/std/` et al. rather than
`src/libstd/` et al. I have not endeavoured to change that at this point
as it would guarantee prompt bitrot and confusion. A change of that
magnitude needs to be discussed first.
2013-11-03 23:49:01 +11:00