On Wed, 13 Nov 2013, Gaius Mulley wrote: > >> In general, for GCC development to consider requirements of your front end > >> or back end, getting it into the GCC repository and developing it there is > >> strongly recommended. > > Sadly, I tried multiple times in the late 90s to bring the folks going > > GNU Pascal development into the GCC project without any > > success. Eventually I have up. > > I'd be delighted to see gm2 in the gcc repository. The gm2 repository > is currently in git format (changed from cvs 2 weeks ago). All fsf > copyright assignment forms have been done some years ago.
Personally I'd welcome addition of front ends for any mainstream languages (of the sort that are suited to ahead-of-time compilation to machine code as in GCC) where there are developers interested in maintaining them in GCC following the usual GCC coding standards and development practices. (sourcebuild.texi, "Front End", provides a checklist so you don't have anything obviously missing, but of course there's lots more involved in following what are currently considered good coding practices in GCC - some things existing front ends do may not now be considered good practice for new front ends.) This doesn't say whether a new front end would be built by default (though my personal view is that --enable-languages=all should mean all languages supported for the given target with the available build tools, and should be the default, but the expectations for routine patch testing could be something less). Of course, if a front end then ceases to be maintained it may get removed, as the CHILL front end was removed. > >From reading http://gnu.gcc.org/wiki/SvnBranch I wonder whether it would > seem sensible to create two branches one at 4.7.3 and another at branch > at the head (maybe) and mercilessly merge from the head. Maybe one > of the earlier activities should be to forward port the 10 patches and > post them to the appropriate mailing list? Any patches that aren't simply filling in checklist items for a new front end certainly need posting separately with their own rationale (for example, if there's an optimizer bug fix for a bug the front end shows up). If the patch only makes sense with the new front end, but isn't simply checklist-filling, it's probably best posted at the same time as the front end itself, but as a separate patch in the series (for example, if you want a new language-independent GIMPLE operation). I think it's reasonable to give SVN write access to anyone with a copyright assignment on file who is interested in maintaining a front end on a branch and hopefully contributing it to trunk in future. -- Joseph S. Myers jos...@codesourcery.com
