Date: Wed, 10 Apr 2019 21:36:25 +0000
Right, but wouldn't the build system would have set up a step to build the BMI for '<foo.h>' because foo.cpp has a dependency on the BMI of <foo.h>?
Why is the information required for this to work any different from if you had used #include of a header that contained an import-declaration?
I guess I am trying to understand why we need to generalize this to header units...
-- Gaby
| -----Original Message-----
| From: Ben Boeckel <ben.boeckel_at_kitware.com>
| Sent: Wednesday, April 10, 2019 1:14 PM
| To: Gabriel Dos Reis <gdr_at_[hidden]>
| Cc: modules_at_lists.isocpp.org; brad.king_at_kitware.com; WG21 Tooling Study
| Group SG15 <tooling_at_[hidden]>
| Subject: Re: [isocpp-modules] Dependency format with module details
| implementation
|
| On Wed, Apr 10, 2019 at 18:32:49 +0000, Gabriel Dos Reis wrote:
| > It is not clear to me why we would want to have this apply to header
| > unit. By the definitions, they are not modules. They don't have
| > names other than the name of the header or header file. They don't
| > provide anything other than their content as a whole. The only
| > dependencies they have are exactly the same that their headers or
| > header files have and therefore can be extracted via the usual
| > pre-processing scan. Why would their BMIs be required for
| > dependencies?
|
| I'm OK with this as well. However, GCC currently expects a BMI for
| header units during compilation:
|
| foo.h:
|
| const int foo = 0;
|
| foo.cpp:
|
| import <foo.h>;
|
| int main(int argc, char* argv[]) {
| return foo;
| }
|
| ```
| % g++ -fmodules-ts -std=c++2a -I. -o foo foo.cpp
| In module imported at foo.cpp:1:1:
| ./foo.h: error: failed to read module ‘!/foo.h.gchm’: No such file or directory
| ./foo.h: fatal error: jumping off the crazy train to crashville
| compilation terminated.
| ```
|
| Using `"foo.h"` instead:
|
| ```
| foo.cpp:1:8: internal compiler error: in module_state, at cp/module.cc:3221
| 1 | import "foo.h";
| | ^~~~~~~
| We are damaged, This is broken.
| Partial device,
| Pliable design,
| Hunt through the rubble for what once was.
| See
| <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgcc.
| gnu.org%2Fwiki%2Fcxx-
| modules%23Bugs&data=02%7C01%7Cgdr%40microsoft.com%7C5cb436
| 4f8fe749470ba108d6bdf11f38%7C72f988bf86f141af91ab2d7cd011db47%7C1
| %7C0%7C636905240721176468&sdata=gZXBSOZfqK9b%2FXFX8OnJkWvv
| Yg%2FWHe9lpsGISkweboY%3D&reserved=0> for instructions.
| ```
|
| --Ben
Why is the information required for this to work any different from if you had used #include of a header that contained an import-declaration?
I guess I am trying to understand why we need to generalize this to header units...
-- Gaby
| -----Original Message-----
| From: Ben Boeckel <ben.boeckel_at_kitware.com>
| Sent: Wednesday, April 10, 2019 1:14 PM
| To: Gabriel Dos Reis <gdr_at_[hidden]>
| Cc: modules_at_lists.isocpp.org; brad.king_at_kitware.com; WG21 Tooling Study
| Group SG15 <tooling_at_[hidden]>
| Subject: Re: [isocpp-modules] Dependency format with module details
| implementation
|
| On Wed, Apr 10, 2019 at 18:32:49 +0000, Gabriel Dos Reis wrote:
| > It is not clear to me why we would want to have this apply to header
| > unit. By the definitions, they are not modules. They don't have
| > names other than the name of the header or header file. They don't
| > provide anything other than their content as a whole. The only
| > dependencies they have are exactly the same that their headers or
| > header files have and therefore can be extracted via the usual
| > pre-processing scan. Why would their BMIs be required for
| > dependencies?
|
| I'm OK with this as well. However, GCC currently expects a BMI for
| header units during compilation:
|
| foo.h:
|
| const int foo = 0;
|
| foo.cpp:
|
| import <foo.h>;
|
| int main(int argc, char* argv[]) {
| return foo;
| }
|
| ```
| % g++ -fmodules-ts -std=c++2a -I. -o foo foo.cpp
| In module imported at foo.cpp:1:1:
| ./foo.h: error: failed to read module ‘!/foo.h.gchm’: No such file or directory
| ./foo.h: fatal error: jumping off the crazy train to crashville
| compilation terminated.
| ```
|
| Using `"foo.h"` instead:
|
| ```
| foo.cpp:1:8: internal compiler error: in module_state, at cp/module.cc:3221
| 1 | import "foo.h";
| | ^~~~~~~
| We are damaged, This is broken.
| Partial device,
| Pliable design,
| Hunt through the rubble for what once was.
| See
| <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgcc.
| gnu.org%2Fwiki%2Fcxx-
| modules%23Bugs&data=02%7C01%7Cgdr%40microsoft.com%7C5cb436
| 4f8fe749470ba108d6bdf11f38%7C72f988bf86f141af91ab2d7cd011db47%7C1
| %7C0%7C636905240721176468&sdata=gZXBSOZfqK9b%2FXFX8OnJkWvv
| Yg%2FWHe9lpsGISkweboY%3D&reserved=0> for instructions.
| ```
|
| --Ben
Received on 2019-04-10 23:36:29