[cfe-dev] [DISCUSSION] - modularize - module map generation (repost from cfe-commits)

[Thompson, John]

Thanks for the feedback, Doug.

-John

From: Douglas Gregor [mailto:dgregor at apple.com]
Sent: Friday, September 27, 2013 12:01 PM
To: Thompson, John
Cc: cfe-dev at cs.uiuc.edu
Subject: Re: [DISCUSSION] - modularize - module map generation (repost from cfe-commits)

Hi John,

On Sep 17, 2013, at 1:53 PM, Thompson, John <John_Thompson at playstation.sony.com<mailto:John_Thompson at playstation.sony.com>> wrote:


(I originally posted this on cfe-commits, but I learned cfe-dev would be more appropriate.)

Hi,

The page for modules (http://clang.llvm.org/docs/Modules.html#future-directions) mentions in the future directions section enhancing modularize with an assistant mode for generating a module.map file.  I'm starting to think about that, so before I plow ahead and possibly do something wrong, I wanted to open up a discussion for ideas and feedback, particularly since modules are new, and I might not have the correct understanding about them yet.

First off, do you think having modularize optionally generate a module.map file is even warranted?  If it is, how close can we get to producing a useable module.map file?  But perhaps the idea is just to create a starting point, to save some typing, since we would already have a list of header files.  I'll proceed along those lines.

I imagine it will only be a starting point, but simply enumerating all of the header files that get pulled in would be helpful.


Basically, as a starting point, I assume the header file name list is the basis for the headers included in the modules, except that these headers can still include other headers via #include, and are not listed because they are either internal, or they are part of a group but not independent and should not result in a separate submodule.

Then at this point, that raises the question of how you figure out the module/submodule hierarchy.

The simplest scheme is that all the files in the header file list pertain to just one outer module, named by a command-line option.  For example, "-root=std" would define one outer module called "std" and each header in the header file list would be a submodule inside "std".

The header file list might have headers that are in subdirectories.  Perhaps a modification of the above scheme could be that a submodule is created for the subdirectory name, and the headers in the subdirectory go inside that module, becoming sub-sub-modules and so on.

This would be my suggestion. Assume that the directory structure implies a module structure, and go from there. I know I've seen a number of libraries where this heuristic would be a good start.


As an alternative, perhaps namespace blocks could be used to determine modules.  The outermost namespace determines the root module, and nested namespaces become the submodule hierarchy.

This is potentially interesting, but I suspect it won't help as much. At least, not in the namespacing structures I've seen.

            - Doug

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20131001/42975d77/attachment.html>