write a configure command

[tarekziade]

BPO	8254
Nosy	@pitrou, @tarekziade, @jkloth, @merwok

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/merwok'
closed_at = <Date 2014-03-13.07:57:42.896>
created_at = <Date 2010-03-28.14:41:23.210>
labels = ['type-feature']
title = 'write a configure command'
updated_at = <Date 2014-03-13.07:57:42.895>
user = 'https://github.com/tarekziade'

bugs.python.org fields:

activity = <Date 2014-03-13.07:57:42.895>
actor = 'eric.araujo'
assignee = 'eric.araujo'
closed = True
closed_date = <Date 2014-03-13.07:57:42.896>
closer = 'eric.araujo'
components = ['Distutils2']
creation = <Date 2010-03-28.14:41:23.210>
creator = 'tarek'
dependencies = []
files = []
hgrepos = []
issue_num = 8254
keywords = ['patch', 'needs review', 'gsoc']
message_count = 18.0
messages = ['101864', '106460', '106534', '106536', '108385', '108449', '108452', '108454', '110601', '110602', '110622', '110929', '110931', '110935', '110940', '117686', '117687', '121265']
nosy_count = 10.0
nosy_names = ['titus', 'pitrou', 'schmir', 'tarek', 'jkloth', 'eric.araujo', 'meatballhat', 'zubin71', 'l0nwlf', 'josip']
pr_nums = []
priority = 'normal'
resolution = 'out of date'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue8254'
versions = ['3rd party']

[tarekziade]

This command will contain all options that are used to build extensions (out of the build* and install* commands) and will create a confifuration file.

build* and install* commands will be able to read back the file if present, and use its values, so we don't have to pass the options again.

See 4Suite configure command for an example

[merwok]

My review of 4Suite’s config command is on <http://bitbucket.org/Merwok/distutils2/wiki/4suite/config\>. Comments welcome.

(Adding my mentor to the nosy list.)

[merwok]

Distutils2 already has a config command used to configure some aspects of C compilation. Not sure if I should expand that or write an unrelated configure command.

[tarekziade]

start a new command from scratch. The configure command is not dealing but with generating a configuration file.

config is implementing a whole compilation chain.

[merwok]

I have a working configure command at http://bitbucket.org/Merwok/distutils2-configure which works. (Read my short reports on https://wokslog.wordpress.com/ for more details.) It’s not completely finished, though:

1. I import build and install to get their user_options, to avoid duplicating these lines. Is that bad?

2. Test coverage is not exhaustive. This will be done incrementally.

3. I tried directly using Distribution and configure objects in the tests, but couldn’t get them to work; I temporarily settled for running Python (sys.executable) in a subprocess. I’m looking for help to change that.

4. As it is now, the configure command just records options without checking for conflicts (e.g. using both –prefix and –user for install). While not in the original description of the task, I think that it should be added. Prior art like 4Suite’s config command or a prototype for configure done by Tarek that I discovered only today support this idea. Is that okay? I’ll have to avoid code duplication between configure, build and install.

[merwok]

5. Should the command write different files per Python version and platform? 4Suite’s config command does that.

[pitrou]

Shouldn't "config" and "configure" have more distinguishable names?
(if I understand correctly, they both are distutils2 commands)

[merwok]

4Suite’s DistExt has a config command similar to the new Distutils2 configure command described in this bug report. The Distutils config command is an unfinished command with use similar to autotools configure scripts. From the module docstring:

“a (mostly) empty command class that exists mainly to be sub-classed by specific module distributions and applications. The idea is that while every "config" command is different, at least they're all named the same, and users always see "config" in the list of standard commands. Also, this is a good place to put common configure-like tasks: "try to compile this C code", or "figure out where this header file lives"”.

The module has seen 26 commits in 10 years. I find the name clash confusing too for end users and wanted to bring the issue later. If I understand autotools correctly, it encompasses both config and configure commands. Since there are no conflicts in options or functionality (config.run is a no-op, configure.run writes a file), I think dropping config or merging it with configure would make a lot of sense. But first things first, configure needs to be reviewed and accepted (5 open questions :) and then I’ll propose a merge into a unified config command (short names win).

[merwok]

Quick update: I have done a basic part of this, but Tarek explained to me the real usefulness of this command, i.e. provide build and installation options for third-party code (for the same purposes that get_config_var in Python’s sysconfig). I am currently working on bpo-8252 but do not forget this one.

[merwok]

Tarek also answered my questions.

1. 4. build and install options should be defined and checked only once, in configure. build and install would inherit from this class and get their option from it.

2. I switched to using distutils2.core.run_setup, which Tarek said is okayish. Understanding why the usual idiom of using the classes directly doesn’t work will be better.

3. Since the cache file (the file that contains options, written by configure) is tied to a precise build, it should be specific. I can put the platform and Python version in the filename, or maybe put the file in the platform-specific build directory. Not sure about the naming in dists. I still have to think about the overlap between setup.cfg and configure.cache.

[jkloth]

WRT #5, it would be possible to use section headers within the configure.cache file to indicate a particular "platform build". Very much like how 4Suite's config command stored the cache file.