[release] Python 3 build problems
Hi, Is there anyone who can write a brief description of the build problem with python 3 for the release notes? We probably should say something. thanks, Daniel
On 17/04/15 07:30 AM, Daniel James wrote:
Hi,
Is there anyone who can write a brief description of the build problem with python 3 for the release notes? We probably should say something.
I checked in a patch a few weeks ago that should have fixed the issue that was raised recently. Is this not included in the release ? If so, why not ? Or are we talking about a different issue here ? Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...
On 17 April 2015 at 12:58, Stefan Seefeld <stefan@seefeld.name> wrote:
On 17/04/15 07:30 AM, Daniel James wrote:
Hi,
Is there anyone who can write a brief description of the build problem with python 3 for the release notes? We probably should say something.
I checked in a patch a few weeks ago that should have fixed the issue that was raised recently. Is this not included in the release ? If so, why not ? Or are we talking about a different issue here ?
The release is based on RC3, and there was some sort of build problem with that. That's pretty much all I know, I haven't been following this issue.
On Fri, Apr 17, 2015 at 6:30 AM, Daniel James <dnljms@gmail.com> wrote:
Hi,
Is there anyone who can write a brief description of the build problem with python 3 for the release notes? We probably should say something.
I think a summary might be: Boost::Python will fail to build if it is complied agains a version of python that is one of: 3.0.X, 3.1.X, 3.2.X, 3.3.X. Versions 2.X and 3.4+ are not affected. Tom
On 17 April 2015 at 15:30, Tom Kent <lists@teeks99.com> wrote:
Boost::Python will fail to build if it is complied agains a version of python that is one of: 3.0.X, 3.1.X, 3.2.X, 3.3.X. Versions 2.X and 3.4+ are not affected.
Thanks. Btw. I can also add a patch to the release notes if needed.
On 17/04/15 01:57 PM, Daniel James wrote:
On 17 April 2015 at 15:30, Tom Kent <lists@teeks99.com> wrote:
Boost::Python will fail to build if it is complied agains a version of python that is one of: 3.0.X, 3.1.X, 3.2.X, 3.3.X. Versions 2.X and 3.4+ are not affected. Thanks. Btw. I can also add a patch to the release notes if needed.
The patch to fix the issue for Python3 < 3.4 is https://github.com/boostorg/python/commit/3e405b6fd5db5615bbef241763de070118... FWIW, Stefan PS: It's a pitty that none of the test builders indicate what Python version they are running with. That would have been valuable information for Boost.Python tests. -- ...ich hab' noch einen Koffer in Berlin...
On Apr 17, 2015 1:03 PM, "Stefan Seefeld" <stefan@seefeld.name> wrote:
On 17/04/15 01:57 PM, Daniel James wrote:
On 17 April 2015 at 15:30, Tom Kent <lists@teeks99.com> wrote:
Boost::Python will fail to build if it is complied agains a version of python that is one of: 3.0.X, 3.1.X, 3.2.X, 3.3.X. Versions 2.X and
3.4+
are not affected. Thanks. Btw. I can also add a patch to the release notes if needed.
The patch to fix the issue for Python3 < 3.4 is
https://github.com/boostorg/python/commit/3e405b6fd5db5615bbef241763de070118...
FWIW, Stefan
PS: It's a pitty that none of the test builders indicate what Python version they are running with. That would have been valuable information for Boost.Python tests.
If it's important you should add an informational test that shows the Python version being tested.
On 17/04/15 02:22 PM, Rene Rivera wrote:
On Apr 17, 2015 1:03 PM, "Stefan Seefeld" <stefan@seefeld.name> wrote:
PS: It's a pitty that none of the test builders indicate what Python version they are running with. That would have been valuable information for Boost.Python tests. If it's important you should add an informational test that shows the Python version being tested.
While that might work, it seems a bit hackish to me. It seems the Python version (as well as a number of other config parameters) are valuable metadata associated with a given build that would be useful to display, alongside the compiler name / version in use. Stefan -- ...ich hab' noch einen Koffer in Berlin...
On Apr 17, 2015 1:27 PM, "Stefan Seefeld" <stefan@seefeld.name> wrote:
On 17/04/15 02:22 PM, Rene Rivera wrote:
On Apr 17, 2015 1:03 PM, "Stefan Seefeld" <stefan@seefeld.name> wrote:
PS: It's a pitty that none of the test builders indicate what Python version they are running with. That would have been valuable
information
for Boost.Python tests. If it's important you should add an informational test that shows the Python version being tested.
While that might work, it seems a bit hackish to me. It seems the Python version (as well as a number of other config parameters) are valuable metadata associated with a given build that would be useful to display, alongside the compiler name / version in use.
It's actually the less hackish way. As it handles the eventuality that the version of Python that the tools are using will be different than the one being tested for BPL. And would also account for multiple versions being tested in the same b2 run.
On Fri, Apr 17, 2015 at 1:51 PM, Rene Rivera <grafikrobot@gmail.com> wrote:
On Apr 17, 2015 1:27 PM, "Stefan Seefeld" <stefan@seefeld.name> wrote:
On 17/04/15 02:22 PM, Rene Rivera wrote:
On Apr 17, 2015 1:03 PM, "Stefan Seefeld" <stefan@seefeld.name> wrote:
PS: It's a pitty that none of the test builders indicate what Python version they are running with. That would have been valuable
information
for Boost.Python tests. If it's important you should add an informational test that shows the Python version being tested.
While that might work, it seems a bit hackish to me. It seems the Python version (as well as a number of other config parameters) are valuable metadata associated with a given build that would be useful to display, alongside the compiler name / version in use.
It's actually the less hackish way. As it handles the eventuality that the version of Python that the tools are using will be different than the one being tested for BPL. And would also account for multiple versions being tested in the same b2 run.
I'd agree with this, if we can make it part of the test. However, it might be nice to include some more information automatically in the comment html file, just like we do with the command that is executed. For debugging purposes it might be nice to see: contents of the user-config.jam file, version of python that run.py is executed with, actual version of the toolsets being used (can we get this from bjam?). I know when I was getting my runners first setup, I had tons of problems with my user-config.jam file (and still do from time to time), and if others could have seen that in my test setup and mentioned it to me, things could have been running more smoothly much sooner. Tom
On Mon, Apr 20, 2015 at 8:53 AM, Tom Kent <lists@teeks99.com> wrote:
On Fri, Apr 17, 2015 at 1:51 PM, Rene Rivera <grafikrobot@gmail.com> wrote:
On Apr 17, 2015 1:27 PM, "Stefan Seefeld" <stefan@seefeld.name> wrote:
On 17/04/15 02:22 PM, Rene Rivera wrote:
On Apr 17, 2015 1:03 PM, "Stefan Seefeld" <stefan@seefeld.name>
wrote:
PS: It's a pitty that none of the test builders indicate what Python version they are running with. That would have been valuable
information
for Boost.Python tests. If it's important you should add an informational test that shows the Python version being tested.
While that might work, it seems a bit hackish to me. It seems the Python version (as well as a number of other config parameters) are valuable metadata associated with a given build that would be useful to display, alongside the compiler name / version in use.
It's actually the less hackish way. As it handles the eventuality that the version of Python that the tools are using will be different than the one being tested for BPL. And would also account for multiple versions being tested in the same b2 run.
I'd agree with this, if we can make it part of the test.
However, it might be nice to include some more information automatically in the comment html file, just like we do with the command that is executed.
For debugging purposes it might be nice to see: contents of the user-config.jam file, version of python that run.py is executed with, actual version of the toolsets being used (can we get this from bjam?).
I would avoid including user-config.jam or system-config.jam in the uploaded information. They are "private" files and may contain confidential information. And hence we would be liable for posting such information on a publicly accessible location. We can definitely include version information though. And maybe scrape the --debug-configuration information from BB and put it in the info (it should have the toolset information). -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
On Mon, Apr 20, 2015 at 9:12 AM, Rene Rivera <grafikrobot@gmail.com> wrote:
On Mon, Apr 20, 2015 at 8:53 AM, Tom Kent <lists@teeks99.com> wrote:
On Fri, Apr 17, 2015 at 1:51 PM, Rene Rivera <grafikrobot@gmail.com> wrote:
On Apr 17, 2015 1:27 PM, "Stefan Seefeld" <stefan@seefeld.name> wrote:
On 17/04/15 02:22 PM, Rene Rivera wrote:
On Apr 17, 2015 1:03 PM, "Stefan Seefeld" <stefan@seefeld.name>
PS: It's a pitty that none of the test builders indicate what
Python
version they are running with. That would have been valuable information for Boost.Python tests. If it's important you should add an informational test that shows
wrote: the
Python version being tested.
While that might work, it seems a bit hackish to me. It seems the Python version (as well as a number of other config parameters) are valuable metadata associated with a given build that would be useful to display, alongside the compiler name / version in use.
It's actually the less hackish way. As it handles the eventuality that the version of Python that the tools are using will be different than the one being tested for BPL. And would also account for multiple versions being tested in the same b2 run.
I'd agree with this, if we can make it part of the test.
However, it might be nice to include some more information automatically in the comment html file, just like we do with the command that is executed.
For debugging purposes it might be nice to see: contents of the user-config.jam file, version of python that run.py is executed with, actual version of the toolsets being used (can we get this from bjam?).
I would avoid including user-config.jam or system-config.jam in the uploaded information. They are "private" files and may contain confidential information. And hence we would be liable for posting such information on a publicly accessible location.
We can definitely include version information though. And maybe scrape the --debug-configuration information from BB and put it in the info (it should have the toolset information).
PS. If you have specific feature to add to the regression testing please file a task in the github boostorg/regression repo < https://github.com/boostorg/regression/issues>. So that I have a ready list of stuff to do when I have free time.
-- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
On Fri, Apr 17, 2015 at 1:02 PM, Stefan Seefeld <stefan@seefeld.name> wrote:
PS: It's a pitty that none of the test builders indicate what Python version they are running with. That would have been valuable information for Boost.Python tests.
I've just started to add it to mine: http://www.boost.org/development/tests/develop/developer/summary.html Should be rolling out to the teeks99* (at least the windows ones) over the next couple weeks. Tom
participants (4)
-
Daniel James -
Rene Rivera -
Stefan Seefeld -
Tom Kent