Created attachment 577141 [details] [diff] [review] 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.
Attachment #577141 - Flags: review?(Pidgeot18) → review?(ehsan)
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
Attachment #577141 - Flags: review?(ehsan) → review+
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?
Yes, build times are extremely important to us!
This is fixed on dxr.lanedo.com
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.