Adding anything huge is always hard in GCC because there are very very few people that can review patches, and those people are the same that do 99% of the work, so they are already saturated. The best way to add things to GCC is: 1) Find who can approve your patch. In your case, it is probably gerald@xxxxxxxxxxx and/or joseph@xxxxxxxxxxxxxxxx, but Joseph is incredibly busy lately with libc, so perhaps C++ maintainers would be willing to review. 2) Ask them directly how they will prefer patches (small long series of patches or larger patch) 3) Try to get the patches as right as possible from the start following GCC conventions (look at other docs). 4) Ping, ping, ping and keep pinging (CCing the maintainers) once every two weeks until the patches are reviewed. As an alternative, you could put your doc (and texi sources) somewhere (github, a svn branch in gcc.gnu.org) and add a link to it here: http://gcc.gnu.org/wiki/WritingANewFrontEnd or even better, completely take over that page if you think your documentation covers most of the stuff there that is not outdated. Cheers, Manuel. On 1 July 2013 11:14, Philip Herron <redbrain@xxxxxxxxxxx> wrote: > Yeah there is a patch in the list somewhere from ages ago where me and > Andi Hellmund added huge front-end documentation but it never got > reviewed. > > I think i need to resurrect this again this week and fix it up and get it in. > > --Phil > > On 30 June 2013 22:51, Manuel López-Ibáñez <lopezibanez@xxxxxxxxx> wrote: >> Perhaps it should be documented somewhere, but where? To be honest, if >> I had to implement a GCC FE, I wouldn't even know where to start >> looking. >> >> BTW, don't look to Fortran for a good example of how to handle >> options. Fortran duplicates the common machinery, which does a lot >> more than the Fortran implementation. The same applies to diagnostics, >> don't follow Fortran, use the common machinery. In general, the C++ FE >> is probably the most modern and the best example to look at. >> >> >> >> On 30 June 2013 22:17, Philip Herron <redbrain@xxxxxxxxxxx> wrote: >>> Thanks so much i just never noticed this lang hook just needed to >>> return the option_lang_mask and now its all fine. >>> >>> Thanks >>> >>> --Phil >>> >>> On 28 June 2013 19:46, Manuel López-Ibáñez <lopezibanez@xxxxxxxxx> wrote: >>>>> I have been having trouble with my lang.opts i keep getting: >>>>> >>>>> hilips-MacBook:gccpy-build redbrain$ gccpy -O0 -fdump-tree-gimple t.py >>>>> -o t.o -fpy-dump-dot -fpy-gen-main >>>>> gpy1: warning: command line option =91-fpy-dump-dot=92 is valid for Python >>>>> but not for [enabled by default] >>>>> gpy1: warning: command line option =91-fpy-gen-main=92 is valid for Python >>>>> but not for [enabled by default] >>>>> gpy1: warning: command line option >>>>> =91-L/usr/local/lib/gcc/x86_64-apple-darwin12.3.0/4.8.0=92 is valid for >>>>> Go/Python but not for [enabled by default] >>>>> gpy1: warning: command line option >>>>> =91-L/usr/local/lib/gcc/x86_64-apple-darwin12.3.0/4.8.0/../../..=92 is >>>>> valid for Go/Python but not for [enabled by default] >>>> >>>> Does your python_handle_option returns true for recognized options? >>>> >>>> When you build, in the build/gcc/ directory there is an options.c >>>> file. Does it mention Python in lang_names? Do the options have the >>>> CL_Python flag? >>>> >>>> Have you defined a hook that returns the lang_mask for Python? See Fortran: >>>> >>>> fortran/f95-lang.c:#define LANG_HOOKS_OPTION_LANG_MASK gfc_option_lang_mask >>>> >>>> BTW, you don't need to re-define Common options unless you want to >>>> completely change their meaning, which normally is a bad idea. >>>> Normally you can just re-use the results returned by the common >>>> options machinery for your own purposes. >>>> >>>> Cheers, >>>> >>>> Manuel.
