Skip to content
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

Tracking issue for custom-named-profile (RFC 2678) #6988

Open
da-x opened this issue May 27, 2019 · 2 comments
Open

Tracking issue for custom-named-profile (RFC 2678) #6988

da-x opened this issue May 27, 2019 · 2 comments

Comments

@da-x
Copy link
Member

@da-x da-x commented May 27, 2019

Steps:

  • Implement the RFC: Implemenation PR
  • Merge the implementation into master
  • Adjust documentation
  • Stabilization PR

Unresolved questions:

  • Bikeshedding the inherits keyword name.
  • Should we keep user profiles under a Toml namespace of their own?

For example:

[profile.custom.release-lto]
inherits = "release"
lto = true
  • If so, should the inherits keyword be able to refer to custom and pre-defined profiles differently?
  • Profile names would collide with rustc target names under target/. Should
    the output directory be also under a different namespace, e.g.
    target/custom/release-lto?
  • Do we really need pre-defined profiles for test, bench, or can we make them obsolete?
  • Is it worthwhile keeping test and bench outputs in target/debug and target/release? Doing so would save compilation time and space.
  • If so, is the dir-name keyword necessary? Alternatively, we can hand-code the output directory of bench and test to be release and debug to keep the current behavior. This may be sufficient until a "global binary cache" feature is implemented, or a per-workspace target/.cache (related discussion).
  • Should the PROFILE environment variable in build scripts be deprecated? Currently it only sets DEBUG or RELEASE, which isn't really useful. Should guide users to use DEBUG and OPT_LEVEL instead.
@ehuss

This comment has been minimized.

Copy link
Contributor

@ehuss ehuss commented Sep 30, 2019

A few things that came up during the PR:

How should target-specific profiles be chosen?

Stable cargo uses a variety of factors to choose the profile per compilation unit:

  • The --release flag.
  • The cargo target (test, bench, etc.).
  • The command (mode).
  • Which package (for profile overrides).

Dependencies are also special, in that when building a test, the test itself will use the "test" profile, but the dependencies will use "dev". This is done under the assumption that if the test profile is different from dev, you may not want to rebuild the world. The named-profiles feature changes this so that dependencies use the same profile as what is being built. Generally for most projects, this won't matter since most projects keep the test and dev profiles the same.

Some people have found this confusing, and it is a little hard to document clearly. However, it is intended to be intuitive (test targets use the "test" profile). The addition of named profiles makes this even more complex and possibly confusing. Try to answer the question of which profile each unit should use for the following:

  • cargo build --test t1
  • cargo test --test t1
  • cargo test --test t1 --profile=foo
  • cargo build --profile=foo --all-targets

One option is to toss away the per-target logic, and use a uniform profile for everything.

Another option is to try to have some elaborate system that tries to retain something like the old behavior.

Another option is to have some sort of target-specific profiles. That is, profile.test could be marked as being the default profile for all tests.

This is a difficult problem, and I'm not really sure where to go with it.

Add named profile support to rustc, check, and fix.

This is a bit tricky, since these commands historically had their own flags:

  • cargo rustc:
    • --profile=dev: build (default)
    • --profile=test: test mode and profile (enables cfg(test), etc.)
    • --profile=bench: bench mode and profile
    • --profile=check: check mode
  • cargo check and cargo fix:
    • --profile=test: Enables cfg(test), does not change the actual profile.

One option is to add a new flag (--mode?) to take over the old behavior. It's questionable of how these should behave, especially considering backwards compatibility, and consistency with other commands (would cargo build --profile=test enable test mode?). The path forward isn't clear to me.

bors bot added a commit to nervosnetwork/ckb that referenced this issue Dec 4, 2019
Merge #1849
1849: feat: no debug symbols as default and add a command to build with debug symbols r=quake a=yangby-cryptape

