On 2/1/19 10:07 AM, Matthew Woehlke wrote:
> On 31/01/2019 17.58, Ben Craig wrote:
>> Your IDEs and tidying tools and anything else that needs to consume
>> and understand your source without building it will care. If you
>> want types and values to have different colors in your IDE, then your
>> IDE needs to be able to get from your file to the source file that
>> declared those entities.
> (That said, it seems to increasingly be the case that the way they do
> this is by... querying the build system and using the compiler to parse
> your sources. At least, the IDE's that work *well* do it this way...)

I don't think that is a correct generalization. For some IDEs, there is
some integration with specific build systems and compilers. For
example, my understanding is that Xcode features that depend on semantic
analysis (e.g., code completion) will not function in a modules enabled
code base unless 1) the code is actually built by Xcode; e.g., built via
an Xcode project, 2) is built with Clang, and 3) is built with a version
of Clang that matches the version of Clang built into the Xcode indexing
services (so that modules built by the build can be consumed by the
indexing service; I'm not sure about this point, it may be that Xcode
can re-generate its own builds of such modules if they are not
compatible, but of course that can fail if the code requires specific
Clang versions). I believe the situation is similar for Visual Studio;
it will consume BMIs produced by the Microsoft compiler, but will have
some manual configuration options for resolving module imports to source
code as well. I think there is risk of vendor feature lock-in with
these approaches that require IDE/tool <-> build system
interaction/dependencies.

Tom.