On 10/21/2017 08:45 PM, Troy Curtis Jr wrote:
I'd like to know what everyone's take on the best way to
extensions for both python2 and python3 when the upstream build system
can only build for one at time.
The path I took for the gpsd update I submitted was to use two
independent source trees, then build one for python2 and another for
python3. But of course if the software is much more than just the
python extensions, it is rebuilding a lot of the same code, with the
same result. This could be considered a bit wasteful of CPU and disk
space, and certainly increases build time.
The only other option I could come up with would be to build for
python2, install that, and then within the install section, reconfigure
with python3 and rebuild (which should hopefully only rebuild the python
related parts), and finally install again with the python3 configured
setup. One pitfall I see with this method is the potential need to
manually clean out certain python2 based generated files if the
reconfigure isn't enough. Plus this results in building in the install
section, which seems a little bit off.
IMHO the first option is better. Sure, it wastes some CPU cycles and
disk space, as well as increases package build time. However, it seems
less prone to needing manual tweaks, provides a much cleaner distinction
between the two build configs, and would make it easier to
enable/disable the two variants as desired.
But that is just my opinion, I'm curious what the Python SIG consensus is.
This solution is good, I've used and seen it used several times.
IFAIR we've used these other strategies here; depending on the package,
they might work for you:
- If nothing in Fedora depends on the python2 version, and users aren't
likely to use it as a python2 library, just drop python2 support!
- Work with upstream to make the buildsystem build two versions at once.
This might be a lot of unnecessary work, though, so you probably don't
- Maintain two separate packages. Again, probably too much effort for