On Thu, Mar 22, 2012 at 1:03 AM, Basile Starynkevitch <bas...@starynkevitch.net> wrote: > On Wed, Mar 21, 2012 at 10:57:08AM +0100, Richard Guenther wrote: >> >> Indeed. There is also different module hierarchies that overlap. For >> example ILs used in the different parts of the compiler. >> >> I think Basile is mostly confused about what files belong to what module, >> a question with not a single answer per file. It's been suggested before, > > > Sorry people, we don't have any established list of named modules. I see > nowhere a list of one or two dozens of modules with for each of them: > > * a name > > * short description in one or two sentences > > * the entire set of files or directories implementing that module > > * the API of that module (perhaps as a public header file, with the strong > requirement that internal functions should be declared in a private header > file) >
We have more than two dozen. http://gcc.gnu.org/onlinedocs/gccint.pdf again every header and dot point in section 9 would be a module. Then there is the supporting bits to those modules.like the IL's and the runtime. Section 9 is basically the abridged overview. So there will be a lot more modules than what is listed. Yes what you describing is a clean up of gccint documentation to be more readable and practical. Also you are describing the chopping process. Yes we do have a list of what is what in documentation. Is is currently really nice to use no its not. Its it fully detailed as it should be no its not. Is the problem huge yes it is. Breaking into modules gcc will have a more complex layout than gnome does. Due to the way thing interact. Most likely will not fit well into a 2d graphic. Most likely will fit well into a 3d graphic. So yes gccint is the starting block. Some are nicely described with what functions own to the module some are not. Imports and exports are not well declared. It is going to have to be a piece by peice prcoess Peter Dolding
