@@ -68,75 +68,6 @@ configuration options:
68
68
69
69
Read more about :ref: `options `.
70
70
71
- Preprocessing
72
- -------------
73
-
74
- By default, maud uses a custom module scanner which ignores preprocessing
75
- for efficiency and stops reading source files after the import declarations.
76
- This works in the most common case where the preprocessor only encounters
77
- ``#include `` directives and an occasional ``#define ``, which leaves
78
- the module dependency graph unaffected. However it is possible for the
79
- preprocessor to affect module and import declarations. For example:
80
-
81
- - an import declaration could be inside a conditional preprocessing block
82
-
83
- .. code-block :: cpp
84
-
85
- module foo;
86
- #if BAR_VERSION >= 3
87
- import bar;
88
- #endif
89
-
90
- - a set of import declarations could be included
91
-
92
- .. code-block :: cpp
93
-
94
- module foo;
95
- #include "common_imports.hxx"
96
-
97
- - a macro could expand to a pragma directive which modifies an ``#include ``
98
-
99
- .. code-block :: cpp
100
-
101
- module;
102
- #include "macros.hxx"
103
- PUSH_INGORED_WARNING(-Wunused-variable);
104
- #include "dodgy.hxx"
105
- POP_INGORED_WARNING();
106
- module foo;
107
-
108
- - a macro could be used to derive the name of the module
109
-
110
- .. code-block :: cpp
111
-
112
- module;
113
- #include "macros.hxx"
114
- module PP_CAT(foo_, FOO_VERSION);
115
-
116
- (I'm actually not sure that the last two are even legal since a global
117
- module fragment should exclusively contain preprocessing directives
118
- :cxx20: `module.global.frag#1 `, however clang allows both.)
119
-
120
- IMHO, it is not desirable to write interface blocks which depend on preprocessing.
121
- Moreover C++26 will restrict usage of the preprocessor severely in module declarations
122
- as described in `P3034R1 <https://isocpp.org/files/papers/P3034R1.html >`_.
123
-
124
- .. _maud-preprocessing-scan-options :
125
-
126
- For source files which require it, the property ``MAUD_PREPROCESSING_SCAN_OPTIONS ``
127
- can be set in cmake. This property should contain all compile options
128
- necessary to correctly preprocess the source file, for example
129
- ``-I /home/i/foo/include -isystem /home/i/boost/include -DFOO_ENABLE_BAR=1 ``.
130
-
131
- Note that the output of these tools is in the JSON format described by `p1689
132
- <https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p1689r5.html> `_
133
- and does not distinguish between a module implementation unit of ``foo `` from a
134
- source file which happens to import ``foo ``. Without information about which module
135
- an implementation unit is associated with, it cannot be automatically added to
136
- the corresponding target. As a workaround if you must have a preprocessing scan
137
- of an implementation unit, you can split the implementation unit into partitions
138
- whose primary module is exposed.
139
-
140
71
Built-in support for generated files
141
72
------------------------------------
142
73
0 commit comments