705550 - libtool-based projects fail to build/link when DXR is in use

Status: RESOLVED FIXED

(Webtools Graveyard :: DXR, defect)

Description

[Kristian Rietveld]

Attachment: Proposed patch to use a cc.sh wrapper script to hide Xclang flags

When DXR is used to index a libtool-based project, these projects fail to link during the build. This happens because libtool does not like the "-Xclang -load" flags, which are used to invoke the DXR Clang plugin. One could argue that libtool should be fixed instead, but this might refrain many users from using DXR in the short term and problems can also pop up with other tools.

Taras Glek came up with the idea of hiding the special Clang flags to invoke the DXR plugin by putting these in a cc.sh wrapper script. cc.sh is then set as the compiler in the CC and CXX environment variables and will take care of launching a specified compiler with a specified SRCDIR.

One of the drawbacks of this approach could be that the many invocations of the shell needed to execute this script increases the build time. Especially if the cc.sh wrapper script is not required for projects such as Mozilla, this is an unnecessary increase in build time.

I will attach a patch which implements such a cc.sh wrapper script. I can confirm that with this patch glib (a libtool-based project) builds perfectly fine.

I am open for discussion of other ways to fix this problem. IMHO it is an important issue to fix to get other projects to deploy DXR.

Comment 1

[(no longer active)]

Comment on attachment 577141 [details] [diff] [review]
Proposed patch to use a cc.sh wrapper script to hide Xclang flags

Review of attachment 577141 [details] [diff] [review]:
-----------------------------------------------------------------

r=me

Comment 2

[Kristian Rietveld]

I've understood that this patch has not made it into the repository yet.  Personally, I am still quite concerned about a possible performance regression, as I've indicated in the opening comment.

I was wondering whether we should do a little performance testing with and without this patch before committing it to the repository. For example, for mozilla builds this patch is not even required and it would be quite stupid to get a 30% increase in build time after committing this patch, even though it is not even used in that particular case.

What do people think about this?  Do people care about the build times for their mozilla trees?

Comment 3

[(no longer active)]

Yes, build times are extremely important to us!

Comment 4

[Lionel Dricot]

This is fixed on dxr.lanedo.com