1. [Stable releases of cargo don't support custom profiles.](../../../rust-lang/cargo/issues/6988)

2. We can't use another manifest file in same directory since `error: the manifest-path must be a path to a Cargo.toml file`.

3. I try to put a debug version of `Cargo.toml` in another  directory, it's conflicted with the original `Cargo.toml`. Each crate should be in only one workspace.

4. Add arguments into `RUSTFLAGS` to control `rustc`, but it's unable to achieve the same effect.

   According to [The Cargo Book](https://doc.rust-lang.org/cargo/reference/manifest.html#the-profile-sections): `debug = true` is equivalent to `-C debuginfo=2` compiler flag.

   According to `rustc --help`, `-g` is equivalent to `-C debuginfo=2`.

   But when use `debug = true`, the size of debug symbols in executable file is bigger than `-g` (or `-C debuginfo=2`), ~~and `debug = true` will enable some other debug features, for example: `debug_assertions = true` (I found it in [rust source code](https://github.com/rust-lang/rust/blob/695fe965173795f9242dfcad6d1c07d7a17b106a/src/bootstrap/config.rs#L631-L632), but it doesn't works when I test it)~~.

   So, I think `debug = true` is better than `-g` or `-C debuginfo=2` for debugging.

   - Execute `cargo build --release` without `debug = true`.
     The size of `ckb` is 36876256 Bytes (36MB).
     After strip, it will be 26102560 Bytes (25MB).
   - Execute `cargo build --release` with `debug = true`.
     The size of `ckb` is 439163736 Bytes (419MB).
     After strip, it will be 26098544 Bytes (25MB).
   - Execute `RUSTFLAGS="-g" cargo build --release` without `debug = true`.
     The size of `ckb` is 366969536 Bytes (350MB).
     After strip, it will be 26155888 Bytes (25MB).
   - Execute `RUSTFLAGS="-C debuginfo=2" cargo build --release` without `debug = true`.
     The size of `ckb` is 26151792 Bytes (351MB).
     After strip, it will be 26098544 Bytes (25MB).

   Use same command always get the same size executable file. **It's deterministic.**

#### Appendix


<details><summary>The stripped part for stripping an executable file which compile by <code>cargo build --release</code> without <code>debug = true</code>.</summary>
<pre>
Sections:
Idx Name              Size      VMA               LMA               File off  Algn  Flags
 27 .comment          0000009a  0000000000000000  0000000000000000  018e41fa  2**0  CONTENTS, READONLY
 28 .debug_aranges    00000270  0000000000000000  0000000000000000  018e4294  2**0  CONTENTS, READONLY, DEBUGGING
 29 .debug_pubnames   0003bcbd  0000000000000000  0000000000000000  018e4504  2**0  CONTENTS, READONLY, DEBUGGING
 30 .debug_info       00150220  0000000000000000  0000000000000000  019201c1  2**0  CONTENTS, READONLY, DEBUGGING
 31 .debug_abbrev     00006993  0000000000000000  0000000000000000  01a703e1  2**0  CONTENTS, READONLY, DEBUGGING
 32 .debug_line       000a3beb  0000000000000000  0000000000000000  01a76d74  2**0  CONTENTS, READONLY, DEBUGGING
 33 .debug_frame      00001230  0000000000000000  0000000000000000  01b1a960  2**3  CONTENTS, READONLY, DEBUGGING
 34 .debug_str        000b5275  0000000000000000  0000000000000000  01b1bb90  2**0  CONTENTS, READONLY, DEBUGGING
 35 .debug_loc        001579db  0000000000000000  0000000000000000  01bd0e05  2**0  CONTENTS, READONLY, DEBUGGING
 36 .debug_macinfo    00000031  0000000000000000  0000000000000000  01d287e0  2**0  CONTENTS, READONLY, DEBUGGING
 37 .debug_pubtypes   00019c31  0000000000000000  0000000000000000  01d28811  2**0  CONTENTS, READONLY, DEBUGGING
 38 .debug_ranges     00098440  0000000000000000  0000000000000000  01d42442  2**0  CONTENTS, READONLY, DEBUGGING
</pre>
</details>

<details><summary>Size of debug symbols in executable files for different compilation conditions.</summary>
<pre>
Sections:
Idx Name               Size      VMA               LMA               File off  Algn  Flags
 // debug = true
 ... omitted ...
 29 .debug_aranges     000002a0  0000000000000000  0000000000000000  018e3294  2**0  CONTENTS, READONLY, DEBUGGING
 30 .debug_pubnames    0225e9f0  0000000000000000  0000000000000000  018e3534  2**0  CONTENTS, READONLY, DEBUGGING
 31 .debug_info        0783474a  0000000000000000  0000000000000000  03b41f24  2**0  CONTENTS, READONLY, DEBUGGING
 32 .debug_abbrev      001a9b4b  0000000000000000  0000000000000000  0b37666e  2**0  CONTENTS, READONLY, DEBUGGING
 33 .debug_line        013b5e42  0000000000000000  0000000000000000  0b5201b9  2**0  CONTENTS, READONLY, DEBUGGING
 34 .debug_frame       00001230  0000000000000000  0000000000000000  0c8d6000  2**3  CONTENTS, READONLY, DEBUGGING
 35 .debug_str         0258ab85  0000000000000000  0000000000000000  0c8d7230  2**0  CONTENTS, READONLY, DEBUGGING
 36 .debug_loc         06240092  0000000000000000  0000000000000000  0ee61db5  2**0  CONTENTS, READONLY, DEBUGGING
 37 .debug_macinfo     00000855  0000000000000000  0000000000000000  150a1e47  2**0  CONTENTS, READONLY, DEBUGGING
 38 .debug_pubtypes    02ba7a4e  0000000000000000  0000000000000000  150a269c  2**0  CONTENTS, READONLY, DEBUGGING
 39 .debug_ranges      021377a0  0000000000000000  0000000000000000  17c4a0ea  2**0  CONTENTS, READONLY, DEBUGGING
 // -g
 ... omitted ...
 29 .debug_aranges     00000270  0000000000000000  0000000000000000  018f2294  2**0  CONTENTS, READONLY, DEBUGGING
 30 .debug_pubnames    01b582ce  0000000000000000  0000000000000000  018f2504  2**0  CONTENTS, READONLY, DEBUGGING
 31 .debug_info        05ae5ecb  0000000000000000  0000000000000000  0344a7d2  2**0  CONTENTS, READONLY, DEBUGGING
 32 .debug_abbrev      0014d4d9  0000000000000000  0000000000000000  08f3069d  2**0  CONTENTS, READONLY, DEBUGGING
 33 .debug_line        010586d0  0000000000000000  0000000000000000  0907db76  2**0  CONTENTS, READONLY, DEBUGGING
 34 .debug_frame       00001230  0000000000000000  0000000000000000  0a0d6248  2**3  CONTENTS, READONLY, DEBUGGING
 35 .debug_str         01ca527f  0000000000000000  0000000000000000  0a0d7478  2**0  CONTENTS, READONLY, DEBUGGING
 36 .debug_loc         05771c55  0000000000000000  0000000000000000  0bd7c6f7  2**0  CONTENTS, READONLY, DEBUGGING
 37 .debug_macinfo     0000078b  0000000000000000  0000000000000000  114ee34c  2**0  CONTENTS, READONLY, DEBUGGING
 38 .debug_pubtypes    025cd42a  0000000000000000  0000000000000000  114eead7  2**0  CONTENTS, READONLY, DEBUGGING
 39 .debug_ranges      01e419c0  0000000000000000  0000000000000000  13abbf01  2**0  CONTENTS, READONLY, DEBUGGING
</pre>
</details>

Co-authored-by: Boyu Yang <yangby@cryptape.com>
@michaelwoerister

This comment has been minimized.

Copy link
Contributor

@michaelwoerister michaelwoerister commented Dec 19, 2019

This is something l look very much forward to! Is there an estimate of when this will become stable?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Roadmap
In Progress
3 participants
You can’t perform that action at this time.