On 07/18/2018 08:03 PM, Matthias Klose wrote: > 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.
Thank you Matthias for explanation of dependencies problematics. I can confirm that option handling scripts can easily work without any fancy modules. Martin > > Matthias >
