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

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

Closed
TimNN opened this issue Mar 22, 2017 · 10 comments
Closed

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

TimNN opened this issue Mar 22, 2017 · 10 comments
Labels
C-feature-request Category: A feature request, i.e: not implemented / a PR. T-infra Relevant to the infrastructure team, which will review and decide on the PR/issue.

Comments

@TimNN
Copy link
Contributor

TimNN commented Mar 22, 2017

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?
@TimNN TimNN added the A-build label Mar 22, 2017
@TimNN TimNN changed the title Should ./configure generate config.toml instead of config.mk Should ./configure generate config.toml instead of config.mk? Mar 22, 2017
@alexcrichton
Copy link
Member

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
Copy link
Member

est31 commented Mar 22, 2017

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
Copy link
Member

ollie27 commented Mar 22, 2017

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
Copy link
Contributor

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
Copy link
Member

@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
Copy link
Member

retep998 commented May 17, 2017

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
Copy link
Contributor

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

@Mark-Simulacrum Mark-Simulacrum added the T-infra Relevant to the infrastructure team, which will review and decide on the PR/issue. label Jun 23, 2017
@metux
Copy link

metux commented Jul 12, 2017

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
Copy link
Member

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
Copy link

metux commented Jul 13, 2017

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.

@Mark-Simulacrum Mark-Simulacrum added the C-feature-request Category: A feature request, i.e: not implemented / a PR. label Jul 27, 2017
alexcrichton added a commit to alexcrichton/rust that referenced this issue Aug 28, 2017
This commit rewrites our ancient `./configure` script from shell into Python.
The impetus for this change is to remove `config.mk` which is just a vestige of
the old makefile build system at this point. Instead all configuration is now
solely done through `config.toml`.

The python script allows us to more flexibly program (aka we can use loops
easily) and create a `config.toml` which is based off `config.toml.example`.
This way we can preserve comments and munge various values as we see fit.

It is intended that the configure script here is a drop-in replacement for the
previous configure script, no functional change is intended. Also note that the
rationale for this is also because our build system requires Python, so having a
python script a bit earlier shouldn't cause too many problems.

Closes rust-lang#40730
bors added a commit that referenced this issue Aug 28, 2017
…crum

rustbuild: Rewrite the configure script in Python

This commit rewrites our ancient `./configure` script from shell into Python.
The impetus for this change is to remove `config.mk` which is just a vestige of
the old makefile build system at this point. Instead all configuration is now
solely done through `config.toml`.

The python script allows us to more flexibly program (aka we can use loops
easily) and create a `config.toml` which is based off `config.toml.example`.
This way we can preserve comments and munge various values as we see fit.

It is intended that the configure script here is a drop-in replacement for the
previous configure script, no functional change is intended. Also note that the
rationale for this is also because our build system requires Python, so having a
python script a bit earlier shouldn't cause too many problems.

Closes #40730
Closes #43295
Closes #42255
Closes #38058
Closes #32176
bors added a commit that referenced this issue Aug 28, 2017
…crum

rustbuild: Rewrite the configure script in Python

This commit rewrites our ancient `./configure` script from shell into Python.
The impetus for this change is to remove `config.mk` which is just a vestige of
the old makefile build system at this point. Instead all configuration is now
solely done through `config.toml`.

The python script allows us to more flexibly program (aka we can use loops
easily) and create a `config.toml` which is based off `config.toml.example`.
This way we can preserve comments and munge various values as we see fit.

It is intended that the configure script here is a drop-in replacement for the
previous configure script, no functional change is intended. Also note that the
rationale for this is also because our build system requires Python, so having a
python script a bit earlier shouldn't cause too many problems.

Closes #40730
Closes #43295
Closes #42255
Closes #38058
Closes #32176
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-feature-request Category: A feature request, i.e: not implemented / a PR. T-infra Relevant to the infrastructure team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

8 participants