A Proposal To Allow Python Scripting Within The GCC Compiler, Replacing AWK

[phoronix]

Phoronix: A Proposal To Allow Python Scripting Within The GCC Compiler, Replacing AWK

A SUSE developer is seeking feedback and interest on the possibility of allowing a scripting language -- most likely Python -- to be used within the GCC compiler code-base. This would primarily be used for replacing existing AWK scripts...

http://www.phoronix.com/scan.php?page=news_item&px=Python-GCC-Awk-Proposal

[Weasel]

The advantage of awk is that it's installed on virtually every Linux distro, has no shitty version incompatibility (python2 vs python3), and is lightweight. I'm not talking about the script itself, but the executable and runtime which will have to get loaded now (yeah some of us don't use python at all except when needed, in cases like this).

So I guess compiling GCC (and MinGW) will become more tedious with this dependency on a bloated scripting language, if you're used to do it from a container like me.

Hopefully it won't come to pass, but I'm no GCC dev so I doubt my word would have merit even if I did post in that thread. So I can only hope.

[carewolf]

The advantage of awk is that it's installed on virtually every Linux distro, has no shitty version incompatibility (python2 vs python3), and is lightweight. I'm not talking about the script itself, but the executable and runtime which will have to get loaded now (yeah some of us don't use python at all except when needed, in cases like this).
.

Well, perl and one version or another of python is too.

And weight of either binaries is bloody irrelevant if you building gcc yourself.

[fithisux]

Since GCC is a GNU project, why don't they go with GNU Guile? Too much effort has been invested. I tend to not understand GNU these days.

[Weasel]

Well, perl and one version or another of python is too.

And weight of either binaries is bloody irrelevant if you building gcc yourself.

Not if you compile in a throwaway container, which means pulling python as extra dependency. Obviously one extra dependency isn't so bad but you know, it keeps piling up, and the compilation isn't exactly fast or straightforward.

[cybertraveler]

I like the Python syntax, but I'm with Weasel. Python is a lot of bloat compared to awk.

I wonder if Lua would be more appropriate. It's lighter than Python.

It's a shame there isn't a stable and well supported Python interpreter out there which is lightweight and doesn't include all the libraries frameworks that Python has. Like a minimalistic and low complexity version of Python.

[NotMine999]

Is this request to move to some version of Python simply because Martin Liska is not making enough effort to learn the AWK language?

I browsed the GCC link and followed it to the Bugzilla case and a GCC webpage. GCC options scripts are apparently written in or generated by AWK and there is some thought about rewriting them in Python to generate C code. I saw an interesting comment from 2017 that I think is by Martin (difficult to tell from the formatting of the webpage) that makes me question his level of knowledge of AWK:

https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00469.html

The detection works fine for the Init problem (thanks!) but it doesn't catch the out-of-range initializer in LangEnabledBy(C, Wall, 2, 0) or in Alias(Wfoobar=, 1, 0). I don't know enough about the option scripts yet to gauge how difficult handling these might be. Do you have any idea?

Having worked in the AWK language a few decades ago on an original IBM PC (4.77 MHz, 640K RAM, IBM DOS, AWK ported to PC), and only having the small gray AWK book (written by the AWK language creators) to use as language documentation, I can certainly understand the steep learning curve and time it takes to learn how to do anything productive in AWK. The AWK language is quite powerful and even extensible to a certain degree for it's diminutive size.

I have not looked at any of the AWK usage in the GCC compiler source code, but I suspect it is much more complex than anything I ever wrote. Thus, I suspect the options scripts portion of GCC has a much steeper learning curve than most code, especially if the code maintainer/developer is more fluent in Python ("new school" programming skill, or, what is taught today) and not AWK ("old school" programming skill, or what is not likely taught today in school).

[kaprikawn]

The advantage of awk is that it's installed on virtually every Linux distro, has no shitty version incompatibility (python2 vs python3), and is lightweight.

This is a legitimate concern which I agree with entirely. But I work a lot in unixy scripting environments, and I can't get on with awk, I avoid it if at all possible. I tend to go with Perl because it's more supported at my workplace, but I can see how doing a regex in Python or whatever would be a lot easier to maintain.

I guess it just comes down to a cost-benefit analysis. Code maintainability is a laudable goal, and I imagine a lot of people are a lot more comfortable with Python than awk. And Python is becoming somewhat ubiquitous, so it's not a massive downside. So I suppose it depends just how much of a ballache those awk scripts are.

[cbxbiker61]

Python is probably the most natural fit for the typical things you want to do in managing a large project. I'm pretty sure they would limit their requirements to just Python without any addition modules. Installing Python by itself is not that big of a deal. It has all of the file management features that you could want, pretty much anything that is doable from within sh scripts.

Awk (there's a good video on YouTube about it's development) was pretty cool way back at the start of computer history, doing great things on 16K UNIX machines....but that was a long time ago and we've certainly moved on.

[gens]

Python is probably the most natural fit for the typical things you want to do in managing a large project.

That is a completely baseless statement.

"
Awk (there's a good video on YouTube about it's development) was pretty cool way back at the start of computer history, doing great things on 16K UNIX machines....but that was a long time ago and we've certainly moved on.
"

This is completely fallacious way of thinking about things.