On 18.07.2018 19:29, Paul Koning wrote: > > >> On Jul 18, 2018, at 1:22 PM, Boris Kolpackov <bo...@codesynthesis.com> wrote: >> >> Paul Koning <paulkon...@comcast.net> writes: >> >>>> On Jul 18, 2018, at 11:13 AM, Boris Kolpackov <bo...@codesynthesis.com> >>>> wrote: >>>> >>>> I wonder what will be the expected way to obtain a suitable version of >>>> Python if one is not available on the build machine? With awk I can >>>> build it from source pretty much anywhere. Is building newer versions >>>> of Python on older targets a similarly straightforward process (somehow >>>> I doubt it)? What about Windows? >>> >>> It's the same sort of thing: untar the sources, configure, make, make >>> install.
Windows binaries and MacOSX binaries are available from upstream. The build process on *ix targets is autoconf based and easy as for awk/gawk. >> Will this also install all the Python packages one might plausible want >> to use in GCC? some extension modules depend on external libraries, but even if those don't exist, the build succeeds without building these extension modules. The sources come with embedded libs for zlib, libmpdec, libexpat. They don't include libffi (only in 3.7), libsqlite, libgdbm, libbluetooth, libdb. I suppose the usage of such modules should be banned by policy. The only needed thing is any of libdb (Berkley/SleepyCat) or gdbm to build the anydbm module which might be necessary. > It installs the entire standard Python library (corresponding to the 1800+ > pages of the library manual). I expect that will easily cover anything GCC > might want to do. The current usage of awk and perl doesn't include any third party libraries. That's where the usage of Python should start with. Matthias
