"Joseph S. Myers" <jos...@codesourcery.com> writes: > On Sat, 23 Oct 2010, Ian Lance Taylor wrote: > >> affect other languages. The only thing I hope to clean up further >> before the merge is additional separation between the Go frontend proper >> and the gcc-specific interface. I'm not going to have time to do the >> full planned separation, which I will continue to work on, but I hope to >> have the proper framework in place for future work. > > Will the front end use its own text domain for i18n of messages, or the > "gcc" domain? Whatever the answer, do you need changes to po/exgettext or > similar to cause all the messages to be properly extracted?
Good questions but I simply don't know. If anybody has any advice I would be happy to hear it. The current Go frontend source code marks text strings which require localization just as gcc code does: with _(), except when directly calling error or similar functions. I suppose my inclination is to simply continue doing that, and leaving the details of localization out of the frontend. In which case the front end will not use its own text domain for internationalization. It seems to me that this is a decision which can be changed later with only mild stress. Looking at po/exgettext, a script whose existence I had not previously suspected, it appears that it will need some minor changes to look at C++ files. I will tackle that at some point after the merge. >> There are three new source code directories: gcc/go, libgo, and elfcpp. >> The last is currently part of the src repository, where it is used by >> gold. I propose moving the master copy of elfcpp to gcc, and handling >> it like libiberty. > > How is elfcpp used? Is this front end in some way restricted to ELF > targets, or more functional with them? (In general, to what extent are > the front end and library portable to different targets - how much work, > if any, is needed to get them building and working for a new target > (architecture or OS)? Would the sort of target changes needed be risky > for Stage 3? What about host portability?) The simple_object work I committed this morning means that elfcpp is no longer required. The front end should be portable to new hosts and targets; I don't know of any issues there (well, I know of one minor issue with a Mach-O target which I intend to fix). The library is not too hard to port--it has been ported to RTEMS already, though I'm sure a Windows port would have some difficulties. The library does currently use the pthreads interface directly; I don't know how hard it would be to change to use gcc's gthread interface. >> The following other files are changed: > > You don't mention documentation. Does the front end have its own manual? > Whether or not it does, the new-front-end checklist (Front End in > sourcebuild.texi) lists places in the documentation that need updating for > a new front end (install.texi, contrib.texi, frontends.texi, > standards.texi, invoke.texi, sourcebuild.texi - plus web page etc. updates > for merging to trunk). Good point. I have not dealt with doc changes yet. >> gcc/opts.c >> gcc/toplev.c >> gcc/debug.h >> gcc/flag-types.h >> gcc/c-family/c-lex.c >> gcc/Makefile.in >> Add support for -ggo, used when building runtime library. > > Note that all -g* options are also handled in a case statement in > java/jvspec.c, though that might well better be handled through specs, and > I don't know if -ggo makes sense at all for Java. Thanks. I doubt -ggo would ever make sense for Java but that seems easy enough to handle. > I think appropriate coding standards documentation for this front end is > needed. Possibly in the form of a description of how the coding standards > differ from the general conventions for C++ in existing parts of GCC at > <http://gcc.gnu.org/wiki/CppConventions>, though those would need merging > into codingconventions.html before being used as a basis for conventions > actually used on GCC trunk. I think the conventions I used are the same as the ones in CppConventions, but, yes, point taken. > The front end's langhooks don't seem to have been updated for the > separation of the init_options and init_options_struct hooks. Thanks, will fix. > I presume you will be posting the front end and other changes for review > (or, I suppose, given the size of the changes, explicitly stating that you > propose for review the diffs between particular revisions of trunk and a > branch given by a particular svn diff command) as indicated in > <http://gcc.gnu.org/ml/gcc/2010-01/msg00504.html>. I will post all changes outside of the gcc/go and libgo directories for review, certainly. I would also appreciate review for the code in gcc/go and libgo on the branch. Whether review is required for that code is an interesting question. I have been assuming that I would become the initial maintainer for the gcc/go and libgo directories. As such, I would be permitted to make changes to those directories without review. So is review required for the initial checkin? I don't know. Ian
