Hi! Congratulations, José, and small but growing team!
Thanks, GCC Steering Committee for allowing this team (and the GCC community at large!) to prove valid the points that Martin Uecker very well formulated (and similarly seconded by other GCC developers), in <https://inbox.sourceware.org/[email protected]> "Re: [SC] Contributing the Algol 68 Front-End to GCC"! As for the two questions -- I'm not a Global Maintainer, but: On 2025-11-22T20:16:30-0500, David Edelsohn via Gcc <[email protected]> wrote: > On Sat, Nov 22, 2025 at 7:11 PM Jose E. Marchesi <[email protected]> > wrote: >> > 1. Algol 68 is not part of all languages built by default. >> >> - We interpret the first stipulation as not building the algol68 >> front-end when --enable-language=all is specified. Is this correct? That's not my understanding -- 'all' is fine, just not 'default': > Algol 68 should not be part of the default bootstrap languages. You can > refine that with the Global Maintainers. We have, per 'gcc/doc/install.texi': @item --enable-languages=@var{lang1},@var{lang2},@dots{} [...] Currently, you can use any of the following: @code{all}, @code{default}, @code{ada}, @code{c}, @code{c++}, @code{cobol}, @code{d}, @code{fortran}, @code{go}, @code{jit}, @code{lto}, @code{m2}, @code{objc}, @code{obj-c++}. [...] If you do not pass this flag, or specify the option @code{default}, then the default languages available in the @file{gcc} sub-tree will be configured. Ada, COBOL, D, Go, Jit, Objective-C++ and Modula-2 are not default languages. LTO is not a default language, but is built by default because @option{--enable-lto} is enabled by default. The other languages are default languages. If @code{all} is specified, then all available languages are built. An exception is @code{jit} language, which requires @option{--enable-host-shared} to be included with @code{all}. So, in my understanding, the Algol 68 front end (and related infrastructure) is part of '--enable-languages=all', but is not part of '--enable-languages=default' (or that option omitted). That makes sense to me. >> - Once the previous point is clarified, should we push the patch series >> as submitted to gcc-patches, even if they are not bisectable, or is it >> preferred to squash the patches into a single big commit? > > Please coordinate with the Global Maintainers on how they wish the patch > to be committed. In the end, it won't matter too much, but if you have reasons to have individual commits instead of one big one (for example, for more specific attribution of additional contributors via 'Co-authored-by: [...]'), you may make it so that you add the 'config-lang.in' file only as the very last commit: that file is what makes a front end known to the GCC build machinery, without that file, everyhing you do in 'gcc/algol68/' in earlier commits won't have any effect. (This is also what GCC/Rust has done, back then, upon my suggestion.) Grüße Thomas >> > The GCC Steering Committee has agreed to include the Algol 68 Front End in >> > trunk designated as experimental with stipulations: >> > >> > 1. Algol 68 is not part of all languages built by default. >> > 2. Algol 68 is not part of the GCC release criteria. >> > 3. All GCC developers who are not responsible for the Algol 68 Front End >> > may decline to work on issues related to the Algol 68 Front End. >> > 4. If the Algol 68 Front End bit rots or is not maintained, it will be >> > removed. >> > >> > To permit Algol 68 development to continue, Jose E. Marchesi is appointed >> > as Algol 68 front end maintainer. >> > >> > If maintaining a Front End outside of trunk is difficult, the Algol 68 >> > developers are invited to propose concrete changes to make it easier to >> > maintain front ends in a branch of the GCC repository outside of trunk. >> > >> > Happy Hacking! >> > David
