2012-12-03 18:48:01 -06:00
|
|
|
// Copyright 2012 The Rust Project Developers. See the COPYRIGHT
|
|
|
|
// file at the top-level directory of this distribution and at
|
|
|
|
// http://rust-lang.org/COPYRIGHT.
|
|
|
|
//
|
|
|
|
// Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or
|
|
|
|
// http://www.apache.org/licenses/LICENSE-2.0> or the MIT license
|
|
|
|
// <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your
|
|
|
|
// option. This file may not be copied, modified, or distributed
|
|
|
|
// except according to those terms.
|
|
|
|
|
2012-07-04 16:53:12 -05:00
|
|
|
//! Validates all used crates and extern libraries and loads their metadata
|
2011-03-15 18:30:43 -05:00
|
|
|
|
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-15 16:03:29 -06:00
|
|
|
use driver::session::Session;
|
2012-12-23 16:41:37 -06:00
|
|
|
use metadata::cstore;
|
|
|
|
use metadata::decoder;
|
|
|
|
use metadata::loader;
|
|
|
|
|
2013-06-28 17:32:26 -05:00
|
|
|
use std::hashmap::HashMap;
|
2013-07-19 20:42:11 -05:00
|
|
|
use syntax::ast;
|
2013-07-31 15:47:32 -05:00
|
|
|
use std::vec;
|
2012-09-04 13:54:36 -05:00
|
|
|
use syntax::attr;
|
2013-07-19 06:51:37 -05:00
|
|
|
use syntax::attr::AttrMetaMethods;
|
2013-08-31 11:13:04 -05:00
|
|
|
use syntax::codemap::{Span, dummy_sp};
|
2012-12-23 16:41:37 -06:00
|
|
|
use syntax::diagnostic::span_handler;
|
2013-06-04 14:34:25 -05:00
|
|
|
use syntax::parse::token;
|
2012-09-04 13:54:36 -05:00
|
|
|
use syntax::parse::token::ident_interner;
|
2013-08-26 04:01:39 -05:00
|
|
|
use syntax::visit;
|
2011-03-15 18:30:43 -05:00
|
|
|
|
2012-07-03 18:11:00 -05:00
|
|
|
// Traverses an AST, reading all the information about use'd crates and extern
|
2011-07-07 23:03:09 -05:00
|
|
|
// libraries necessary for later resolving, typechecking, linking, etc.
|
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-15 16:03:29 -06:00
|
|
|
pub fn read_crates(sess: Session,
|
2013-07-19 00:38:55 -05:00
|
|
|
crate: &ast::Crate,
|
2013-08-31 11:13:04 -05:00
|
|
|
os: loader::Os,
|
2013-01-29 18:51:16 -06:00
|
|
|
intr: @ident_interner) {
|
2013-02-04 16:02:01 -06:00
|
|
|
let e = @mut Env {
|
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-15 16:03:29 -06:00
|
|
|
sess: sess,
|
2013-02-04 16:02:01 -06:00
|
|
|
os: os,
|
|
|
|
crate_cache: @mut ~[],
|
|
|
|
next_crate_num: 1,
|
|
|
|
intr: intr
|
|
|
|
};
|
2013-08-26 04:01:39 -05:00
|
|
|
let mut v = ReadCrateVisitor{ e:e };
|
2013-02-16 09:21:56 -06:00
|
|
|
visit_crate(e, crate);
|
2013-08-26 04:01:39 -05:00
|
|
|
visit::walk_crate(&mut v, crate, ());
|
2013-06-27 08:04:22 -05:00
|
|
|
dump_crates(*e.crate_cache);
|
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-15 16:03:29 -06:00
|
|
|
warn_if_multiple_versions(e, sess.diagnostic(), *e.crate_cache);
|
2012-04-06 01:42:32 -05:00
|
|
|
}
|
|
|
|
|
2013-08-26 04:01:39 -05:00
|
|
|
struct ReadCrateVisitor { e:@mut Env }
|
|
|
|
impl visit::Visitor<()> for ReadCrateVisitor {
|
|
|
|
fn visit_view_item(&mut self, a:&ast::view_item, _:()) {
|
|
|
|
visit_view_item(self.e, a);
|
|
|
|
visit::walk_view_item(self, a, ());
|
|
|
|
}
|
|
|
|
fn visit_item(&mut self, a:@ast::item, _:()) {
|
|
|
|
visit_item(self.e, a);
|
|
|
|
visit::walk_item(self, a, ());
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-08-12 11:39:19 -05:00
|
|
|
#[deriving(Clone)]
|
2013-02-19 01:40:42 -06:00
|
|
|
struct cache_entry {
|
2013-11-26 23:02:25 -06:00
|
|
|
cnum: ast::CrateNum,
|
2013-08-31 11:13:04 -05:00
|
|
|
span: Span,
|
2013-06-12 12:02:55 -05:00
|
|
|
hash: @str,
|
2013-07-19 06:51:37 -05:00
|
|
|
metas: @~[@ast::MetaItem]
|
2013-02-19 01:40:42 -06:00
|
|
|
}
|
2012-04-06 01:42:32 -05:00
|
|
|
|
2013-06-27 08:04:22 -05:00
|
|
|
fn dump_crates(crate_cache: &[cache_entry]) {
|
2013-10-21 15:08:31 -05:00
|
|
|
debug!("resolved crates:");
|
2013-08-03 11:45:23 -05:00
|
|
|
for entry in crate_cache.iter() {
|
2013-10-21 15:08:31 -05:00
|
|
|
debug!("cnum: {:?}", entry.cnum);
|
|
|
|
debug!("span: {:?}", entry.span);
|
|
|
|
debug!("hash: {:?}", entry.hash);
|
2012-04-09 17:06:38 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-02-04 16:02:01 -06:00
|
|
|
fn warn_if_multiple_versions(e: @mut Env,
|
2013-08-11 12:26:59 -05:00
|
|
|
diag: @mut span_handler,
|
2013-06-27 08:04:22 -05:00
|
|
|
crate_cache: &[cache_entry]) {
|
2012-06-04 10:03:14 -05:00
|
|
|
if crate_cache.len() != 0u {
|
2013-01-07 16:16:52 -06:00
|
|
|
let name = loader::crate_name_from_metas(
|
2013-03-05 21:39:18 -06:00
|
|
|
*crate_cache[crate_cache.len() - 1].metas
|
|
|
|
);
|
|
|
|
|
2013-08-12 11:39:19 -05:00
|
|
|
let (matches, non_matches) = crate_cache.partitioned(|entry|
|
|
|
|
name == loader::crate_name_from_metas(*entry.metas));
|
2012-04-06 01:42:32 -05:00
|
|
|
|
2013-03-28 20:39:09 -05:00
|
|
|
assert!(!matches.is_empty());
|
2012-04-06 01:42:32 -05:00
|
|
|
|
|
|
|
if matches.len() != 1u {
|
2012-05-22 19:48:04 -05:00
|
|
|
diag.handler().warn(
|
2013-09-28 00:38:08 -05:00
|
|
|
format!("using multiple versions of crate `{}`", name));
|
2013-08-03 11:45:23 -05:00
|
|
|
for match_ in matches.iter() {
|
2013-05-19 00:07:44 -05:00
|
|
|
diag.span_note(match_.span, "used here");
|
2012-06-29 18:26:56 -05:00
|
|
|
let attrs = ~[
|
2013-07-02 14:47:32 -05:00
|
|
|
attr::mk_attr(attr::mk_list_item(@"link",
|
|
|
|
(*match_.metas).clone()))
|
2012-06-29 18:26:56 -05:00
|
|
|
];
|
2012-07-18 18:18:02 -05:00
|
|
|
loader::note_linkage_attrs(e.intr, diag, attrs);
|
2012-04-06 01:42:32 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-06-27 08:04:22 -05:00
|
|
|
warn_if_multiple_versions(e, diag, non_matches);
|
2012-04-06 01:42:32 -05:00
|
|
|
}
|
2011-07-07 23:03:09 -05:00
|
|
|
}
|
|
|
|
|
2013-02-04 16:02:01 -06:00
|
|
|
struct Env {
|
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-15 16:03:29 -06:00
|
|
|
sess: Session,
|
2013-08-31 11:13:04 -05:00
|
|
|
os: loader::Os,
|
2013-02-04 16:02:01 -06:00
|
|
|
crate_cache: @mut ~[cache_entry],
|
2013-07-19 00:38:55 -05:00
|
|
|
next_crate_num: ast::CrateNum,
|
2013-02-04 16:02:01 -06:00
|
|
|
intr: @ident_interner
|
|
|
|
}
|
2011-07-07 23:37:56 -05:00
|
|
|
|
2013-07-19 00:38:55 -05:00
|
|
|
fn visit_crate(e: &Env, c: &ast::Crate) {
|
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-15 16:03:29 -06:00
|
|
|
let cstore = e.sess.cstore;
|
2013-02-16 09:21:56 -06:00
|
|
|
|
2013-08-03 11:45:23 -05:00
|
|
|
for a in c.attrs.iter().filter(|m| "link_args" == m.name()) {
|
2013-07-19 06:51:37 -05:00
|
|
|
match a.value_str() {
|
2013-02-16 09:21:56 -06:00
|
|
|
Some(ref linkarg) => {
|
2013-06-12 12:02:55 -05:00
|
|
|
cstore::add_used_link_args(cstore, *linkarg);
|
2013-02-16 09:21:56 -06:00
|
|
|
}
|
|
|
|
None => {/* fallthrough */ }
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-07-05 03:28:53 -05:00
|
|
|
fn visit_view_item(e: @mut Env, i: &ast::view_item) {
|
2013-03-20 00:17:42 -05:00
|
|
|
match i.node {
|
2013-07-31 15:47:32 -05:00
|
|
|
ast::view_item_extern_mod(ident, path_opt, ref meta_items, id) => {
|
|
|
|
let ident = token::ident_to_str(&ident);
|
|
|
|
let meta_items = match path_opt {
|
|
|
|
None => meta_items.clone(),
|
2013-10-07 19:49:10 -05:00
|
|
|
Some((p, _path_str_style)) => {
|
2013-11-22 17:45:12 -06:00
|
|
|
let p_path = Path::init(p);
|
2013-09-26 19:21:59 -05:00
|
|
|
match p_path.filestem_str() {
|
|
|
|
None|Some("") =>
|
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-15 16:03:29 -06:00
|
|
|
e.sess.span_bug(i.span, "Bad package path in `extern mod` item"),
|
2013-07-31 15:47:32 -05:00
|
|
|
Some(s) =>
|
|
|
|
vec::append(
|
|
|
|
~[attr::mk_name_value_item_str(@"package_id", p),
|
|
|
|
attr::mk_name_value_item_str(@"name", s.to_managed())],
|
2013-09-26 19:21:59 -05:00
|
|
|
*meta_items)
|
2013-07-31 15:47:32 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
};
|
2013-10-21 15:08:31 -05:00
|
|
|
debug!("resolving extern mod stmt. ident: {:?}, meta: {:?}",
|
2013-07-31 15:47:32 -05:00
|
|
|
ident, meta_items);
|
|
|
|
let cnum = resolve_crate(e,
|
|
|
|
ident,
|
|
|
|
meta_items,
|
|
|
|
@"",
|
|
|
|
i.span);
|
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-15 16:03:29 -06:00
|
|
|
cstore::add_extern_mod_stmt_cnum(e.sess.cstore, id, cnum);
|
2011-07-27 07:19:39 -05:00
|
|
|
}
|
2012-08-03 21:59:04 -05:00
|
|
|
_ => ()
|
2013-07-31 15:47:32 -05:00
|
|
|
}
|
2011-07-07 23:37:56 -05:00
|
|
|
}
|
|
|
|
|
2013-06-27 08:04:22 -05:00
|
|
|
fn visit_item(e: &Env, i: @ast::item) {
|
2013-03-20 00:17:42 -05:00
|
|
|
match i.node {
|
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-15 16:03:29 -06:00
|
|
|
ast::item_foreign_mod(ref fm) => {
|
|
|
|
if fm.abis.is_rust() || fm.abis.is_intrinsic() {
|
|
|
|
return;
|
|
|
|
}
|
2013-10-10 14:57:34 -05:00
|
|
|
|
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-15 16:03:29 -06:00
|
|
|
// First, add all of the custom link_args attributes
|
|
|
|
let cstore = e.sess.cstore;
|
|
|
|
let link_args = i.attrs.iter()
|
|
|
|
.filter_map(|at| if "link_args" == at.name() {Some(at)} else {None})
|
|
|
|
.to_owned_vec();
|
|
|
|
for m in link_args.iter() {
|
|
|
|
match m.value_str() {
|
|
|
|
Some(linkarg) => {
|
|
|
|
cstore::add_used_link_args(cstore, linkarg);
|
|
|
|
}
|
|
|
|
None => { /* fallthrough */ }
|
|
|
|
}
|
|
|
|
}
|
2012-09-04 18:40:11 -05:00
|
|
|
|
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-15 16:03:29 -06:00
|
|
|
// Next, process all of the #[link(..)]-style arguments
|
|
|
|
let cstore = e.sess.cstore;
|
|
|
|
let link_args = i.attrs.iter()
|
|
|
|
.filter_map(|at| if "link" == at.name() {Some(at)} else {None})
|
|
|
|
.to_owned_vec();
|
|
|
|
for m in link_args.iter() {
|
|
|
|
match m.meta_item_list() {
|
|
|
|
Some(items) => {
|
2013-11-28 20:03:38 -06:00
|
|
|
let kind = items.iter().find(|k| {
|
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-15 16:03:29 -06:00
|
|
|
"kind" == k.name()
|
2013-11-28 20:03:38 -06:00
|
|
|
}).and_then(|a| a.value_str());
|
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-15 16:03:29 -06:00
|
|
|
let kind = match kind {
|
|
|
|
Some(k) if "static" == k => cstore::NativeStatic,
|
|
|
|
Some(k) => {
|
|
|
|
e.sess.span_fatal(i.span,
|
|
|
|
format!("unknown kind: `{}`", k));
|
|
|
|
}
|
|
|
|
None => cstore::NativeUnknown
|
|
|
|
};
|
2013-11-28 20:03:38 -06:00
|
|
|
let n = items.iter().find(|n| {
|
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-15 16:03:29 -06:00
|
|
|
"name" == n.name()
|
2013-11-28 20:03:38 -06:00
|
|
|
}).and_then(|a| a.value_str());
|
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-15 16:03:29 -06:00
|
|
|
let n = match n {
|
|
|
|
Some(n) => n,
|
|
|
|
None => {
|
|
|
|
e.sess.span_fatal(i.span,
|
|
|
|
"#[link(...)] specified without \
|
|
|
|
`name = \"foo\"`");
|
|
|
|
}
|
|
|
|
};
|
|
|
|
cstore::add_used_library(cstore, n.to_owned(), kind);
|
|
|
|
}
|
|
|
|
None => {}
|
2013-02-16 11:48:28 -06:00
|
|
|
}
|
2011-07-27 07:19:39 -05:00
|
|
|
}
|
2011-07-07 23:37:56 -05:00
|
|
|
}
|
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-15 16:03:29 -06:00
|
|
|
_ => { }
|
2011-07-07 23:37:56 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-07-19 06:51:37 -05:00
|
|
|
fn metas_with(ident: @str, key: @str, mut metas: ~[@ast::MetaItem])
|
|
|
|
-> ~[@ast::MetaItem] {
|
|
|
|
// Check if key isn't there yet.
|
|
|
|
if !attr::contains_name(metas, key) {
|
2013-06-27 08:04:22 -05:00
|
|
|
metas.push(attr::mk_name_value_item_str(key, ident));
|
2012-04-05 20:31:03 -05:00
|
|
|
}
|
2013-06-27 08:04:22 -05:00
|
|
|
metas
|
2012-04-05 20:31:03 -05:00
|
|
|
}
|
|
|
|
|
2013-07-19 06:51:37 -05:00
|
|
|
fn metas_with_ident(ident: @str, metas: ~[@ast::MetaItem])
|
|
|
|
-> ~[@ast::MetaItem] {
|
2013-06-12 12:02:55 -05:00
|
|
|
metas_with(ident, @"name", metas)
|
2012-04-07 13:00:00 -05:00
|
|
|
}
|
|
|
|
|
2013-07-19 06:51:37 -05:00
|
|
|
fn existing_match(e: &Env, metas: &[@ast::MetaItem], hash: &str)
|
2013-11-26 23:02:25 -06:00
|
|
|
-> Option<ast::CrateNum> {
|
2013-08-03 11:45:23 -05:00
|
|
|
for c in e.crate_cache.iter() {
|
2012-06-04 10:03:14 -05:00
|
|
|
if loader::metadata_matches(*c.metas, metas)
|
2013-06-27 08:04:22 -05:00
|
|
|
&& (hash.is_empty() || c.hash.as_slice() == hash) {
|
2012-08-20 14:23:37 -05:00
|
|
|
return Some(c.cnum);
|
2012-06-04 10:03:14 -05:00
|
|
|
}
|
|
|
|
}
|
2012-08-20 14:23:37 -05:00
|
|
|
return None;
|
2012-04-05 20:31:03 -05:00
|
|
|
}
|
|
|
|
|
2013-02-04 16:02:01 -06:00
|
|
|
fn resolve_crate(e: @mut Env,
|
2013-07-31 15:47:32 -05:00
|
|
|
ident: @str,
|
2013-07-19 06:51:37 -05:00
|
|
|
metas: ~[@ast::MetaItem],
|
2013-06-12 12:02:55 -05:00
|
|
|
hash: @str,
|
2013-08-31 11:13:04 -05:00
|
|
|
span: Span)
|
2013-07-19 00:38:55 -05:00
|
|
|
-> ast::CrateNum {
|
2013-07-31 15:47:32 -05:00
|
|
|
let metas = metas_with_ident(ident, metas);
|
2012-04-05 20:31:03 -05:00
|
|
|
|
2012-08-06 14:34:08 -05:00
|
|
|
match existing_match(e, metas, hash) {
|
2012-08-20 14:23:37 -05:00
|
|
|
None => {
|
2013-02-19 01:40:42 -06:00
|
|
|
let load_ctxt = loader::Context {
|
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-15 16:03:29 -06:00
|
|
|
sess: e.sess,
|
2012-05-22 19:16:26 -05:00
|
|
|
span: span,
|
|
|
|
ident: ident,
|
2013-01-17 21:14:26 -06:00
|
|
|
metas: metas,
|
2012-05-22 19:16:26 -05:00
|
|
|
hash: hash,
|
2012-05-22 19:48:04 -05:00
|
|
|
os: e.os,
|
2012-07-18 18:18:02 -05:00
|
|
|
intr: e.intr
|
2012-05-22 19:16:26 -05:00
|
|
|
};
|
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-15 16:03:29 -06:00
|
|
|
let loader::Library {
|
|
|
|
dylib, rlib, metadata
|
|
|
|
} = load_ctxt.load_library_crate();
|
2011-07-08 14:40:16 -05:00
|
|
|
|
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-15 16:03:29 -06:00
|
|
|
let attrs = decoder::get_crate_attributes(metadata);
|
2012-04-05 20:31:03 -05:00
|
|
|
let linkage_metas = attr::find_linkage_metas(attrs);
|
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-15 16:03:29 -06:00
|
|
|
let hash = decoder::get_crate_hash(metadata);
|
2012-04-05 20:31:03 -05:00
|
|
|
|
2011-07-08 14:55:38 -05:00
|
|
|
// Claim this crate number and cache it
|
2011-07-27 07:19:39 -05:00
|
|
|
let cnum = e.next_crate_num;
|
2013-02-19 01:40:42 -06:00
|
|
|
e.crate_cache.push(cache_entry {
|
|
|
|
cnum: cnum,
|
|
|
|
span: span,
|
|
|
|
hash: hash,
|
|
|
|
metas: @linkage_metas
|
|
|
|
});
|
2011-07-08 14:04:52 -05:00
|
|
|
e.next_crate_num += 1;
|
2011-07-08 14:40:16 -05:00
|
|
|
|
2011-07-08 14:55:38 -05:00
|
|
|
// Now resolve the crates referenced by this crate
|
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-15 16:03:29 -06:00
|
|
|
let cnum_map = resolve_crate_deps(e, metadata);
|
2011-07-08 14:55:38 -05:00
|
|
|
|
2012-04-15 03:07:47 -05:00
|
|
|
let cname =
|
2013-01-17 21:14:26 -06:00
|
|
|
match attr::last_meta_item_value_str_by_name(load_ctxt.metas,
|
2013-05-19 00:07:44 -05:00
|
|
|
"name") {
|
2013-02-16 12:16:32 -06:00
|
|
|
Some(v) => v,
|
2013-07-31 15:47:32 -05:00
|
|
|
None => ident
|
2012-04-15 03:07:47 -05:00
|
|
|
};
|
2013-02-19 01:40:42 -06:00
|
|
|
let cmeta = @cstore::crate_metadata {
|
|
|
|
name: cname,
|
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-15 16:03:29 -06:00
|
|
|
data: metadata,
|
2013-02-19 01:40:42 -06:00
|
|
|
cnum_map: cnum_map,
|
|
|
|
cnum: cnum
|
|
|
|
};
|
2011-07-08 14:55:38 -05:00
|
|
|
|
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-15 16:03:29 -06:00
|
|
|
let cstore = e.sess.cstore;
|
2011-07-08 14:40:16 -05:00
|
|
|
cstore::set_crate_data(cstore, cnum, cmeta);
|
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-15 16:03:29 -06:00
|
|
|
cstore::add_used_crate_source(cstore, cstore::CrateSource {
|
|
|
|
dylib: dylib,
|
|
|
|
rlib: rlib,
|
|
|
|
cnum: cnum,
|
|
|
|
});
|
2012-08-01 19:30:05 -05:00
|
|
|
return cnum;
|
2012-04-05 20:31:03 -05:00
|
|
|
}
|
2012-08-20 14:23:37 -05:00
|
|
|
Some(cnum) => {
|
2012-08-01 19:30:05 -05:00
|
|
|
return cnum;
|
2012-04-05 20:31:03 -05:00
|
|
|
}
|
|
|
|
}
|
2011-07-08 14:55:38 -05:00
|
|
|
}
|
2011-05-26 19:16:54 -05:00
|
|
|
|
2011-07-08 14:55:38 -05:00
|
|
|
// Go through the crate metadata and load any crates that it references
|
2013-08-25 22:21:13 -05:00
|
|
|
fn resolve_crate_deps(e: @mut Env, cdata: @~[u8]) -> cstore::cnum_map {
|
2013-10-21 15:08:31 -05:00
|
|
|
debug!("resolving deps of external crate");
|
2011-07-08 14:55:38 -05:00
|
|
|
// The map from crate numbers in the crate we're resolving to local crate
|
|
|
|
// numbers
|
2013-04-03 08:28:36 -05:00
|
|
|
let mut cnum_map = HashMap::new();
|
2013-06-21 07:29:53 -05:00
|
|
|
let r = decoder::get_crate_deps(cdata);
|
2013-08-03 11:45:23 -05:00
|
|
|
for dep in r.iter() {
|
2011-07-27 07:19:39 -05:00
|
|
|
let extrn_cnum = dep.cnum;
|
2013-06-04 01:00:49 -05:00
|
|
|
let cname_str = token::ident_to_str(&dep.name);
|
2013-06-12 12:02:55 -05:00
|
|
|
let cmetas = metas_with(dep.vers, @"vers", ~[]);
|
2013-10-21 15:08:31 -05:00
|
|
|
debug!("resolving dep crate {} ver: {} hash: {}",
|
2013-06-12 12:02:55 -05:00
|
|
|
cname_str, dep.vers, dep.hash);
|
2013-07-02 14:47:32 -05:00
|
|
|
match existing_match(e,
|
|
|
|
metas_with_ident(cname_str, cmetas.clone()),
|
2012-07-18 18:18:02 -05:00
|
|
|
dep.hash) {
|
2012-08-20 14:23:37 -05:00
|
|
|
Some(local_cnum) => {
|
2013-10-21 15:08:31 -05:00
|
|
|
debug!("already have it");
|
2011-07-08 14:55:38 -05:00
|
|
|
// We've already seen this crate
|
|
|
|
cnum_map.insert(extrn_cnum, local_cnum);
|
2012-04-05 20:31:03 -05:00
|
|
|
}
|
2012-08-20 14:23:37 -05:00
|
|
|
None => {
|
2013-10-21 15:08:31 -05:00
|
|
|
debug!("need to load it");
|
2011-07-08 14:55:38 -05:00
|
|
|
// This is a new one so we've got to load it
|
2012-06-21 18:44:10 -05:00
|
|
|
// FIXME (#2404): Need better error reporting than just a bogus
|
|
|
|
// span.
|
2013-01-30 11:56:33 -06:00
|
|
|
let fake_span = dummy_sp();
|
2013-07-31 15:47:32 -05:00
|
|
|
let local_cnum = resolve_crate(e, cname_str, cmetas, dep.hash,
|
2013-02-16 12:16:32 -06:00
|
|
|
fake_span);
|
2011-07-08 14:55:38 -05:00
|
|
|
cnum_map.insert(extrn_cnum, local_cnum);
|
2012-04-05 20:31:03 -05:00
|
|
|
}
|
2011-07-08 14:55:38 -05:00
|
|
|
}
|
|
|
|
}
|
2013-03-22 21:26:41 -05:00
|
|
|
return @mut cnum_map;
|
2011-07-08 14:55:38 -05:00
|
|
|
}
|