This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] Adding Python as a possible language and it's usage
- From: Matthias Klose <doko at debian dot org>
- To: Karsten Merker <merker at debian dot org>, gcc at gcc dot gnu dot org
- Date: Fri, 20 Jul 2018 12:01:03 +0200
- Subject: Re: [RFC] Adding Python as a possible language and it's usage
- References: <20180719202030.7ejto32zyg5vdwoq@excalibur.cnev.de>
On 19.07.2018 22:20, Karsten Merker wrote:
> David Malcolm wrote:
>> On Tue, 2018-07-17 at 14:49 +0200, Martin Liška wrote:
>>> I've recently touched AWK option generate machinery and it's
>>> quite unpleasant to make any adjustments. My question is
>>> simple: can we starting using a scripting language like Python
>>> and replace usage of the AWK scripts? It's probably question
>>> for Steering committee, but I would like to see feedback from
>>> community.
>>
>> As you know, I'm a fan of Python. As I noted elsewhere in this
>> thread, one issue is Python 2 vs Python 3 (and minimum
>> versions). Within Python 2.*, Python 2.6 onwards is broadly
>> compatible with Python 3.*, and there's a well-known common
>> subset that works in both languages.
>>
>> To what extent would this complicate bootstrap? (I don't think
>> so, in that it would appear to be just an external build-time
>> dependency on the build machine).
>>
>> Would this make it harder for people to build GCC? It's one
>> more dependency, but CPython is widely available and relatively
>> easy to build. (I don't have experience of doing bring-up of a
>> new architecture, though).
>
> Hello,
>
> I have recently been working on bringing up a new Debian port for
> the riscv64 architecture from scratch, so I would like to add
> some of my personal experiences here.
>
> Adding a dependency on python for building gcc would make life
> for distribution porters quite a bit harder. There are a bunch
> of packages that are more or less essential for a modern Linux
> distribution but at the same time extremely difficult to properly
> cross-build. For a distribution porter trying to bootstrap a new
> architecture, this means that one has to resort to native
> building sooner or later, i.e. one has to build native toolchain
> packages and then work forward from there. During the bootstrap
> process it is often necessary to break dependency cycles and
> natively rebuild toolchain packages with different build-profiles
> enabled, or to build newer versions of the same toolchain packages
> with bugfixes for the new architecture.
>
> A dependency on python would mean that to be able to do a native
> rebuild of the toolchain one would need a native python. The
> problem here is that python has an enormous number of transitive
> build-dependencies and not all of them are easily cross-buildable,
> i.e. one needs a native compiler to build some of them in a
> bootstrap scenario. This can lead to a catch-22-style situation
> where one would need a native python package and its dependencies
> for natively building the gcc package and a native gcc package
> for building (some of) the dependencies of the python package.
>
> With awk we don't have this problem as in contrast to python awk
> doesn't pull in any dependencies that aren't required by gcc
> anyway. From a distro porter's point of view I would therefore
> appreciate very much if it would be possible to avoid adding a
> python dependency to the gcc build process.
I don't see that as an issue. As said in another reply in this thread, you can
do a staged python build, which has the same build dependencies as awk (maybe
except the db/gdvm module). And if you need to, you can cross build python as
well more easily than for example perl or guile.
Matthias