Re: Issue with ede-ninja-project and CMake
Alastair Rankine <[email protected]> Sun, 1 Nov 2015 15:25:29 -0500
| Newsgroups | gmane.emacs.cedet |
|---|---|
| Message-ID | <[email protected]> |
--===============5569366417972904422== Content-Type: multipart/alternative; boundary="Apple-Mail=_352B68A6-3CAD-4E5E-A6F5-57E00D017790" --Apple-Mail=_352B68A6-3CAD-4E5E-A6F5-57E00D017790 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Just an update to this - I have committed a workaround for this problem. The next version of the Ninja build tool will have a way to discover the = names of build rules, which can then be used to query the compilation = database. Until this is available, I have implemented a workaround which = scans the Ninja build files recursively. Previously Ninja projects could specify a :build-rules attribute, and = now they can use :build-rules-regexp instead. This should fix the issue with recent CMake versions. Let me know any concerns or questions. > On Sep 20, 2015, at 9:38 PM, Alastair Rankine <[email protected]> = wrote: >=20 > I discovered recently that a change in CMake has broken compatibility = with ede-ninja-project. >=20 > Basically ede-ninja-project uses the native capability of the ninja = build tool to generate a compilation database on the fly. In order to do = this we need to specify the name of the appropriate build rules which we = want to see in the output. By default, the ede-ninja-project type uses = the rule names =E2=80=9CC_COMPILER=E2=80=9D and =E2=80=9CCXX_COMPILER=E2=80= =9D, which were until recently the default rule names for CMake. >=20 > In the recent 3.2 release (or possibly earlier) of CMake, a change was = made to the names of the build rules it generated within ninja=E2=80=99s = build file. Instead of =E2=80=9CCXX_COMPILER=E2=80=9D, it will now = generate build rules with names such as =E2=80=9CCXX_COMPILER__proj=E2=80=9D= . In other words, the build rule names are no longer stable, and hence = cannot easily be used with ede-ninja-project. >=20 > Workaround: For now I suggest using CMake=E2=80=99s = CMAKE_EXPORT_COMPILE_COMMANDS variable to export a compile_commands.json = file, which can be used with the regular ede-compdb-project type. >=20 > I think this is ultimately a Ninja problem, and I have raised it with = them, see here: https://github.com/martine/ninja/issues/1024 = <https://github.com/martine/ninja/issues/1024> >=20 > I have also added an expected failure for the affected ninja unit test = within CEDET. This is intended to allow the unit tests to execute = cleanly when a recent version of CMake is installed. Unfortunately there = is something about the CEDET utest environment which prevents it from = working correctly - instead of recording a test failure it records an = aborted test case. I looked into this briefly but couldn=E2=80=99t work = out why it was behaving like this - any advice appreciated. >=20 > By the way, I still intend to remove the runtime dependency on cmake = and ninja for the unit tests of compdb - which should also fix the = expected failure. >=20 > = --------------------------------------------------------------------------= ---- > _______________________________________________ > Cedet-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/cedet-devel --Apple-Mail=_352B68A6-3CAD-4E5E-A6F5-57E00D017790 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html = charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" = class=3D""><div class=3D"">Just an update to this - I have committed a = workaround for this problem.</div><div class=3D""><br = class=3D""></div><div class=3D"">The next version of the Ninja build = tool will have a way to discover the names of build rules, which can = then be used to query the compilation database. Until this is available, = I have implemented a workaround which scans the Ninja build files = recursively.</div><div class=3D""><br class=3D""></div><div = class=3D"">Previously Ninja projects could specify a :build-rules = attribute, and now they can use :build-rules-regexp instead.</div><div = class=3D""><br class=3D""></div><div class=3D"">This should fix the = issue with recent CMake versions.</div><div class=3D""><br = class=3D""></div><div class=3D"">Let me know any concerns or = questions.</div><div class=3D""><br class=3D""></div><br = class=3D""><div><blockquote type=3D"cite" class=3D""><div class=3D"">On = Sep 20, 2015, at 9:38 PM, Alastair Rankine <<a = href=3D"mailto:[email protected]" class=3D"">[email protected]</a>>= wrote:</div><br class=3D"Apple-interchange-newline"><div class=3D""><meta= http-equiv=3D"Content-Type" content=3D"text/html charset=3Dutf-8" = class=3D""><div style=3D"word-wrap: break-word; -webkit-nbsp-mode: = space; -webkit-line-break: after-white-space;" class=3D"">I discovered = recently that a change in CMake has broken compatibility with = ede-ninja-project.<div class=3D""><br class=3D""></div><div = class=3D"">Basically ede-ninja-project uses the native capability of the = ninja build tool to generate a compilation database on the fly. In order = to do this we need to specify the name of the appropriate build rules = which we want to see in the output. By default, the ede-ninja-project = type uses the rule names =E2=80=9CC_COMPILER=E2=80=9D and = =E2=80=9CCXX_COMPILER=E2=80=9D, which were until recently the default = rule names for CMake.</div><div class=3D""><br class=3D""></div><div = class=3D"">In the recent 3.2 release (or possibly earlier) of CMake, a = change was made to the names of the build rules it generated within = ninja=E2=80=99s build file. Instead of =E2=80=9CCXX_COMPILER=E2=80=9D, = it will now generate build rules with names such as = =E2=80=9CCXX_COMPILER__proj=E2=80=9D. In other words, the build rule = names are no longer stable, and hence cannot easily be used with = ede-ninja-project.</div><div class=3D""><br class=3D""></div><div = class=3D"">Workaround: For now I suggest using CMake=E2=80=99s = CMAKE_EXPORT_COMPILE_COMMANDS variable to export a compile_commands.json = file, which can be used with the regular ede-compdb-project = type.</div><div class=3D""><br class=3D""></div><div class=3D"">I think = this is ultimately a Ninja problem, and I have raised it with them, see = here: <a href=3D"https://github.com/martine/ninja/issues/1024" = class=3D"">https://github.com/martine/ninja/issues/1024</a></div><div = class=3D""><br class=3D""></div><div class=3D"">I have also added an = expected failure for the affected ninja unit test within CEDET. This is = intended to allow the unit tests to execute cleanly when a recent = version of CMake is installed. Unfortunately there is something about = the CEDET utest environment which prevents it from working correctly - = instead of recording a test failure it records an aborted test case. I = looked into this briefly but couldn=E2=80=99t work out why it was = behaving like this - any advice appreciated.</div><div class=3D""><br = class=3D""></div><div class=3D"">By the way, I still intend to remove = the runtime dependency on cmake and ninja for the unit tests of compdb - = which should also fix the expected failure.</div><div class=3D""><br = class=3D""></div></div>---------------------------------------------------= ---------------------------<br = class=3D"">_______________________________________________<br = class=3D"">Cedet-devel mailing list<br class=3D""><a = href=3D"mailto:[email protected]" = class=3D"">[email protected]</a><br = class=3D"">https://lists.sourceforge.net/lists/listinfo/cedet-devel<br = class=3D""></div></blockquote></div><br class=3D""></body></html>= --Apple-Mail=_352B68A6-3CAD-4E5E-A6F5-57E00D017790-- --===============5569366417972904422== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ------------------------------------------------------------------------------ --===============5569366417972904422== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Cedet-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/cedet-devel --===============5569366417972904422==--