set begin_exports/end_exports (or private) for files one cannot modify

[GoogleCodeExporter]

wiki says this:
If fix_includes has suggested a private header file (such as 
<bits/stl_vector.h>) instead of the proper public header file (<vector>), you 
can fix this by inserting a specially crafted comment near top of the private 
file (assuming you can write to it): '// IWYU pragma: private, include 
"the/public/file.h"'. 

However sometimes you cannot modify the private file. 
It would be nice if one could specify one way or another that a (system) header 
file is a facade and should not be further dissected.

E.g. one could specify in an identically named file (maybe with different 
extension) the IWYU options and a reference to the real file. (but there are 
also other possibilities).

alternate could be command line options or a config file indicating what files 
are facade file and should export all, and what files are private files

Original issue reported on code.google.com by fransmeu...@gmail.com on 9 Feb 2014 at 12:41

Attachments:

• iwyu.struct.tar.gz

[GoogleCodeExporter]

Have you seen https://code.google.com/p/include-what-you-use/wiki/IWYUMappings? 
The mapping files were intended to solve exactly this problem.

Original comment by kim.gras...@gmail.com on 9 Feb 2014 at 1:01

[GoogleCodeExporter]

Actually after raising the issue I indeed noticed the mapping file and played 
with it, but I could not really achieve what I wanted.
Not sure if the mapping file has preference above internal mappings
Also I could not find how to define a mapping for export (also not in the wiki)

This seems to be closest, but I could not get it to work:
 { include: ["<bits/unique_ptr.h>", "private", "<memory>", "public"] }
Also in this example I was not sure how to deal with header files that used " " 
instead of < >

Original comment by fransmeu...@gmail.com on 10 Feb 2014 at 2:46

[GoogleCodeExporter]

The mapping files are applied on top of the internal mappings (unless you also 
specify -Xiwyu --no_default_mappings, in which case the internal mappings are 
pruned.)

Unfortunately there is no external syntax for export. Sometimes it can be 
achieved with a mapping, but not always (e.g. selective export). Maybe we 
should look into a syntax for describing exports as well.

In mapping files, escape quotes with \, so something like:

  { include: ["\"foo.h\"", "private", "\"bar.h\"", "public"] }

Please post back with more concrete details and maybe we can figure something 
out.

Original comment by kim.gras...@gmail.com on 10 Feb 2014 at 7:27

[GoogleCodeExporter]

Ah, ok, thanks for the suggestion wrt the \"
Actually ideally (at least in a C world) one probably does not want to treat 
quotes and angled brackets much differently. 
I for me, I prefer angled brackets where possible. It is a little bit faster as 
the compiler does not need to search in the current dir.

The concrete issue I am facing is:
We have code that needs to work on windows as well as linux, and at some point 
it was decided to create a file platform.h as a facade to hide some os specific 
includes. So basically platform.h has an #ifdef/#else/#endif  with some 
#includes in it.

I could add pragma's to the file, but I would prefer not to touch the file and 
instead specify it in a mapping file (also as we have a few of those facade 
files for different purposes).

Original comment by fransmeu...@gmail.com on 12 Feb 2014 at 8:07

[GoogleCodeExporter]

Yes, I'm also a little suspicious wrt angled vs quoted includes, I don't really 
understand why they've been given such significance in IWYU.

Would it work if you added a mapping file to map all detail haeders to 
platform.h?

Original comment by kim.gras...@gmail.com on 12 Feb 2014 at 8:15

[GoogleCodeExporter]

I think that would indeed help. 
(not sure if the project review will accept annotations in the project facade 
files).
For now I created a small script that adds begin-exports and end-exports around 
the facade files locally.

Original comment by fransmeu...@gmail.com on 12 Feb 2014 at 8:23