change configure defaults

[ahicks92]

99% of the time, you want the following configure command: ./configure --enable-debug --enable-debuginfo --enable-optimize --enable-llvm-assertions --enable-debug-assertions. Current configure does not make these the default.

The consequences are twofold:

• If you don't know, you have to ask about them. It's not obvious for at least --enable-llvm-assertions at least that what you're asking about is a configure script option.
• If you discover that you need them, the rebuild is very expensive.

I suggest changing these to match the above command, then modifying the release infrastructure to turn them off for release mode. It may also be beneficial to add a --releasemode option that does so automatically for easy local testing.

[petrochenkov]

No way!
99% of the time I want simply ./configure because it builds fast (+ maybe --enable-ninja/--enable-ccache/etc, but that's kinda off-topic).
I want --enable-llvm-assertions when I work on trans and --enable-debuginfo when I encounter some especially tricky bug requiring gdb beyond basic backtrace.

[ahicks92]

I can see your argument, but I counter with this: as someone new to Rust who went straight into trans, I remember the huge amount of frustration involved in finding those in the first place. Even people on IRC weren't specifically sure which ones were needed.

Perhaps there need to be profiles or something: --releasemode matches whatever the CI infrastructure needs (and is the default), --fast does whatever we can to build faster but perhaps needs additional dependencies, --fulldebug is the above or similar,.

I'm not particularly attached to my list, either. Perhaps cut out the debug and debuginfo ones and just turn on the asserts is more reasonable?

[petrochenkov]

@camlorn
Btw, --enable-debug includes other debugging options, so ./configure --enable-debug --enable-optimize is equivalent to the configuration you wrote.

One more aspect is that debuginfo builds are not gated by buildbot and segfault or cause LLVM assertions like 80% of time (at least on Windows). I tried to build with debuginfo about a weak ago and encountered both an assert (#35566, can be worked around) and then a segfault!

[alexcrichton]

@petrochenkov is right where the current defaults are optimized for "I want a fast build of rustc". E.g. those who are just simply building from source or packagers for example. @camlorn is right though that we don't have an ergonomic switch for "I'm developing rustc" which has all those nice default options.

We had a bug for this long ago but I kinda forgot where it went. The idea though was that you'd so something like:

./configure --enable-mode=developer

or something like that. That way we can tweak over time what it means to be within that profile and we could add various other profiles as well (likely with the defaults remaining as they are today, ish)

[ahicks92]

yeah, I'd be okay with profiles. The real issue here is that it's very non-obvious which you need.

@petrochenkov's comment about duplicate options actually helps make my point: the options I'm using were the options I was given via the #rustc IRC channel. It's good to know that I only need two of them, but I'd never have found that out on my own.

[caipre]

I actually wrote about this a few little while ago.

Related: is make preferred over rustbuild?

[ahicks92]

@caipre
Sadly I can't conveniently skim your post for the part related to this issue because your web site is inaccessible to screen reader users; can you raise the relevant points here?

I don't think that make is preferred to Rustbuild, it's just that Rustbuild isn't as well documented and what have you. At some point this transition will be complete, I imagine, and make will be deprecated. But I'm not well informed on this issue, and my choice is based off what people on IRC (primarily @eddyb) gave me.

[caipre]

@camlorn: Hmm, not sure why my site wouldn't work with a screen reader. The post doesn't raise any new concerns, it was just echoing the confusion around configuration options and the current build system(s) as it pertains to developer builds. I'm also using make, and with similar parameters.

[ahicks92]

@caipre
It looks like your site tries to do something with CSS for layout instead of using normal old HTML or something, but basically the article shows up as if it were all inside the same <p> tag and with absolutely no formatting.

I've been seeing this more than a bit lately, primarily in the Rust community. I don't know which site generator or platform to blame, or even if it's a screen reader bug or not, but it's extremely annoying at best and causes me to skip the articles.

You can catch me on IRC sometimes, if you want to investigate further.

[eddyb]

@camlorn I wonder if markdown generators put in <p> tags at all. I wouldn't think about it and just have <br> (in my web design naivity).

[caipre]

@camlorn
Thanks for the information. I'm just using Jekyll, and it's a layout I wrote myself. I use CSS for styling (flexbox), but the HTML is there as well and ought to be semantic. For instance, I use <main> and <article> to set up the content, and <p> for each paragraph. It renders fine in links and the browser with CSS disabled. I wonder if the screen reader doesn't support HTML5?

Sorry to hijack the thread. I'll investigate more offline.

[ahicks92]

@eddyb
That's not what's going on. <br> will work. It's suboptimal, but it won't cause all the text to effectively be on one line.

@caipre
All the screen readers support almost all of HTML5. That's not the problem. I haven't been on IRC lately but, if you catch me there sometime or contact me through another avenue, I can look at it with firebug and see if I can spot anything obvious. I'm probably not the best person to ask, but it's annoying me at this point because it's only in the Rust ecosystem that I've seen it and you're not the only one. I should have saved those links in hindsight, but who knew it would come up?

[Mark-Simulacrum]

So with rustbuild, the defaults are still mainly the same, but the options are well-documented when going through config.toml copied from src/bootstrap/config.toml.example; I think that makes this sufficiently fixed. It's relatively straightforward to find what needs to be changed in there. As such, I'm going to close.