On Sat, May 10, 2025 at 3:43 AM Richard Purdie <richard.pur...@linuxfoundation.org> wrote: > > On Fri, 2025-05-09 at 17:45 -0400, Nikolaos Chatzikonstantinou wrote: > > I rewrote GNU m4 in Python. Long story short, I wanted to learn m4 to > > fix some issues I had with GNU Guile and Autotools, and after > > realizing m4 1.4 is ~8000 lines of code and reading e.g. > > <https://www.owlfolio.org/development/autoconf-swot/> which claims > > "Feature gaps in GNU M4 hold back development of Autoconf." I thought > > I'd rewrite it in Rust. (It turned out to be more beneficial to > > rewrite in Python due to faster prototyping for the time being.) > > Eventually I plan to get back to my original purpose of fixing the > > integration of GNU Guile and Autotools. > > > > You can find the project home page here, > > <https://codeberg.org/annoyingusername/m4p> and you can install with > > pip via `pip install m4p`. > > > > I'm hoping that this is a welcome addition. I'm interested to hear if > > m4p works as a GNU m4 replacement for you, and any issues that arise. > > FWIW, OpenEmbedded/Yocto Project knows how to cross compile a large > chunk of open source software and build functional images from source. > It runs autoreconf on most of the software so if you wanted to test > this against a large pool of software, it would allow that. > > I'd be curious on the speed comparison if you do as autoreconf spends > most of it's time in m4.
This is a good idea, I will try this and will post results here. At this point (v0.3) I've implemented all macros, the only missing functionality is how m4p treats the debug level, so perhaps it's time to do this. Regards, Nikolaos Chatzikonstantinou
