[Tooling] [ Modules and Tools ] Tracking Random Dependency Information
JeanHeyd Meneide
phdofthehouse at gmail.com
Wed Dec 19 09:38:54 CET 2018
Peter:
On Wed, Dec 19, 2018 at 2:49 AM Peter Bindels <dascandy at gmail.com> wrote:
> This is putting the cart behind the horse. How do you invoke the compiler
> without knowing the dependency information? How do you read a code base if
> the actual files found depend on your include paths? Wasn't this part of
> the original problem - having code that does what you write down & intend,
> rather than depend on context for meaning?
>
> I do not believe that doing full semantic analysis for dependency analysis
> is even an option. That would equally imply that to compile the source code
> you need to have fully compiled it - how do you ever begin?
>
It requires out-of-band information, period. The paper doesn't change
that. Someone still needs to specify a Resource Path for std::embed (or
anything else related to resources) to work. Similarly, someone must also
specify Include Paths in order to do the first build. Either that, or you
come to an agreement with your build tool that you will obey a specific
layout, and the build tool will work with that assumption so it can get
through a first pass over your code. Neither of these change that the
information is outside of the specification of your include statements.
Modules do not map directly to any file system schema, nor any
namespace schema. It's all wild wild west, so again you need out-of-band
information in order to coordinate anything. I haven't made the situation
any better, or worse, but if the cost of doing full semantic analysis is
cheap enough to use then I'd want that to be the case. I have no indication
from any implementers that that is desirable.
Colby:
That sounds fairly correct, though as of right now I do not know how
to, e.g., export such information post-compilation for any build system to
pick up. What compiler flags make visible post-compilation dependency
information? From reading ninja documentation, I only see that they use
/showIncludes for VC++ and -MMD-style Makefile-like depfile reading.
Neither of these perform full semantic analysis to help get the build
system going (they do preprocessing + a few other steps, but never semantic
analysis), so I'm curious where I would find this information?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.open-std.org/pipermail/tooling/attachments/20181219/bfa59595/attachment.html
More information about the Tooling
mailing list