Should ./configure generate config.toml instead of config.mk?

[TimNN]

As far as I know, getting rid of ./configure is a desirable goal. As I understand it, it is kept mainly for compatibility reasons:

• It's used in the "standard unix workflow", ie. ./configure && make && make install
• which is used by linux distros shipping rust?
• It's used in our ci infrastructure

Making ./configure produce a config.toml file seems like a potential step in the right direction and would allow getting rid of a nice chunk of compatibility code in rustbuild.

Open questions:

• Do we want to get rid of ./configure in the near future? In that case making it produce a config.toml first is probably not worth the effort.
• How complicated would it be to make ./configure generate config.toml?

[alexcrichton]

Ah yeah so FWIW I don't envision us deleting the ./configure script any time soon in the near future. It's handy (as is evidenced by our own infrastructure) to have a one liner for a shell script which can configure the build. While hand-editing config.toml is always preferable I think for development machines aren't so great at it.

That being said, I think removing config.mk would be great, it'd certainly remove a lot of code in src/bootstrap/config.rs! It may not be easy to do so though getting shell scripts to emit TOML files. Ideally the shell script would emit config.toml based on config.toml.example so all the comments are still in there, but this definitely sounds like some grep/sed wizardry that I myself at least may not possess.

[est31]

this definitely sounds like some grep/sed wizardry that I myself at least may not possess.

I could have a look, but I'm not sure whether I'll be able to avoid GNU extensions. I guess macs still should be able to use it?

[ollie27]

How about adding a command like ./x.py configure to create config.toml? Writing it in Python would allow it run on Windows as well without MSYS.

[petrochenkov]

How about adding a command like ./x.py configure to create config.toml?

I'd personally go as far as making configure mandatory again and build non self-sufficient.
Maybe it will help with rustbuild thinking for 10 seconds when asked to run a single test.

[alexcrichton]

@ollie27 yeah that's a good point, writing this in Python would be quite reasonable I think. We shouldn't go too crazy though. We're better at maintaining Python than shell, but not by much.

@petrochenkov yeah I think that's a plausible idea!

[retep998]

I'd personally go as far as making configure mandatory again

Making bash mandatory to build Rust is a huge regression. For the sake of all the Windows users out there, please don't. Unless you meant making ./x.py configure mandatory first, which is probably fine.

[petrochenkov]

@retep998
I didn't mean ./configure shell script literally, just splitting rustbuild into separate configuration and build stages.

[metux]

As far as I know, getting rid of ./configure is a desirable goal.

Actually, the opposite. It's the de-facto standard in Unix world.

Doesn't need to be actual autoconf-produced (assuming you tell it loud and clear,
that folks skip the autoreconf -fi step), but it should behave like it.
Especially:

• honor the standard env variables ($CC, $LD, $AR, $PKG_CONFIG, ...)
• generate a makefile, that behaves like autoconf-generated ones (eg. honor $DESTDIR)
• honor --*dir= options
• honor --enable-/--disable- options for switchable features
• honor --host=/--build=/--target= options
• use pkg-config for library lookup (and

OTOH, the x.py call should go away - or at least done by the generated makefile, so
packagers don't need to care about it.

[retep998]

Actually, the opposite. It's the de-facto standard in Unix world.

Meanwhile Rust tries to support platforms outside the Unix world. Having a configure script that wraps the underlying rustbuild system is great for unix packagers, but unix tools should never be required to build Rust.

[metux]

Having a configure script that wraps the underlying rustbuild system is great for unix packagers, but unix tools should never be required to build Rust.

Of course, it's just meant as a frontend.

The key point is: it should behave like autoconf, provide a compatible command line interface.