ilya-biryukov wrote: > Can you clarify, are you saying this pattern of having a header in two > different modules has to keep working indefinitely, or are you willing to > migrate off of it? > I don't understand what the reason is for the header to be in two different > modules in the first place. It sounds like it is somehow related to a build > optimization, but what exactly is that?
Our whole build infrastructure relies on producing those module maps. In Bazel (and its internal equivalent), you can have multiple targets (`cc_library`) that own the same header. Bazel generates a module map for each of the `cc_library` like this: - each file in `hdrs` becomes a `header` (can be modular or `textual`, depending on the target, e.g. all protos produce modular targets, we can also make some targets modular), - each **header** file in `srcs` becomes a **private** header. - `.inc` files and `textual_hdrs` become `textual headers`. Things are a little more complicated on top of that, we actually have a submodule per header in each module matching a target. And we also rely on `-fmodule-strict-decluse` to make sure we never have any headers that are not covered by module maps. That way we enforce the structure from our BUILD rules: headers are only allowed to include headers from their direct dependencies and only the non-private ones. I believe the way access checking of headers is done today, Clang allows us to have a dependency on a header that you **could** get through a module that has it publicly available, even if it ends up picking a module where the header was actually private. In turn, this allows us to add optimization by limiting the number of header and modules we need to ship to distributed build for each of the compile actions. I know there are many details missing from this explanation, but I hope this gives a start. Changing how our build is done within all of Google is obviously hard. I understand that having multiple modules for a header may not be something others care about, but we need it and are willing to put the work to make it work too. Does that explanation help to clarify our use case or do folks still have questions? > Do you include proto headers directly or through the wrapper headers? Directly. > Are there any important macros in proto headers? I don't think there are. I am not sure why it's important. > Do you need to abuse macros to get something out of proto headers? Kinda like > `#define private public` but more realistic. > > My initial reaction is to offer a solution by not using private headers > (especially that it is so easily subverted by textual headers) and to rely on > `-fmodules-embed-all-files` (which you already do). I believe you have > constraints that make this "simple" solution not feasible. So I'm curious to > know what about this solution doesn't work. As mentioned above, we rely on private headers to check we do not accidentally include a header in `srcs` from a file that's not part of the same target (caveat: unless there's some other target we depend on exposing the same header as non-private). > Do you realize you can ask for a different deadline? If you don't tell how > much time you need, you get an external deadline imposed on you. I find exchanges like this non-respectful and non-considerate. Please give us some benefit of a doubt, we are trying to explain our use-case and we are happy to put in the work to make both our cases work. > What makes you think that no discussion is possible? For the record, "we need > this to work, you must make it work" is not a discussion. Could you directly quote something in my writing that you interpreted like this? I definitely did not mean this to come across as a demand. On the contrary, I have interpreted the xkcd link and some of the replies as hostile and snarky. I would like to move away from that style and find a productive way forward here. https://github.com/llvm/llvm-project/pull/138227 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
