On 11/11/2020 11:46 AM, Rafael Sadowski wrote:
On Wed Nov 11, 2020 at 05:02:08PM +0100, Jeremie Courreges-Anglas wrote:
On Mon, Nov 09 2020, Jeremie Courreges-Anglas <j...@wxcvbn.org> wrote:
On Sun, Nov 08 2020, Rafael Sadowski <raf...@sizeofvoid.org> wrote:
On Sun Nov 08, 2020 at 01:46:14AM +0100, Jeremie Courreges-Anglas wrote:
This diff drops boost_python27 and boost_numpy27. I switched the
defaults to python3 but the boost-build .py files aren't ready for that
(using python3 -m compileall fails with syntax errors). No idea how
used/useful boost-build actually is or how maintainers want to deal with
this python2/3 mix. One possible approach would be to run 2to3 on
those files, but this doesn't catch all the py2->py3 gotchas.
I also worked on it yesterday and found the same py2->py3 issue.
So what do you think should be done? :)
I can propose:
1. keep the diff as is, it looks weird but maybe boost-build still works fine
(no idea how to test that)
2. drop the boost-build parts until a new release brings proper python3
support
3. some hacks to make the current boost-build work with python3 (I have
nothing against it but I'd prefer not to care about this myself)
< rsadowski> My idea would be
[2] remove all in share/boost-build
[4] remove the compileall.py task.
I'd prefer to go with option 2, option 4 means that .pyc files can stay
around if the user starts boost-build as root.
So, shall we go ahead with this diff? If so I'll ask Antoine to slip
this in his next bulk (per sthen@ suggestion). More tests are obviously
welcome.
I have just committed the make fake tweak, so you need to apply this on
a fresh CVS checkout.
If Brad accept option 2, I would like to install the following tools
anyway. This means that the boost build system can still be used.
- # boost-build:
- ${INSTALL_PROGRAM} ${WRKSRC}/tools/build/src/engine/bin.*/{b2,bjam} \
- ${PREFIX}/bin
...
- ${INSTALL_DATA_DIR} ${PREFIX}/share/examples/boost-build
- ${INSTALL_DATA} ${WRKSRC}/tools/build/example/site-config.jam \
- ${PREFIX}/share/examples/boost-build
Well the only question I have is if we remove this does anything in the
ports tree
depend it for building anything? If not, then I'd say go with removing
it all together
for the time being until it is updated to be compatible with Python 3.
If the answer
is yes then how many ports?
