[cfe-dev] [RFC] Embedding compilation database info in object files.

[David Blaikie]

On Fri, Jul 19, 2013 at 3:50 PM, Sean Silva <silvas at purdue.edu> wrote:
>
>
>
> On Fri, Jul 19, 2013 at 12:33 AM, Chandler Carruth <chandlerc at google.com>
> wrote:
>>
>>
>> On Thu, Jul 18, 2013 at 2:20 PM, Sean Silva <silvas at purdue.edu> wrote:
>>>>
>>>> So I'm not completely opposed to the idea. I'd be curious what Chandler
>>>> thinks, he usually happens to have strong opinions about things like this :)
>>>
>>>
>>> Yeah, I'd love to hear any ideas he has about this.
>>
>>
>> I'm summoned. =D
>>
>> So, I'm moderately opposed to the idea. The reason is that we've tried
>> this (as Manuel mentions) and it creates a really huge new problem: where do
>> you look for the object file. Worse, the *right* object file.
>>
>> The primary benefit of writing out to a single compilation database is
>> *precisely* that: it is a *single* compilation database. You can place it in
>> a common, predictable location and have clang-based tools look there. We had
>> huge, never-ending problems with this in practice. We would spend more time
>> looking for the .o file than we would running the clang tool, or we would
>> find the wrong .o file and end up not reproducing the compile developers
>> actually cared about.
>
>
> Perhaps the commandline flag that enables emitting this information could
> also accept a unique ID to embed along with the information, which would
> allow you to easily decide which files correspond to which build. Would that
> address these issues you cite? If not, could you elaborate?
>
>>
>>
>> Even if you build aggregate databases as you say for "final build
>> products", I agree with Manuel: this just moves the problem. Now you need to
>> know which build product to look into.
>
>
> I think that "Moving the problem" is actually an important part of this
> proposal. The primary issue in my eyes is getting information from A to B,
> where
>
> A = a place that knows what information should be in the compilation
> database
> B = somewhere that a tool can access the compilation database.
>
> I can think of two places that qualify for A: 1) The build system and 2) the
> the compiler itself. Changing the build system (either the build program
> itself, or even the "project files") is a non-starter in my environment. So
> that leaves us with using A=the compiler itself (I'm open to other values of
> A, but at the moment these two are the only ones I can think of). Now, the
> question is how do you transport the information to somewhere the tool can
> access it.
>
> Basically by definition, a build system allows access to build products, and
> so without any additional assumption, build products are a viable option for
> transporting the information in all build systems. The constraint of not
> modifying existing build configurations leads to the conclusion that these
> build products that we use for transport must be *existing* build products.
>
> Simply embedding this information in build products doesn't get us all the
> way from A to B. However, "Moving the problem" to be "given a set of build
> products known to contain all the compilation database information for a
> project, extract a compilation database" is I think a useful simplification
> of the problem "given an arbitrary C/C++ project, extract a compilation
> database". Would you agree?

But that's not where you've moved the problem, because you still have
the problem of "find the set of build products". If a build system
produces 3 binaries - there's no consistent/trivial/generic way to
discover those 3 binaries that I know of.

>
> -- Sean Silva
>
>>
>>
>> I genuinely think that having a common database is far and away the best
>> strategy for integrating tools into a development process. We should focus
>> on updating build systems to directly write out these databases. That tends
>> to be the most effective way to get the compilation database.
>
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>