msg91719 - (view) |
Author: Arfrever Frehtes Taifersar Arahesis (Arfrever) * |
Date: 2009-08-18 22:25 |
sharedmods rule of Makefile calls setup.py which doesn't fail even
building of extensions has failed.
|
msg91725 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2009-08-19 06:25 |
It is deliberate that building Python succeeds even if building an
extension has failed.
|
msg91726 - (view) |
Author: Arfrever Frehtes Taifersar Arahesis (Arfrever) * |
Date: 2009-08-19 12:03 |
An option of `configure` could be added, whose enabling would change
this behavior.
|
msg91739 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2009-08-19 20:05 |
Why is it desirable to have such an option?
|
msg91740 - (view) |
Author: Jean-Paul Calderone (exarkun) * |
Date: 2009-08-19 20:09 |
This makes it more easily possible for automated systems to detect that
there was a problem with the build.
Checking an exit code is easy. Grabbing and parsing stdout and stderr
is hard and fragile.
|
msg91743 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2009-08-19 20:26 |
> This makes it more easily possible for automated systems to detect that
> there was a problem with the build.
How do you define "problem" in this context? Why is it a problem if some
extension module did not get built? Perhaps it cannot build correctly
on this system. Is it, or is it not a problem that the module was not
built because header files were lacking that would be available, but
weren't installed on the build machine?
|
msg91744 - (view) |
Author: Jean-Paul Calderone (exarkun) * |
Date: 2009-08-19 20:27 |
If it's not a problem, then the invoker doesn't need to check the exit
code of setup.py. Why are you resistant to exposing more information?
|
msg91745 - (view) |
Author: Guilherme Polo (gpolo) * |
Date: 2009-08-19 20:34 |
> If it's not a problem, then the invoker doesn't need to check the exit
> code of setup.py.
Suppose the _tkinter module failed to compile on a given system, how
would you know if this is a problem or not ? setup.py would return 1
because it couldn't be built, but the rest of Python were compiled
successfully.
|
msg91746 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2009-08-19 21:02 |
> If it's not a problem, then the invoker doesn't need to check the exit
> code of setup.py. Why are you resistant to exposing more information?
Because I believe that the information that is being exposed in this
patch is confusing, and will trick people into believing things that
actually don't happen. When they then try to track down the problems,
they will (then rightly) complain that the implemented behavior is
incorrect.
|
msg91750 - (view) |
Author: Arfrever Frehtes Taifersar Arahesis (Arfrever) * |
Date: 2009-08-19 22:25 |
> When they then try to track down the problems, they will
> (then rightly) complain that the implemented behavior is
> incorrect.
setup.py could optionally fail immediately when building of an
extension has failed.
|
msg91753 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2009-08-19 22:35 |
>> When they then try to track down the problems, they will
>> (then rightly) complain that the implemented behavior is
>> incorrect.
>
> setup.py could optionally fail immediately when building of an
> extension has failed.
What about skipped extensions (i.e. those where building them was
not even attempted?)
Why is it interesting to know that building was attempted, but failed?
|
msg91783 - (view) |
Author: Arfrever Frehtes Taifersar Arahesis (Arfrever) * |
Date: 2009-08-20 21:06 |
When building of an extension has failed due to external reasons (e.g.
headers from too old version of a Python dependency), user might prefer
to be forced to fix these reasons, than to have Python built without an
extension. If `make` doesn't fail, user might not notice the problem
during building of Python, but some time later during trying to import
some modules. Such behavior is also especially desired in distributions
(like Gentoo) in which packages are automatically built on users'
systems.
Maybe the option could be named --enable-strict-building-of-extensions?
|
msg91785 - (view) |
Author: Guilherme Polo (gpolo) * |
Date: 2009-08-20 21:35 |
Wouldn't be more interesting to add an option where you tell exactly
which modules aren't expected to be compiled successfully ? If any
modules besides those specified are not built, then setup.py returns 1.
I, for instance, don't care if the _bsddb extension doesn't get built
but I do care that some others get compiled successfully.
|
msg91787 - (view) |
Author: Arfrever Frehtes Taifersar Arahesis (Arfrever) * |
Date: 2009-08-20 21:55 |
> Wouldn't be more interesting to add an option where you tell
> exactly which modules aren't expected to be compiled successfully ?
> If any modules besides those specified are not built, then setup.py
> returns 1.
It's good idea. The option of `configure` could be named
--enable-extensions=ext1,ext2,...
--enable-extensions=all could be also supported and it would mean that
all non-skipped extensions are requested.
|
msg91790 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2009-08-20 22:20 |
> When building of an extension has failed due to external reasons (e.g.
> headers from too old version of a Python dependency), user might prefer
> to be forced to fix these reasons, than to have Python built without an
> extension.
Ok - but your patch does not implement that. If the extension fails to
compile because the header files are not installed at all, even with
your patch, there is no error indication. So according to your
requirements, your patch is incorrect.
|
msg91791 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2009-08-20 22:22 |
>> Wouldn't be more interesting to add an option where you tell
>> exactly which modules aren't expected to be compiled successfully ?
>> If any modules besides those specified are not built, then setup.py
>> returns 1.
>
> It's good idea. The option of `configure` could be named
> --enable-extensions=ext1,ext2,...
>
> --enable-extensions=all could be also supported and it would mean that
> all non-skipped extensions are requested.
I also thought of such a solution, and could accept it.
However, it is really trivial to implement for anybody invoking an
automatic build of Python: after the build completes, do
python -c 'import ext1,ext2,...' 2>/dev/null
and check the return status - and voila, you know whether your required
modules were built successfully.
|
msg91792 - (view) |
Author: Arfrever Frehtes Taifersar Arahesis (Arfrever) * |
Date: 2009-08-20 22:30 |
> Ok - but your patch does not implement that. If the extension
> fails to compile because the header files are not installed at all,
> even with your patch, there is no error indication.
`make` will return error:
$ cat Makefile
x:
false
all: x
$ make
false
make: *** [x] Error 1
$
Also note that my original patch was created before I slightly changed
my suggestion :) .
|
msg91801 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2009-08-21 05:35 |
> `make` will return error:
No it will not. I just tested it: on my Linux system, _bsddb
was not built, yet make reported success even after installing
your patch.
|
msg121406 - (view) |
Author: Éric Araujo (eric.araujo) * |
Date: 2010-11-18 01:37 |
(Side note: Specifying optional/required extensions from the command line may be an interesting new feature in distutils2.)
|
msg241744 - (view) |
Author: Mark Lawrence (BreamoreBoy) * |
Date: 2015-04-21 20:50 |
I'm assuming that this will not be implemented until 3.6.
|
msg241793 - (view) |
Author: Jean-Paul Calderone (Jean-Paul Calderone) |
Date: 2015-04-22 09:49 |
It's only been six years, no need to rush.
|
|
Date |
User |
Action |
Args |
2022-04-11 14:56:52 | admin | set | github: 50980 |
2019-09-03 08:53:24 | djc | set | nosy:
- djc
|
2019-03-15 22:08:01 | BreamoreBoy | set | nosy:
- BreamoreBoy
|
2015-04-22 09:49:17 | Jean-Paul Calderone | set | nosy:
- exarkun, Jean-Paul Calderone
|
2015-04-22 09:49:02 | Jean-Paul Calderone | set | nosy:
+ Jean-Paul Calderone messages:
+ msg241793
|
2015-04-21 20:50:59 | BreamoreBoy | set | nosy:
+ BreamoreBoy
messages:
+ msg241744 versions:
+ Python 3.6, - Python 3.3 |
2010-12-14 03:26:28 | r.david.murray | set | type: enhancement versions:
+ Python 3.3, - Python 3.2 |
2010-11-18 01:37:06 | eric.araujo | set | nosy:
+ eric.araujo
messages:
+ msg121406 versions:
- Python 2.6, Python 3.1, Python 2.7 |
2010-10-28 13:54:35 | djc | set | nosy:
+ djc
|
2009-08-21 05:35:08 | loewis | set | messages:
+ msg91801 |
2009-08-20 22:30:45 | Arfrever | set | messages:
+ msg91792 |
2009-08-20 22:22:45 | loewis | set | messages:
+ msg91791 |
2009-08-20 22:20:09 | loewis | set | messages:
+ msg91790 |
2009-08-20 21:55:34 | Arfrever | set | messages:
+ msg91787 |
2009-08-20 21:35:04 | gpolo | set | messages:
+ msg91785 |
2009-08-20 21:06:38 | Arfrever | set | messages:
+ msg91783 |
2009-08-19 22:35:41 | loewis | set | messages:
+ msg91753 |
2009-08-19 22:25:11 | Arfrever | set | messages:
+ msg91750 |
2009-08-19 21:02:34 | loewis | set | messages:
+ msg91746 |
2009-08-19 20:34:42 | gpolo | set | nosy:
+ gpolo messages:
+ msg91745
|
2009-08-19 20:27:46 | exarkun | set | messages:
+ msg91744 |
2009-08-19 20:26:29 | loewis | set | messages:
+ msg91743 |
2009-08-19 20:09:22 | exarkun | set | nosy:
+ exarkun messages:
+ msg91740
|
2009-08-19 20:05:15 | loewis | set | messages:
+ msg91739 |
2009-08-19 12:03:22 | Arfrever | set | messages:
+ msg91726 title: Non-zero exit status of setup.py when building of extensions has failed -> Add option of non-zero exit status of setup.py when building of extensions has failed |
2009-08-19 06:25:25 | loewis | set | versions:
- Python 2.5, Python 2.4, Python 3.0 |
2009-08-19 06:25:09 | loewis | set | nosy:
+ loewis messages:
+ msg91725
|
2009-08-18 22:25:20 | Arfrever | create | |