Re: [cmake-developers] ninja failing CompileCommandOutput
On Mon, Jun 4, 2012 at 4:41 PM, Brad King wrote: > On 06/04/2012 10:25 AM, Bill Hoffman wrote: > > On 6/1/2012 1:55 PM, Brad King wrote: > >> The generator is supposed to produce a file that lists all the > >> compiler invocation command lines in a JSON format. The test > >> runs a build with the option and then runs a program that reads > >> the generated file and re-plays the commands. The test and its > >> C++ program should not need modification because it works for the > >> Makefile generator. The Ninja generator will need to generate > >> the properly encoded commands like the Makefile generator does. > > > > Seems like the json file is reasonable: > > > >"command": "C:\\PROGRA~2\\MICROS~1.0\\VC\\bin\\cl.exe /nologo > > /DWIN32 /D_WINDOWS /W3 /Zm1000 /EHsc /GR /D_DEBUG /MDd /Zi /Ob0 /Od > > /RTC1 -I\"c:\\Users\\hoffman\\Work\\My > > Builds\\NinjaCMake\\Tests\\CompileCommandOutput\\..\\..\\Source\" > > /TP > > /FoCMakeFiles/CompileCommandOutput.dir/compile_command_output.cxx.obj > > /FdTARGET_PDB -c \"c:\\Users\\hoffman\\Work\\My > > > Builds\\NinjaCMake\\Tests\\CompileCommandOutput\\compile_command_output.cxx\"", > >"file": "c:\\Users\\hoffman\\Work\\My > > > Builds\\NinjaCMake\\Tests\\CompileCommandOutput\\compile_command_output.cxx" > > }, > > > > the test driver should be able to read a file with \\ in it, > > and the generator output is fine. > > The topic was first brought up here: > > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/3678 > > Context of this discussion: > > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/3774 > > Origin of parser in question: > > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0e6b05fc > > Manuel, as author of this parser can you comment please? >From taking a very high level look it seems to me like the parser probably needs fixing on Windows - I unfortunately don't have a Windows machine around (I really need to get one ...), but I think disabling it for Windows is fine for now - as Stephen points out in a later email clang tooling for Windows is not that useful yet due to clang restrictions. If somebody expresses a strong need for the Windows fixes, I can prioritize them; please let me know in that case. Cheers, /Manuel -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Review request: Ninja-EXPORT_COMPILE_COMMANDS
+erikjv, who might have the perspective of yet-another-meta-build-system :) On Thu, May 10, 2012 at 12:47 AM, Peter Collingbourne wrote: > On Sun, May 06, 2012 at 03:20:59PM +0200, Stephen Kelly wrote: >> >> Hi, >> >> I've pushed a new branch to my clone for review to make the >> CMAKE_EXPORT_COMPILE_COMMANDS option work with the Ninja generator. >> >> https://gitorious.org/~steveire/cmake/steveires-cmake >> >> Thanks, >> >> Steve. > > Hi Steve, > > Thanks for working on this. > > I think the main problem with your changes is that they do not respect > the CMAKE_*_COMPILE_OBJECT variable, so the output will be wrong for > non-C++ compilers or compilers that do not take the conventional set > of command line parameters. > > Furthermore, there is no need to make paths within the build directory > absolute. Each command must be invoked from the home output directory > (i.e. the build "root" directory), so each command's "directory" > attribute should be set to that directory, rather than the start > output directory as in your patch. > > I am not sure if this is the best approach for building JSON files > from Ninja CMake builds. A few weeks ago I spoke with the folks at > Google who are working on Clang tooling, and I believe the current > thinking is that it may be best to teach Ninja to output JSON files > based on the provided build.ninja files. The advantage of this is > that it will work for any build system with a Ninja generator, and > there would be no need to add functionality to CMake which may impose > an additional maintenance burden and get out of sync with the > "real" build commands. As far as I recall we didn't come to a conclusion of what the "right" way to do it is, so let me try to summarize the thoughts we had first. With meta-build systems being common, there are basically 3 options for how to export build related information in a standardized format that is independent of the target build system: 1. Implement the output in every target build system Pro: - there might be implicit knowledge about the build that only the target system has - the format can be produced even when you don't have a meta build system Con: - some target build systems are hard to extend (make, VS, etc) - there are more target build systems then meta-build-systems 2. Implement the output in every meta build system Pro: - good meta build systems like cmake can abstract out common code for different target build systems, so there's less code to maintain overall - there are fewer places to implement the format Con: - not usable without meta build systems 3. A combination: Add support to some target build systems (like ninja) to support the format. Add support to meta build systems to output the format themselves for targets that don't support it, and add implicit targets to reproduce the information in the right spots for target build systems that support it. I think (3) is the optimal solution - target build systems can opt in to support the format, thus making use of their implicit knowledge about the build, while meta-build systems can ensure that no target system is left behind, using the common infrastructure to give basic support with little code. >From that perspective, I would argue that the proposed patch is a good thing (as it is not a lot of code and supports a real current pain (at least for me)), but we might want to rip it out once ninja supports compile command output itself. Thoughts? /Manuel -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Generating information for C++ tools in cmake (patch)
On Tue, May 17, 2011 at 6:03 AM, Brad King wrote: > On 05/16/2011 12:37 PM, Manuel Klimek wrote: >> On Mon, May 16, 2011 at 7:58 AM, Brad King wrote: >>> On 05/14/2011 01:04 AM, Manuel Klimek wrote: >>>> Any news on this one? We're currently building more tools, so it would >>>> be cool to know when we can expect this to be more easily available. >>>> If there's more work to do on my side, I'm happy to see it through. >>> >>> Thanks for the ping. I've had the topic sitting in my work tree for a while >>> but needed to make one more fix. I just needed to tweak your last commit to >>> only build the test helper code if the test would be run. I've merged the >>> topic to our 'next' branch: >>> >>> http://cmake.org/gitweb?p=cmake.git;a=commit;h=024f2cdc > > FYI, I had to fix several errors to make this topic portable: > > http://www.cdash.org/CDash/index.php?project=CMake&filtercount=3&showfilters=1&filtercombine=and&field1=buildstarttime/date&compare1=83&value1=2011-05-16%2021%3A00%3A00%20EDT&field2=buildstarttime/date&compare2=84&value2=2011-05-17%2006%3A00%3A00%20EDT&field3=builderrors/number&compare3=43&value3=0 > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c9174c0e > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a7e7a04a > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4e2185cb > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=169bb05f > > It's amazing how little of the STL can actually be used ;) Wow. Well, the language (and thus the stl) and the compilers have evolved - sometimes it's a shame if one has to support old versions that even the compiler writers would consider broken, but there is no choice - thanks for showing those corner cases, they're definitely educating for me. Cheers, /Manuel ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Generating information for C++ tools in cmake (patch)
On Mon, May 16, 2011 at 7:58 AM, Brad King wrote: > On 05/14/2011 01:04 AM, Manuel Klimek wrote: >> Any news on this one? We're currently building more tools, so it would >> be cool to know when we can expect this to be more easily available. >> If there's more work to do on my side, I'm happy to see it through. > > Thanks for the ping. I've had the topic sitting in my work tree for a while > but needed to make one more fix. I just needed to tweak your last commit to > only build the test helper code if the test would be run. I've merged the > topic to our 'next' branch: > > http://cmake.org/gitweb?p=cmake.git;a=commit;h=024f2cdc Cool, thanks! /Manuel ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Generating information for C++ tools in cmake (patch)
Any news on this one? We're currently building more tools, so it would be cool to know when we can expect this to be more easily available. If there's more work to do on my side, I'm happy to see it through. Thanks, /Manuel On Mon, Apr 25, 2011 at 10:22 AM, Manuel Klimek wrote: > On Mon, Apr 25, 2011 at 9:16 AM, Brad King wrote: >> On 04/25/2011 12:06 PM, Manuel Klimek wrote: >>> On Mon, Apr 25, 2011 at 8:59 AM, Brad King wrote: >>>> On 04/25/2011 11:54 AM, Manuel Klimek wrote: >>>>> Is just putting IF(UNIX) ... around all the stuff enough for that? >>>> >>>> It's not just the test. The C++ implementation cannot handle all >>>> generators. It should be taught to run only for generators where it >>>> is known to work. Perhaps it can check a value set by each platform >>>> module. >>> >>> Ah, ok, I was thinking putting it around the exporting of the flag, so >>> that you can only switch it on on supported platforms >> >> That approach may work. It is up to the platform modules to present >> the option when it can be implemented. If that is just a few conditions >> around a single place then great. >> >>> - as far as I >>> can tell, the code still works on other platforms, the database is >>> just not enough, right? >> >> The main problem is that some of the generators write syntax that is >> specific to the make tool (e.g. NMake, Borland) directly into the >> command line. That syntax confuses any tool that wants to read it >> from the database. > > Ok, I added > IF(CMAKE_GENERATOR MATCHES "Unix Makefiles") > to guard the export of the option, and > IF(UNIX) > to guard the execution of the test... > > Unfortunately I don't have non-unix systems to test on at the moment... > > I also reexported all my other patches rebased on current master head. > > Cheers, > /Manuel > ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Better Eclipse CDT support
On Mon, May 9, 2011 at 2:30 PM, Manuel Klimek wrote: > On Sun, May 8, 2011 at 7:38 PM, Oliver Buchtala > wrote: >> Hi Alex, Manuel, and other interested watchers, >> >> I'd like to introduce a preview version of an Eclipse plugin >> 'CMakeWorkbench' which is combined with the CMake CDT7 generator >> developed lately. >> I try to reduce user actions for importing projects and managing working >> sets. >> By watching solution files generated with CDT7 generator automatic >> updating is achieved... >> Of course there are still some hitches... and obviously much space for >> improvement... but hey ;) that's is my first eclipse plugin >> >> Please find notes about installation: >> https://github.com/oliver/cmake-workbench/blob/master/doc/Install.markdown >> and a step by step HelloWorld on: >> https://github.com/oliver/cmake-workbench/blob/master/doc/examples/HelloWorld.markdown >> >> Please: I'd like to have your opinion and maybe some trying :) > > First impression: very nice. > > Somehow even the .h stuff works now :) No, it doesn't ... It now opens the projects in the background (which is nice) and had me thinking that there were no duplicated .cpp files in there any more for a moment. > > /me is happy... will use it more and see how it behaves when the > CMakeLists.txt change :D > > Cheers, > /Manuel > >> >> Bye, >> Oliver >> >> PS: I have developed and tested under Ubuntu LTS 10.04 + Eclipse 3.7 M6 >> + CDT 8.0 M6. >> >> > ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Better Eclipse CDT support
On Sun, May 8, 2011 at 7:38 PM, Oliver Buchtala wrote: > Hi Alex, Manuel, and other interested watchers, > > I'd like to introduce a preview version of an Eclipse plugin > 'CMakeWorkbench' which is combined with the CMake CDT7 generator > developed lately. > I try to reduce user actions for importing projects and managing working > sets. > By watching solution files generated with CDT7 generator automatic > updating is achieved... > Of course there are still some hitches... and obviously much space for > improvement... but hey ;) that's is my first eclipse plugin > > Please find notes about installation: > https://github.com/oliver/cmake-workbench/blob/master/doc/Install.markdown > and a step by step HelloWorld on: > https://github.com/oliver/cmake-workbench/blob/master/doc/examples/HelloWorld.markdown > > Please: I'd like to have your opinion and maybe some trying :) First impression: very nice. Somehow even the .h stuff works now :) /me is happy... will use it more and see how it behaves when the CMakeLists.txt change :D Cheers, /Manuel > > Bye, > Oliver > > PS: I have developed and tested under Ubuntu LTS 10.04 + Eclipse 3.7 M6 > + CDT 8.0 M6. > > ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Better Eclipse CDT support
Pulling in a few more people (suggested audience from Sergey), please tell me if I'm CC'ing a list that doesn't make sense. Context: Oliver is currently working on making eclipse support for CMake a lot better. I heard that Andrew is working on configuration of includes and defines in eclipse, so there might be potential for coordinating efforts to make eclipse and cmake work better together and provide a really nicely integrated development setup. Cheers, /Manuel On Thu, Apr 28, 2011 at 3:03 PM, Oliver Buchtala wrote: > Am 28.04.2011 23:30, schrieb Oliver Buchtala: >> Am 28.04.2011 22:57, schrieb Alexander Neundorf: >>> On Wednesday 27 April 2011, Oliver Buchtala wrote: Forgot to feed the list... Am 27.04.2011 22:01, schrieb Alexander Neundorf: > On Friday 22 April 2011, Oliver Buchtala wrote: > ... > >> Here we go: >> git://github.com/oliver/cmake_cdt7.git >> >> I have intensively worked with this generator the last days - and am not >> completely satisfied with it in the moment. >> But basically, it does what I want. > I built and installed it. > I'm actually not really using Eclipse much myself, e.g. so I have never > used working sets before. > > I tried to load it via Project Explorer -> Select Working Set -> Window > Working Set -> Working set type: C/C++ and then selecting the > builddir/eclipse/CMake.wst file. > But now I'm not sure what to do with it. > The normal targets and directory structure look like they did before, and > in the eclipse/ directory there are a lot of empty directories starting > with a "@". > > So, how do I use it ? > > Alex Hi Alex, I have written down some things on http://edge.substance.io/#oliver/CMakeEclipseCDT7 >>> I installed the plugin. >>> Now I imported the working set CMake.wst instead of the project(s). >>> I see three working sets: CMake, CMake/ALL and CMake/CTestDashboardTargets. >>> When I select "Top Level Elements" -> Projects, I see nothing from them. >>> When I select "Top Level Elements" -> "Working sets", I see them, e.g. >>> the "CMake" one. When I try to click it open, it is empty. If I right-click >>> it and "Go Into", the pane becomes empty. >>> When I right-click and click "Properties", it shows me a dialog with the >>> existing (other) projects, no cmake among them, and no directories are >>> checked. >>> >>> What am I doing wrong ? >>> >>> The wst file is attached. >>> >>> Alex >> Hi Alex, >> >> wst-file is allright and I see that all projects are generated :) >> >> Unfortunately, this working set stuff is yet a bit inconvenient, as it >> is not an Eclipse built-in. >> >> What you need to do: >> 0. Switch to C/C++ perspective (maybe this is the empty project >> observation you described?) >> 1. Import eclipse projects (all from the CDT_ECLIPSE_OUTPUT_DIR) >> -> you see all projects flat side by side? >> 2. Import wst file >> 3. Goto 'Select Working Sets...' (in Project Explorer) >> 4. Select all (three) working sets >> 5. Goto 'Top Level Elements' (in Project Explorer) and activate 'Working >> Sets' >> Now you should see the projects within working sets >> >> Note1: almost all are in the CMake working sets, as FOLDERs are only set >> for MSVC generators >> Note2: once I experienced that the working sets plugin spoiled my >> workspace some how and I had import from scratch >> after deleting .metadata in workspace directory and restart eclipse and >> then redo that importing. >> >> Helps? >> >> I want to create an Eclipse Plugin which shall make all this more >> convenient and more automatically. >> Something like a CMake enabling 'Solution' file that manages imported >> projects and working sets etc... >> But yet I am a PDE beginner... so, this will take some more weeks... >> >> Bye, >> Oliver >> > FYI: I am currently struggling a bit with Eclipse's linked folders under > Eclipse 3.6 + CDT 7.0.2. > This has the consequence, that I can not add a link to > PROJECT_SOURCE_DIR and PROJECT_BINARY_DIR > without causing troubles with the CDT indexer. I'd really like to have a > the global project similar to the project your generator creates. > With Eclipse 3.7 and CDT 8 these problems seem to be resolved. > So that feature is currently deactivated and I will make it switchable > for edge-affine eclipse users. > When the next version is released officially it's gonna be the default > behavior. > > Bye, > Oliver > > ___ > cmake-developers mailing list > cmake-developers@cmake.org > http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers > ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Better Eclipse CDT support
On Fri, Apr 29, 2011 at 11:55 AM, Alexander Neundorf wrote: > On Thursday 28 April 2011, Oliver Buchtala wrote: > ... >> wst-file is allright and I see that all projects are generated :) >> >> Unfortunately, this working set stuff is yet a bit inconvenient, as it >> is not an Eclipse built-in. >> >> What you need to do: >> 0. Switch to C/C++ perspective (maybe this is the empty project >> observation you described?) >> 1. Import eclipse projects (all from the CDT_ECLIPSE_OUTPUT_DIR) >> -> you see all projects flat side by side? > > I have to import all the projects in eclipse/ manually one by one ? Nope, you just go to the toplevel directory, and eclipse will import recursively. > I mean, there are twenty or more, I didn't count. > I don't really feel like doing this. > >> 2. Import wst file >> 3. Goto 'Select Working Sets...' (in Project Explorer) >> 4. Select all (three) working sets >> 5. Goto 'Top Level Elements' (in Project Explorer) and activate 'Working >> Sets' >> Now you should see the projects within working sets >> >> Note1: almost all are in the CMake working sets, as FOLDERs are only set >> for MSVC generators >> Note2: once I experienced that the working sets plugin spoiled my >> workspace some how and I had import from scratch >> after deleting .metadata in workspace directory and restart eclipse and >> then redo that importing. >> >> Helps? >> >> I want to create an Eclipse Plugin which shall make all this more >> convenient and more automatically. >> Something like a CMake enabling 'Solution' file that manages imported >> projects and working sets etc... >> But yet I am a PDE beginner... so, this will take some more weeks... > > That sounds like a great plan :-) > > But, for me, the thing which sucks by far most about the Eclipse generator, is > that Eclipse has these problems with out-of-source building. > AFAIK Eclipse expects that the project file is at the root of the source tree, > and that e.g. also the svn etc. directories are in this tree. For me Oliver's eclipse generator actually works with out-of-source builds. (eclipse 3.7, CDT 8). If I remember correctly the main thing to look out for is to put the workspace outside of both the source and the cmake build directory. Cheers, /Manuel > > Now a golden rule of cmake is to never generate stuff into the source dir, but > always only into the binary dir. Otherwise it is not really possible to have > multiple build dirs for one source dir. > > So, if you think about starting to work on Eclipse, it would be *great* if you > could try to make Eclipse support project root dir != dir of the project > file, i.e. out-of-source builds. > > Alex > ___ > cmake-developers mailing list > cmake-developers@cmake.org > http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers > ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Generating information for C++ tools in cmake (patch)
On Mon, Apr 25, 2011 at 9:16 AM, Brad King wrote:
> On 04/25/2011 12:06 PM, Manuel Klimek wrote:
>> On Mon, Apr 25, 2011 at 8:59 AM, Brad King wrote:
>>> On 04/25/2011 11:54 AM, Manuel Klimek wrote:
>>>> Is just putting IF(UNIX) ... around all the stuff enough for that?
>>>
>>> It's not just the test. The C++ implementation cannot handle all
>>> generators. It should be taught to run only for generators where it
>>> is known to work. Perhaps it can check a value set by each platform
>>> module.
>>
>> Ah, ok, I was thinking putting it around the exporting of the flag, so
>> that you can only switch it on on supported platforms
>
> That approach may work. It is up to the platform modules to present
> the option when it can be implemented. If that is just a few conditions
> around a single place then great.
>
>> - as far as I
>> can tell, the code still works on other platforms, the database is
>> just not enough, right?
>
> The main problem is that some of the generators write syntax that is
> specific to the make tool (e.g. NMake, Borland) directly into the
> command line. That syntax confuses any tool that wants to read it
> from the database.
Ok, I added
IF(CMAKE_GENERATOR MATCHES "Unix Makefiles")
to guard the export of the option, and
IF(UNIX)
to guard the execution of the test...
Unfortunately I don't have non-unix systems to test on at the moment...
I also reexported all my other patches rebased on current master head.
Cheers,
/Manuel
From 4984fa3a6a5d276a5a2fbad610cf9ebfc4cd187f Mon Sep 17 00:00:00 2001
From: Manuel Klimek
Date: Wed, 12 Jan 2011 20:06:25 -0800
Subject: [PATCH 1/6] refactor flags and defines
---
Source/cmMakefileTargetGenerator.cxx | 120 ++---
Source/cmMakefileTargetGenerator.h |3 +
2 files changed, 68 insertions(+), 55 deletions(-)
diff --git a/Source/cmMakefileTargetGenerator.cxx b/Source/cmMakefileTargetGenerator.cxx
index 69320da..01545fc 100644
--- a/Source/cmMakefileTargetGenerator.cxx
+++ b/Source/cmMakefileTargetGenerator.cxx
@@ -249,6 +249,66 @@ void cmMakefileTargetGenerator::WriteCommonCodeRules()
}
//
+std::string cmMakefileTargetGenerator::GetFlags(const std::string &l) {
+ std::string flags;
+ const char *lang = l.c_str();
+
+ bool shared = ((this->Target->GetType() == cmTarget::SHARED_LIBRARY) ||
+ (this->Target->GetType() == cmTarget::MODULE_LIBRARY));
+
+ // Add language feature flags.
+ this->AddFeatureFlags(flags, lang);
+
+ this->LocalGenerator->AddArchitectureFlags(flags, this->Target,
+ lang, this->ConfigName);
+
+ // Fortran-specific flags computed for this target.
+ if(l == "Fortran")
+{
+this->AddFortranFlags(flags);
+}
+
+ // Add shared-library flags if needed.
+ this->LocalGenerator->AddSharedFlags(flags, lang, shared);
+
+ // Add include directory flags.
+ this->AddIncludeFlags(flags, lang);
+
+ // Append old-style preprocessor definition flags.
+ this->LocalGenerator->
+AppendFlags(flags, this->Makefile->GetDefineFlags());
+
+ // Add include directory flags.
+ this->LocalGenerator->
+AppendFlags(flags,this->GetFrameworkFlags().c_str());
+
+ return flags;
+}
+
+std::string cmMakefileTargetGenerator::GetDefines(const std::string &l) {
+ std::string defines;
+ const char *lang = l.c_str();
+ // Add the export symbol definition for shared library objects.
+ if(const char* exportMacro = this->Target->GetExportMacro())
+{
+this->LocalGenerator->AppendDefines(defines, exportMacro, lang);
+}
+
+ // Add preprocessor definitions for this target and configuration.
+ this->LocalGenerator->AppendDefines
+(defines, this->Makefile->GetProperty("COMPILE_DEFINITIONS"), lang);
+ this->LocalGenerator->AppendDefines
+(defines, this->Target->GetProperty("COMPILE_DEFINITIONS"), lang);
+ std::string defPropName = "COMPILE_DEFINITIONS_";
+ defPropName +=
+cmSystemTools::UpperCase(this->LocalGenerator->ConfigurationName);
+ this->LocalGenerator->AppendDefines
+(defines, this->Makefile->GetProperty(defPropName.c_str()), lang);
+ this->LocalGenerator->AppendDefines
+(defines, this->Target->GetProperty(defPropName.c_str()), lang);
+ return defines;
+}
+
void cmMakefileTargetGenerator::WriteTargetLanguageFlags()
{
// write language flags for target
@@ -262,72 +322,22 @@ void cmMakefileTargetGenerator::WriteTargetLanguageFlags()
cmStdString compiler = "CMAKE_";
compiler += *l;
compiler += "_COMPILER";
-*this->FlagFileStream << "#
Re: [cmake-developers] Better Eclipse CDT support
On Sat, Apr 23, 2011 at 2:56 PM, Oliver Buchtala wrote: > Please have a look at: > > git://github.com/oliver/cmake_cdt7.git > > > ...and try ;) ...and send me feedback. So far this looks *great* - I happen to work on a few cmake enabled open source projects at the moment, so this is really making my day :) One feature request would be to teach it parallelism - I've got 12 (logical) cores, please, dear eclipse, use them - sequential builds are so 90s. I can set them in the project settings (C/C++ Build -> Behaviour -> Use parallel build), but doing so for every project is quite cumbersome now that there are quite a few of those projects ... Cheers, /Manuel ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Generating information for C++ tools in cmake (patch)
On Mon, Apr 25, 2011 at 8:59 AM, Brad King wrote: > On 04/25/2011 11:54 AM, Manuel Klimek wrote: >> Is just putting IF(UNIX) ... around all the stuff enough for that? > > It's not just the test. The C++ implementation cannot handle all > generators. It should be taught to run only for generators where it > is known to work. Perhaps it can check a value set by each platform > module. Ah, ok, I was thinking putting it around the exporting of the flag, so that you can only switch it on on supported platforms - as far as I can tell, the code still works on other platforms, the database is just not enough, right? Cheers, /Manuel ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Generating information for C++ tools in cmake (patch)
On Mon, Apr 25, 2011 at 8:27 AM, Brad King wrote: > On 04/05/2011 12:13 PM, Manuel Klimek wrote: >> On Tue, Apr 5, 2011 at 6:19 AM, Brad King wrote: >>> On 04/05/2011 08:33 AM, Brad King wrote: >>>> On 04/04/2011 12:01 PM, Manuel Klimek wrote: >>>>> Done. >>>> >>>> Thanks! >>> >>> While running the test on more platforms I ran into a problem. On >>> Windows makefile tools like Borland and NMake we use custom inline >>> response file syntax to handle long command lines: >>> >>> http://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/Platform/Windows.cmake;hb=v2.8.4#l16 >>> >>> This syntax ends up in compile_commands.json and then makes no sense. >>> This opens a can of worms. Unless we can refactor the generators to >>> avoid using inline response file syntax then this whole feature will >>> not work. Recently I added support for using cmake-generated response >>> files for -I paths on some platforms: >>> >>> http://cmake.org/gitweb?p=cmake.git;a=commit;h=1c3233a8 >>> >>> It is a start, but I have no time to work further on ensuring command >>> lines in the makefiles stay short enough for the ancient Windows make >>> tools. >>> >>> For what platforms do you actually need this feature? >> >> The first version is completely fine as unix-only - clang on Windows >> is not exactly "there" yet, so I think doing the Windows stuff as a >> second step when we have proven the usefulness in unix land by >> integrating some tools will make sense. > > I still cannot integrate this patch series until the above problems have > been addressed. Please extend the series with a patch that disables the > option except on the platforms where you know it works. Is just putting IF(UNIX) ... around all the stuff enough for that? Thanks, /Manuel ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] PATCH: Adds functions to run standalone tools and to parse the command line arguments from a compile command line database as generated by CMake
This is the next step in building the standalone tools infrastructure: This patch simplifies writing of standalone Clang tools. As an example, we add clang-check, a tool that runs a syntax only frontend action over a .cc file. When you integrate this into your favorite editor, you get much faster feedback on your compilation errors, thus reducing your feedback cycle especially when writing new code. The tool depends on integration of an outstanding patch to CMake to work (cc'ed Brad King) which allows you to always have a current compile command database in your cmake output directory when you set CMAKE_EXPORT_COMPILE_COMMANDS. The change has been reviewed by Zhanyong (and to a lesser extend by Chandler). 0001-Adds-functions-to-run-standalone-tools-and-to-parse-.patch Description: Binary data ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Generating information for C++ tools in cmake (patch)
For your convenience, rebased onto current head and git format-patch'ed.
Cheers,
/Manuel
On Tue, Apr 5, 2011 at 9:14 AM, Manuel Klimek wrote:
> On Tue, Apr 5, 2011 at 5:33 AM, Brad King wrote:
>> On 04/04/2011 12:01 PM, Manuel Klimek wrote:
>>> Done.
>>
>> Thanks!
>>
>>> I also have the previous patches ready (re-based with master). Let me
>>> know how we'll go on about submitting all that.
>>
>> I still have them on a local topic branch. See below.
>> Have you changed anything since then?
>
> Well, the git rebase led to conflicts which I resolved - otherwise I
> didn't change anything on the other patches. So I can re-export the
> changes to save you some work with merging, if you want :)
>
> Cheers,
> /Manuel
>
>> If you prefer to send the new versions, please use "git format-patch" to
>> construct the patch series. Then send the files by email.
>>
>> Thanks,
>> -Brad
>>
>>
>> commit c8ed16a373adf98cf21a619349de8c0bde6a0eed
>> Author: Manuel Klimek
>> Date: Mon Jan 17 11:44:44 2011 -0500
>>
>> Make compile line export optional
>>
>> Add option CMAKE_EXPORT_COMPILE_COMMANDS to control the behavior.
>>
>> Modules/CMakeGenericSystem.cmake | 3 +++
>> Source/cmGlobalUnixMakefileGenerator3.cxx | 2 +-
>> Source/cmMakefileTargetGenerator.cxx | 3 ++-
>> 3 files changed, 6 insertions(+), 2 deletions(-)
>>
>> commit 357fdbb1d7c472991323d36c6a431a36f16918bd
>> Author: Manuel Klimek
>> Date: Thu Jan 13 16:15:54 2011 -0500
>>
>> Export all compile command lines to json database
>>
>> Source/cmGlobalUnixMakefileGenerator3.cxx | 41
>> +
>> Source/cmGlobalUnixMakefileGenerator3.h | 6
>> Source/cmMakefileTargetGenerator.cxx | 21 +-
>> 3 files changed, 66 insertions(+), 2 deletions(-)
>>
>> commit a75e21cadeb48c257d870db925131994f7da4995
>> Author: Manuel Klimek
>> Date: Thu Jan 13 16:06:20 2011 -0500
>>
>> Factor Makefile flag and define lookup into methods
>>
>> Cache results over repeated calls.
>>
>> Source/cmMakefileTargetGenerator.cxx | 107
>> +++--
>> Source/cmMakefileTargetGenerator.h | 5 ++
>> 2 files changed, 67 insertions(+), 45 deletions(-)
>>
>
>
>
> --
> Manuel Klimek (http://go/klimek)
From 8b304e3c4a111a242033d261adb9f02f116cfa96 Mon Sep 17 00:00:00 2001
From: Manuel Klimek
Date: Wed, 12 Jan 2011 20:06:25 -0800
Subject: [PATCH 1/5] refactor flags and defines
---
Source/cmMakefileTargetGenerator.cxx | 120 ++---
Source/cmMakefileTargetGenerator.h |3 +
2 files changed, 68 insertions(+), 55 deletions(-)
diff --git a/Source/cmMakefileTargetGenerator.cxx b/Source/cmMakefileTargetGenerator.cxx
index 69320da..01545fc 100644
--- a/Source/cmMakefileTargetGenerator.cxx
+++ b/Source/cmMakefileTargetGenerator.cxx
@@ -249,6 +249,66 @@ void cmMakefileTargetGenerator::WriteCommonCodeRules()
}
//
+std::string cmMakefileTargetGenerator::GetFlags(const std::string &l) {
+ std::string flags;
+ const char *lang = l.c_str();
+
+ bool shared = ((this->Target->GetType() == cmTarget::SHARED_LIBRARY) ||
+ (this->Target->GetType() == cmTarget::MODULE_LIBRARY));
+
+ // Add language feature flags.
+ this->AddFeatureFlags(flags, lang);
+
+ this->LocalGenerator->AddArchitectureFlags(flags, this->Target,
+ lang, this->ConfigName);
+
+ // Fortran-specific flags computed for this target.
+ if(l == "Fortran")
+{
+this->AddFortranFlags(flags);
+}
+
+ // Add shared-library flags if needed.
+ this->LocalGenerator->AddSharedFlags(flags, lang, shared);
+
+ // Add include directory flags.
+ this->AddIncludeFlags(flags, lang);
+
+ // Append old-style preprocessor definition flags.
+ this->LocalGenerator->
+AppendFlags(flags, this->Makefile->GetDefineFlags());
+
+ // Add include directory flags.
+ this->LocalGenerator->
+AppendFlags(flags,this->GetFrameworkFlags().c_str());
+
+ return flags;
+}
+
+std::string cmMakefileTargetGenerator::GetDefines(const std::string &l) {
+ std::string defines;
+ const char *lang = l.c_str();
+ // Add the export symbol definition for shared library objects.
+ if(const char* exportMacro = this->Target->GetExportMacro())
+{
+this->LocalGenerator->AppendDefines(defines, exportMacro, lang);
+}
+
+ // Add preprocessor definitions for this targe
Re: [cmake-developers] Generating information for C++ tools in cmake (patch)
On Tue, Apr 5, 2011 at 5:33 AM, Brad King wrote: > On 04/04/2011 12:01 PM, Manuel Klimek wrote: >> Done. > > Thanks! > >> I also have the previous patches ready (re-based with master). Let me >> know how we'll go on about submitting all that. > > I still have them on a local topic branch. See below. > Have you changed anything since then? Well, the git rebase led to conflicts which I resolved - otherwise I didn't change anything on the other patches. So I can re-export the changes to save you some work with merging, if you want :) Cheers, /Manuel > If you prefer to send the new versions, please use "git format-patch" to > construct the patch series. Then send the files by email. > > Thanks, > -Brad > > > commit c8ed16a373adf98cf21a619349de8c0bde6a0eed > Author: Manuel Klimek > Date: Mon Jan 17 11:44:44 2011 -0500 > > Make compile line export optional > > Add option CMAKE_EXPORT_COMPILE_COMMANDS to control the behavior. > > Modules/CMakeGenericSystem.cmake | 3 +++ > Source/cmGlobalUnixMakefileGenerator3.cxx | 2 +- > Source/cmMakefileTargetGenerator.cxx | 3 ++- > 3 files changed, 6 insertions(+), 2 deletions(-) > > commit 357fdbb1d7c472991323d36c6a431a36f16918bd > Author: Manuel Klimek > Date: Thu Jan 13 16:15:54 2011 -0500 > > Export all compile command lines to json database > > Source/cmGlobalUnixMakefileGenerator3.cxx | 41 > + > Source/cmGlobalUnixMakefileGenerator3.h | 6 > Source/cmMakefileTargetGenerator.cxx | 21 +- > 3 files changed, 66 insertions(+), 2 deletions(-) > > commit a75e21cadeb48c257d870db925131994f7da4995 > Author: Manuel Klimek > Date: Thu Jan 13 16:06:20 2011 -0500 > > Factor Makefile flag and define lookup into methods > > Cache results over repeated calls. > > Source/cmMakefileTargetGenerator.cxx | 107 +++-- > Source/cmMakefileTargetGenerator.h | 5 ++ > 2 files changed, 67 insertions(+), 45 deletions(-) > -- Manuel Klimek (http://go/klimek) ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Generating information for C++ tools in cmake (patch)
On Tue, Apr 5, 2011 at 6:19 AM, Brad King wrote: > On 04/05/2011 08:33 AM, Brad King wrote: >> On 04/04/2011 12:01 PM, Manuel Klimek wrote: >>> Done. >> >> Thanks! > > While running the test on more platforms I ran into a problem. On > Windows makefile tools like Borland and NMake we use custom inline > response file syntax to handle long command lines: > > http://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/Platform/Windows.cmake;hb=v2.8.4#l16 > > This syntax ends up in compile_commands.json and then makes no sense. > This opens a can of worms. Unless we can refactor the generators to > avoid using inline response file syntax then this whole feature will > not work. Recently I added support for using cmake-generated response > files for -I paths on some platforms: > > http://cmake.org/gitweb?p=cmake.git;a=commit;h=1c3233a8 > > It is a start, but I have no time to work further on ensuring command > lines in the makefiles stay short enough for the ancient Windows make > tools. > > For what platforms do you actually need this feature? The first version is completely fine as unix-only - clang on Windows is not exactly "there" yet, so I think doing the Windows stuff as a second step when we have proven the usefulness in unix land by integrating some tools will make sense. Cheers, /Manuel ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Generating information for C++ tools in cmake (patch)
On Mon, Apr 4, 2011 at 8:26 AM, Brad King wrote:
> On 04/01/2011 02:42 PM, Manuel Klimek wrote:
>> sorry for the delay, but I was busy with other stuff - please find
>> attached a proposal patch for the test - I don't know enough about the
>> cmake testing infrastructure to say whether that was what you
>> imagined, please let me know if I should change anything.
>
> That looks pretty good, thanks. Here are a few comments from review:
>
> - The cmSystemTools::ParseArguments method is not very solid. It fails for
> double-quotes in the middle of an argument, like '-I"a b"'. Use the newer
> ParseUnixCommandLine instead. Unfortunately for historical reasons we
> need to convert from vector to vector. Try
> the patch below.
Done.
> - The Source directory should not be touched for this. Put the source code
> in Tests/CMakeLib and move the code to build the executable to the
> CMakeLists.txt file in that directory.
Done.
> - In the CompileCommandOutput test source files, please actually create a
> symbol in each library and call them from the main. Otherwise some
> toolchains will complain about empty object files.
Done.
> - The ADD_TEST_MACRO call will need to be conditioned to run only when the
> exported compile lines will work. I will take care of that for you when
> the rest of the patch is ready.
I also have the previous patches ready (re-based with master). Let me
know how we'll go on about submitting all that.
Thanks,
/Manuel
>
> Thanks,
> -Brad
>
>
> diff --git a/Source/run_compile_commands.cxx b/Source/run_compile_commands.cxx
> index 0b248f7..82cedfb 100644
> --- a/Source/run_compile_commands.cxx
> +++ b/Source/run_compile_commands.cxx
> @@ -117,8 +117,9 @@ int main ()
> it = parser.GetTranslationUnits().begin(),
> end = parser.GetTranslationUnits().end(); it != end; ++it)
> {
> - std::vector command =
> - cmSystemTools::ParseArguments(it->at("command").c_str());
> + std::vector command1;
> + cmSystemTools::ParseUnixCommandLine(it->at("command").c_str(), command1);
> + std::vector command(command1.begin(), command1.end());
> if (!cmSystemTools::RunSingleCommand(
> command, 0, 0, it->at("directory").c_str()))
> {
>
--
Manuel Klimek (http://go/klimek)
diff --git a/Tests/CMakeLib/CMakeLists.txt b/Tests/CMakeLib/CMakeLists.txt
index bda2fa5..7815545 100644
--- a/Tests/CMakeLib/CMakeLists.txt
+++ b/Tests/CMakeLib/CMakeLists.txt
@@ -30,3 +30,6 @@ endif()
foreach(test ${CMakeLib_TESTS})
add_test(CMakeLib.${test} CMakeLibTests ${test})
endforeach()
+
+ADD_EXECUTABLE(runcompilecommands run_compile_commands.cxx)
+TARGET_LINK_LIBRARIES(runcompilecommands CMakeLib)
diff --git a/Tests/CMakeLib/run_compile_commands.cxx b/Tests/CMakeLib/run_compile_commands.cxx
new file mode 100644
index 000..c925167
--- /dev/null
+++ b/Tests/CMakeLib/run_compile_commands.cxx
@@ -0,0 +1,132 @@
+#include "cmSystemTools.h"
+
+class CompileCommandParser {
+public:
+ typedef std::map CommandType;
+ typedef std::vector TranslationUnitsType;
+
+ CompileCommandParser(std::ifstream *input)
+ {
+this->Input = input;
+ }
+
+ void Parse()
+ {
+NextNonWhitespace();
+ParseTranslationUnits();
+ }
+
+ const TranslationUnitsType& GetTranslationUnits()
+ {
+return this->TranslationUnits;
+ }
+
+private:
+ void ParseTranslationUnits()
+ {
+this->TranslationUnits = TranslationUnitsType();
+ExpectOrDie('[', "at start of compile command file");
+do
+ {
+ ParseTranslationUnit();
+ this->TranslationUnits.push_back(this->Command);
+ } while(Expect(','));
+ExpectOrDie(']', "at end of array");
+ }
+
+ void ParseTranslationUnit()
+ {
+this->Command = CommandType();
+if(!Expect('{')) return;
+if(Expect('}')) return;
+do
+ {
+ ParseString();
+ std::string name = this->String;
+ ExpectOrDie(':', "between name and value");
+ ParseString();
+ std::string value = this->String;
+ this->Command[name] = value;
+ } while(Expect(','));
+ExpectOrDie('}', "at end of object");
+ }
+
+ void ParseString()
+ {
+this->String.clear();
+if(!Expect('"')) return;
+while (!Expect('"'))
+ {
+ Expect('\\');
+ this->String.push_back(C);
+ Next();
+ }
+ }
+
+ bool Expect(char c)
+ {
+if(this->C == c)
+ {
+ NextNonWhitespace();
+ return true;
+ }
+return false;
+ }
+
+ void ExpectOrDie(char c, const std::string & message)
+ {
+if (!Expect(c))
+ ErrorExit
Re: [cmake-developers] Generating information for C++ tools in cmake (patch)
Hi Brad, sorry for the delay, but I was busy with other stuff - please find attached a proposal patch for the test - I don't know enough about the cmake testing infrastructure to say whether that was what you imagined, please let me know if I should change anything. Cheers, /Manuel On Thu, Jan 20, 2011 at 1:55 PM, Brad King wrote: > On 1/19/2011 9:07 PM, Manuel Klimek wrote: >> So the question is: do you want to run this test as part of the >> dashboard clients? > > Yes, we do. Please implement the test in C++ using the hints I > sent previously. > > Thanks, > -Brad > -- Manuel Klimek (http://go/klimek) cmake-compile-command-test.patch Description: Binary data ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Generating information for C++ tools in cmake (patch)
On Tue, Jan 18, 2011 at 11:08 AM, David Cole wrote: > On Tue, Jan 18, 2011 at 1:53 PM, Brad King wrote: >> >> On 1/18/2011 1:50 PM, Manuel Klimek wrote: >> > Since this is a big integration style test, is it also possible to >> > integrate a python test? (the whole test would fit into a few lines of >> > python then) >> >> We'd prefer not to depend on python, but certainly a prototype in >> python would be a good start. >> >> -Brad >> ___ >> cmake-developers mailing list >> cmake-developers@cmake.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers > > > Brad's being polite when he says we'd prefer not to depend on python. > > CMake itself *will not* depend on python. And for any test that is expected > to be run on all of our dashboard clients before it's accepted into CMake > 'master', such a test cannot depend on python either. So the question is: do you want to run this test as part of the dashboard clients? I'm happy to comply with whatever decision you make, given the trade-off between maintainability of the test and dependency on python. Cheers, /Manuel ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Generating information for C++ tools in cmake (patch)
On Mon, Jan 17, 2011 at 8:52 AM, Brad King wrote: > On 01/14/2011 06:19 PM, Manuel Klimek wrote: >> Attached are 2 patches for caching the defines&flags and introducing >> the options. > > Thanks. > >> I'll look into testing next, any hints for what to look out for would >> be appreciated ;) > > I think the test needs to build one of CMake's current tests, > such as COnly, with the new export option. Then it should parse > the json file and try re-running all the recorded command lines. > > The easiest way to do this is probably to create a new executable > that builds as part of the main CMake build process when the > BUILD_TESTING option is on. It can link to CMakeLib and use > helpers like cmSystemTools::RunSingleCommand to take care of > re-running the children. You'll have to write a tiny json parser > of course. Since this is a big integration style test, is it also possible to integrate a python test? (the whole test would fit into a few lines of python then) Cheers, /Manuel ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Generating information for C++ tools in cmake (patch)
Attached are 2 patches for caching the defines&flags and introducing
the options.
I'll look into testing next, any hints for what to look out for would
be appreciated ;)
Cheers,
/Manuel
On Fri, Jan 14, 2011 at 2:54 PM, Brad King wrote:
> On 01/14/2011 05:46 PM, Manuel Klimek wrote:
>> I'm currently trying to figure out the best point where to add that
>> option...
>
> In the cmMakefileTargetGenerator you can test for the option with
>
> this->Makefile->IsOn("...")
>
>> Is there a good example I can base it on? So far I followed
>> CMAKE_BUILD_TYPE through the code base, which suggests that I need to
>> - find a .cmake file in modules in which I can put the option
>> - document it in cmDocumentVariables
>
> Probably like CMAKE_VERBOSE_MAKEFILE which is another option to the
> Makefile generator. See CMakeGenericSystem.cmake. Surround it by
>
> if("${CMAKE_GENERATOR}" MATCHES "Make")
> ...
> endif()
>
> so that it only shows up for Makefile generators.
>
> -Brad
>
--
Manuel Klimek (http://go/klimek)
diff --git a/Source/cmMakefileTargetGenerator.cxx b/Source/cmMakefileTargetGenerator.cxx
index 52b6bb7..07f5014 100644
--- a/Source/cmMakefileTargetGenerator.cxx
+++ b/Source/cmMakefileTargetGenerator.cxx
@@ -250,59 +250,66 @@ void cmMakefileTargetGenerator::WriteCommonCodeRules()
//
std::string cmMakefileTargetGenerator::GetFlags(const std::string &l) {
- std::string flags;
- const char *lang = l.c_str();
+ std::pair::iterator, bool>
+insert_result = this->FlagsByLanguage.insert(std::make_pair(l, ""));
+ if (insert_result.second) {
+std::string& flags = insert_result.first->second;
+const char *lang = l.c_str();
- bool shared = ((this->Target->GetType() == cmTarget::SHARED_LIBRARY) ||
- (this->Target->GetType() == cmTarget::MODULE_LIBRARY));
+bool shared = ((this->Target->GetType() == cmTarget::SHARED_LIBRARY) ||
+ (this->Target->GetType() == cmTarget::MODULE_LIBRARY));
- // Add language feature flags.
- this->AddFeatureFlags(flags, lang);
+// Add language feature flags.
+this->AddFeatureFlags(flags, lang);
- this->LocalGenerator->AddArchitectureFlags(flags, this->Target,
- lang, this->ConfigName);
+this->LocalGenerator->AddArchitectureFlags(flags, this->Target,
+ lang, this->ConfigName);
- // Fortran-specific flags computed for this target.
- if(l == "Fortran")
-{
-this->AddFortranFlags(flags);
-}
-
- // Add shared-library flags if needed.
- this->LocalGenerator->AddSharedFlags(flags, lang, shared);
+// Fortran-specific flags computed for this target.
+if(l == "Fortran")
+ {
+ this->AddFortranFlags(flags);
+ }
- // Add include directory flags.
- this->LocalGenerator->
-AppendFlags(flags, this->LocalGenerator->GetIncludeFlags(lang));
- // Add include directory flags.
- this->LocalGenerator->
-AppendFlags(flags,this->GetFrameworkFlags().c_str());
+// Add shared-library flags if needed.
+this->LocalGenerator->AddSharedFlags(flags, lang, shared);
- return flags;
+// Add include directory flags.
+this->LocalGenerator->
+ AppendFlags(flags, this->LocalGenerator->GetIncludeFlags(lang));
+// Add include directory flags.
+this->LocalGenerator->
+ AppendFlags(flags,this->GetFrameworkFlags().c_str());
+ }
+ return insert_result.first->second;
}
std::string cmMakefileTargetGenerator::GetDefines(const std::string &l) {
- std::string defines;
- const char *lang = l.c_str();
- // Add the export symbol definition for shared library objects.
- if(const char* exportMacro = this->Target->GetExportMacro())
-{
-this->LocalGenerator->AppendDefines(defines, exportMacro, lang);
-}
+ std::pair::iterator, bool>
+insert_result = this->DefinesByLanguage.insert(std::make_pair(l, ""));
+ if (insert_result.second) {
+std::string &defines = insert_result.first->second;
+const char *lang = l.c_str();
+// Add the export symbol definition for shared library objects.
+if(const char* exportMacro = this->Target->GetExportMacro())
+ {
+ this->LocalGenerator->AppendDefines(defines, exportMacro, lang);
+ }
- // Add preprocessor definitions for this target and configuration.
- this->LocalGenerator->AppendDefines
-(defines, this->Makefile->GetProperty("COMPILE_DEFINITIONS"), lang);
- this->LocalGenerator->AppendDefines
-(defines, this->Target->GetPr
Re: [cmake-developers] Generating information for C++ tools in cmake (patch)
On Fri, Jan 14, 2011 at 11:05 AM, Brad King wrote: > On 01/14/2011 01:58 PM, Manuel Klimek wrote: >> Hm, I was actually going more for a bool option - I'd really like a >> file name that's easily recognizable by a tool with minimal user >> configuration. > > Sure. If you are trying to create a standard file name/format then you > should choose a marketable name for it. That will make it recognizable, > distinct, "googleable", and not tied to CMake or any build system. > It will also provide a meaningful name for the CMake option: > > $ cmake ... -DCMAKE_EXPORT_$coolname=1 I'm currently trying to figure out the best point where to add that option... Is there a good example I can base it on? So far I followed CMAKE_BUILD_TYPE through the code base, which suggests that I need to - find a .cmake file in modules in which I can put the option - document it in cmDocumentVariables Anything I'm missing? Thanks a lot, /Manuel ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Generating information for C++ tools in cmake (patch)
On Fri, Jan 14, 2011 at 10:53 AM, Brad King wrote: > On 01/14/2011 01:28 PM, Manuel Klimek wrote: >> I'm fine with making it optional. Another option would be to make it >> hidden, as we want tools and not users to interact with it. Your call. > > Actually, with an option then the file name becomes moot: > > $ cmake ... -DCMAKE_EXPORT_COMPILE_RULES=compile_commands.json Hm, I was actually going more for a bool option - I'd really like a file name that's easily recognizable by a tool with minimal user configuration. We can of course put in a second option with the file name with a good default. Cheers, /Manuel >>> Okay. Does JSON support any kind of schema? >> >> Why would we need a schema? For documenation? Or do you plan to use >> meta-tools on it? > > Just curious. Pretty much every time I've ever written code that > generates a .xml file someone eventually comes along asking for > a schema. ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Generating information for C++ tools in cmake (patch)
On Fri, Jan 14, 2011 at 5:25 AM, Brad King wrote: > On 01/13/2011 06:05 PM, Manuel Klimek wrote: >> I think that finding this file in the same spot relative to the base >> build directory independently of the build system used will make it a >> lot easier for tool-smiths / users to actually make use of it. If you >> want to hide it away, I'd vote for a more build system independent >> name than CMakeFiles. > > CMake used to write lots of files to the top of the build tree but many > people complained about the verbosity, especially for in-source builds. > Now we hide as many files as possible under CMakeFiles/ subdirectories. > If the file must go in the top level then I'd prefer to enable it only > optionally as discussed previously. I'm fine with making it optional. Another option would be to make it hidden, as we want tools and not users to interact with it. Your call. >>> About the content of the json file: I suggest that each command also >>> include a "language" field indicating "C", "C++", or "Fortran". >> >> I'd rather keep it focused for now, and add additional things later if >> you're ok with that. > > Okay. Does JSON support any kind of schema? Why would we need a schema? For documenation? Or do you plan to use meta-tools on it? Cheers, /Manuel ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Generating information for C++ tools in cmake (patch)
On Thu, Jan 13, 2011 at 1:30 PM, Brad King wrote: > On 01/12/2011 11:47 PM, Manuel Klimek wrote: >> Split up the patch - apparently I need ssh access to push the topic >> stuff, so I'm just attaching the patches. > > Thanks. That's pretty clean. In the final version of this topic please > add one more intermediate commit that optimizes GetFlags and GetDefines > to cache their result for each language. Otherwise they get invoked > once for the target (as in current CMake) plus once for each source file > (after the second patch). Will do. > About the name "cxx_commands.json" of the file: I'd like to hide this > away from the casual user by putting it in the CMakeFiles subdirectory. > The commands can be for compilation of any language so it should be > called something like "CMakeFiles/compile_commands.json" instead. I think that finding this file in the same spot relative to the base build directory independently of the build system used will make it a lot easier for tool-smiths / users to actually make use of it. If you want to hide it away, I'd vote for a more build system independent name than CMakeFiles. The commands are currently only for c/c++ compilation, but I'm fine with "compile_commands" to keep it flexible. > About the content of the json file: I suggest that each command also > include a "language" field indicating "C", "C++", or "Fortran". That > will help tools know how to treat the file named by the "file" field. > One might also include a "target" field indicating the name of the > logical target to which it belongs. I don't know whether this is > useful in your case or not. I'd rather keep it focused for now, and add additional things later if you're ok with that. Cheers, /Manuel ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Generating information for C++ tools in cmake (patch)
On Thu, Jan 13, 2011 at 11:43 AM, Alexander Neundorf wrote: > On Wednesday 12 January 2011, Manuel Klimek wrote: > ... >> Yes, I agree that it is very conceivable that we'll want that in the >> future - one reason I propose a JSON format is that it is both easy to >> parse and easy to extend. > > Any special reason why you choose json and not xml ? > xml is still a bit more widespread. Yes. Parsing speed matters. Tools that run will need to parse a potentially pretty big file. I don't have any numbers, so it's all based on experience I have from 5 years ago where parsing XML was painfully slow. If somebody has numbers, I'm happy to reconsider the format ... > I have two things in mind (not short term, but mid or long term): > > * have cmake write some project or buildfile which can be used as a build-tool > independent buildfile ... well, i.e. it should contain all information to > build the project (as makefiles do), be easily parseble (e.g. xml or json...) > and provide enough information for IDEs, so that e.g. QtCreator could use > this as primary project file. It should be possible that it includes not only > the commands to compile the files, but also to link, to install, to > preprocess only, etc. This would probably be the file you are writing now, > but heavily extended later on. While I see how this might be useful, it is orthogonal to the matter I'm trying to solve, and I would vote for putting it into 2 different files (again because I want the parsing to be fast). The problem I'm currently solving is "how to understand the C/C++ code in the project". What you propose would include all the dependencies, which are a pretty huge extra chunk of information. > * have cmake install some FooConfig.xml or FooConfig.json file (instead or > additionally to FooConfig.cmake), which contains information about an > installed package (like pkg-config), and which can be easily parsed by other > tools (e.g. xml or json). This is only related to what you are doing now in > that I think it should use the same markup language as that will use one day. Agreed. > I would have opted for xml, but simply because I consider it the default > choice. I don't have a real opinion on json. As I said, if you can make a good case for parsing XML files at the same speed we can parse JSON, I'm happy to reconsider. One thing we could probably do is define a subset of XML for this file and use that, which would bring parsing speed up to par, but of course would get rid of many of the reasons you would want XML in the first place. Cheers, /Manuel ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Generating information for C++ tools in cmake (patch)
On Wed, Jan 12, 2011 at 10:29 AM, Brad King wrote:
> On 1/12/2011 1:19 PM, Manuel Klimek wrote:
>> I actually don't think writing out a single text file will be
>> noticeable in the overall generation. If I assume that I can write 60
>> MB/s, I'd need a code base 250 times the size of the cmake code base
>> before hitting 1 second. Since the cmake code base seems to be around
>> 200k LOC C++ code, this would be a 50M LOC code base. I don't expect
>> one second in the generation phase to matter for such a code base.
>
> Don't bother with the option for now. It is easily added after testing.
> Please refactor your patch into multiple commits as I previously
> requested and then we can review in more detail.
Split up the patch - apparently I need ssh access to push the topic
stuff, so I'm just attaching the patches.
Cheers,
/Manuel
diff --git a/Source/cmMakefileTargetGenerator.cxx b/Source/cmMakefileTargetGenerator.cxx
index 9dcd8f1..52b6bb7 100644
--- a/Source/cmMakefileTargetGenerator.cxx
+++ b/Source/cmMakefileTargetGenerator.cxx
@@ -249,6 +249,62 @@ void cmMakefileTargetGenerator::WriteCommonCodeRules()
}
//
+std::string cmMakefileTargetGenerator::GetFlags(const std::string &l) {
+ std::string flags;
+ const char *lang = l.c_str();
+
+ bool shared = ((this->Target->GetType() == cmTarget::SHARED_LIBRARY) ||
+ (this->Target->GetType() == cmTarget::MODULE_LIBRARY));
+
+ // Add language feature flags.
+ this->AddFeatureFlags(flags, lang);
+
+ this->LocalGenerator->AddArchitectureFlags(flags, this->Target,
+ lang, this->ConfigName);
+
+ // Fortran-specific flags computed for this target.
+ if(l == "Fortran")
+{
+this->AddFortranFlags(flags);
+}
+
+ // Add shared-library flags if needed.
+ this->LocalGenerator->AddSharedFlags(flags, lang, shared);
+
+ // Add include directory flags.
+ this->LocalGenerator->
+AppendFlags(flags, this->LocalGenerator->GetIncludeFlags(lang));
+ // Add include directory flags.
+ this->LocalGenerator->
+AppendFlags(flags,this->GetFrameworkFlags().c_str());
+
+ return flags;
+}
+
+std::string cmMakefileTargetGenerator::GetDefines(const std::string &l) {
+ std::string defines;
+ const char *lang = l.c_str();
+ // Add the export symbol definition for shared library objects.
+ if(const char* exportMacro = this->Target->GetExportMacro())
+{
+this->LocalGenerator->AppendDefines(defines, exportMacro, lang);
+}
+
+ // Add preprocessor definitions for this target and configuration.
+ this->LocalGenerator->AppendDefines
+(defines, this->Makefile->GetProperty("COMPILE_DEFINITIONS"), lang);
+ this->LocalGenerator->AppendDefines
+(defines, this->Target->GetProperty("COMPILE_DEFINITIONS"), lang);
+ std::string defPropName = "COMPILE_DEFINITIONS_";
+ defPropName +=
+cmSystemTools::UpperCase(this->LocalGenerator->ConfigurationName);
+ this->LocalGenerator->AppendDefines
+(defines, this->Makefile->GetProperty(defPropName.c_str()), lang);
+ this->LocalGenerator->AppendDefines
+(defines, this->Target->GetProperty(defPropName.c_str()), lang);
+ return defines;
+}
+
void cmMakefileTargetGenerator::WriteTargetLanguageFlags()
{
// write language flags for target
@@ -262,68 +318,22 @@ void cmMakefileTargetGenerator::WriteTargetLanguageFlags()
cmStdString compiler = "CMAKE_";
compiler += *l;
compiler += "_COMPILER";
-*this->FlagFileStream << "# compile " << l->c_str() << " with " <<
+*this->FlagFileStream << "# compile " << l->c_str() << " with " <<
this->Makefile->GetSafeDefinition(compiler.c_str()) << "\n";
}
for(std::set::const_iterator l = languages.begin();
l != languages.end(); ++l)
{
-const char *lang = l->c_str();
-std::string flags;
-std::string defines;
-bool shared = ((this->Target->GetType() == cmTarget::SHARED_LIBRARY) ||
- (this->Target->GetType() == cmTarget::MODULE_LIBRARY));
-
-// Add the export symbol definition for shared library objects.
-if(const char* exportMacro = this->Target->GetExportMacro())
- {
- this->LocalGenerator->AppendDefines(defines, exportMacro, lang);
- }
-
-// Add preprocessor definitions for this target and configuration.
-this->LocalGenerator->AppendDefines
- (defines, this->Makefile->GetProperty("COMPILE_DEFINITIONS"), lang);
-this->LocalGenerator->AppendDefines
- (defines, thi
Re: [cmake-developers] Generating information for C++ tools in cmake (patch)
On Wed, Jan 12, 2011 at 10:05 AM, Brad King wrote: > On 1/12/2011 12:52 PM, Manuel Klimek wrote: >> Exporting the information in a defined way into the script language >> would be an option, too. > > Typically build rules depend on the configuration (Debug, Release). > For Makefile generators there is only one configuration, but for > Xcode and VS IDE generators several configurations are written to > the build system for selection at build time. Also, since the > functionality we're discussion will work only for Makefile generators > I don't think it makes sense to add an API in the CMake language > for this. It is also better if the analysis tools can work on > projects whose CMake code was not specifically written to support > them. Good point. >> one reason I propose a JSON format is that it is both easy to >> parse and easy to extend. > > Okay. > >> It is actually a matter of writing one extra file globally > > That makes sense. One more concern is that the size of this file > will grow linearly with the size of the rest of the build system. > Writing it could add noticeable overhead during normal generation. > It is simple enough to enable with a cache option added on the > command line though. I actually don't think writing out a single text file will be noticeable in the overall generation. If I assume that I can write 60 MB/s, I'd need a code base 250 times the size of the cmake code base before hitting 1 second. Since the cmake code base seems to be around 200k LOC C++ code, this would be a 50M LOC code base. I don't expect one second in the generation phase to matter for such a code base. As I said, I'm happy enough to put it behind a cache option though. Cheers, /Manuel ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Generating information for C++ tools in cmake (patch)
Hi Brad, On Wed, Jan 12, 2011 at 8:25 AM, Brad King wrote: > Hi Manuel, > > I think the goals of your work are important. I like the general > idea. One sure way to give such tools the same view of the code > as the compiler is to ask the build system to provide the information. > > I'm a CMake developer but I also wrote gccxml. The latter is a > code analysis tool that simulates the preprocessing performed by > a target compiler to get the same view of the code. We use it to > convert C++ header files into a .xml representation of the interface > for easy loading by interpreted language wrapper generators. > > In order to run gccxml in real projects we need to write CMake code > that uses add_custom_command to create build-time rules. Passing > the include path and preprocessor definitions requires custom code > to add them to the command line, and there is no guarantee that they > stay in sync with what the real compiler gets. This is difficult > to maintain. > > One distinction between gccxml and tools like you propose is that > gccxml has to run during the build to help generate code for the > compiler rather than running after the build to analyze the code. > However, the difficulty with running it to match the compiler > demonstrates why build system awareness is helpful. Exporting the information in a defined way into the script language would be an option, too. If we have the information for example as a readable property for source files, writing the code that exports the data in any format in the cmake file is trivial - on the other hand I'd really like to create some form of well-defined "standard" format that tools can rely on finding. One other idea that looks like it would help especially your case would be to add an extra target command called "cxx_tool" or something that serves the purpose of running tools that need the c++ command line. I'd be also happy to spend some cycles on helping to implement that for the makefile case, as we're planning on tools like "include-what-you-use" (http://llvm.org/devmtg/2010-11/Silverstein-IncludeWhatYouUse.pdf) that you might want to run during a build, too. > On 1/11/2011 5:10 PM, Manuel Klimek wrote: >> I thought about that, too. On the other hand, we might also want to >> make that information available from other generators where it makes >> sense - in my mind it is somewhat orthogonal to the generator: >> - for generators that are already very tightly IDE integrated (like >> VS) we probably don't need to output this information, as the IDE >> already exposes this information in well-defined ways that tool users >> for those IDEs would use >> - for generators that are not tightly coupled to the IDE or where the >> IDE doesn't make the build information easily accessible (like >> Eclipse), we actually want to enable developers to make the output >> "default" in their cmake build setup, so they can use command line >> tools or hand-made macros in their editor/IDE. > > CMake has 2 categories of main generators: IDE and Makefile. The > Xcode and VS generators are IDE, the rest are Makefile. Other > generators like KDevelop are actually Makefile generators plus > project files that just list source files but not build rules. > > The IDE generators (Xcode and VS) do not actually generate the > final compile lines. Therefore the proposed functionality is > possible only with Makefile generators. However, since there > is no toolchain not supported by Makefile generators that should > be sufficient. Thanks for explaining. >> No, I'm not planning to output the link commands - this is purely for >> code understanding, not rebuilding the code - while thinking about how >> to enable fast rebuilds by adding this information might have some >> valid use case, it is currently completely out of scope as far as I'm >> concerned. > > My understanding is that clang is based on llvm which is a set of > modular components for all parts of the toolchain. It is conceivable > that tools in the future may be interested in the link line to do > whole-program analysis. However, I think starting off with just the > compile information is sufficient. Yes, I agree that it is very conceivable that we'll want that in the future - one reason I propose a JSON format is that it is both easy to parse and easy to extend. >> - you use your normal cmake+(your build system) workflow for building >> - you use tools that run over source files and use the little c++ >> compile database to be able to understand the c++ code correctly >> >> As a user, I want to be able to do both without having to run cmake in >> betwe
Re: [cmake-developers] Generating information for C++ tools in cmake (patch)
Hi Alexander, On Tue, Jan 11, 2011 at 12:45 PM, Alexander Neundorf wrote: > Hi, > > On Tuesday 11 January 2011, Manuel Klimek wrote: >> Hi, >> >> we're working on C++ tools based on clang to get the power of >> automated refactoring and analysis that Java has known for years to >> C++ developers. > > Sounds great :-) > >> With the attached patch I include a proposal for how we could export >> the compile command line for C/C++ files from cmake for Unix makefile >> generators: >> The idea is to output a small JSON database with all C/C++ files in >> the project, which contains >> - the file's path >> - the working directory in which the compile runs >> - the compile command > > To me this sounds a bit like it should be a separate generator, like the > Eclipse/CodeBlocks/KDevelop generators. They generate Makefiles and > additionally project files. > This one could generate the Makefiles and additionally the json file. I thought about that, too. On the other hand, we might also want to make that information available from other generators where it makes sense - in my mind it is somewhat orthogonal to the generator: - for generators that are already very tightly IDE integrated (like VS) we probably don't need to output this information, as the IDE already exposes this information in well-defined ways that tool users for those IDEs would use - for generators that are not tightly coupled to the IDE or where the IDE doesn't make the build information easily accessible (like Eclipse), we actually want to enable developers to make the output "default" in their cmake build setup, so they can use command line tools or hand-made macros in their editor/IDE. > Do you plan to put only the compile commands into the json-file or also the > commands needed for linking the targets etc. ? > In this case, the json file could maybe used by itself as project file for an > IDE... No, I'm not planning to output the link commands - this is purely for code understanding, not rebuilding the code - while thinking about how to enable fast rebuilds by adding this information might have some valid use case, it is currently completely out of scope as far as I'm concerned. The workflow really is: - you use your normal cmake+(your build system) workflow for building - you use tools that run over source files and use the little c++ compile database to be able to understand the c++ code correctly As a user, I want to be able to do both without having to run cmake in between. This might well be hidden behind a cmake configuration option if you think it affects the standard generation too much. thanks for your feedback! /Manuel >> Background: >> While C++ refactoring and analysis tools are not compilers, and thus >> don't run as part of the build system, they need the exact information >> of a build in order to be able to correctly understand the C++ code of >> the project. The natural candidate to export that information is the >> build system. We chose cmake to provide a first implementation, as >> cmake is the current open source standard build system for large scale >> C++ projects (like clang itself), and as such it is in the best >> position to define a standard way to make compile commands accessible >> for tools in the open source world. >> >> Example tools: >> - running clang -fsyntax-only over source code from an editor to get >> fast syntax checks >> - running match/replace tools over C++ code (a project we're currently >> working on) >> >> Any feedback would be highly appreciated. If you think the way this is >> implemented is a dumb idea (which it probably is), please tell me - I >> don't have a lot of experience in the cmake architecture. Also, if you >> object to the idea of exporting this information in general, please >> let me know. > > These are only my 2 cents, what do the other cmake devs think ? ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] Generating information for C++ tools in cmake (patch)
Hi,
we're working on C++ tools based on clang to get the power of
automated refactoring and analysis that Java has known for years to
C++ developers.
With the attached patch I include a proposal for how we could export
the compile command line for C/C++ files from cmake for Unix makefile
generators:
The idea is to output a small JSON database with all C/C++ files in
the project, which contains
- the file's path
- the working directory in which the compile runs
- the compile command
Background:
While C++ refactoring and analysis tools are not compilers, and thus
don't run as part of the build system, they need the exact information
of a build in order to be able to correctly understand the C++ code of
the project. The natural candidate to export that information is the
build system. We chose cmake to provide a first implementation, as
cmake is the current open source standard build system for large scale
C++ projects (like clang itself), and as such it is in the best
position to define a standard way to make compile commands accessible
for tools in the open source world.
Example tools:
- running clang -fsyntax-only over source code from an editor to get
fast syntax checks
- running match/replace tools over C++ code (a project we're currently
working on)
Any feedback would be highly appreciated. If you think the way this is
implemented is a dumb idea (which it probably is), please tell me - I
don't have a lot of experience in the cmake architecture. Also, if you
object to the idea of exporting this information in general, please
let me know.
Thanks a lot,
/Manuel
diff --git a/Source/cmGlobalUnixMakefileGenerator3.cxx b/Source/cmGlobalUnixMakefileGenerator3.cxx
index d9a341c..92f87c9 100644
--- a/Source/cmGlobalUnixMakefileGenerator3.cxx
+++ b/Source/cmGlobalUnixMakefileGenerator3.cxx
@@ -31,6 +31,7 @@ cmGlobalUnixMakefileGenerator3::cmGlobalUnixMakefileGenerator3()
#else
this->UseLinkScript = true;
#endif
+ this->CommandDatabase = NULL;
}
void cmGlobalUnixMakefileGenerator3
@@ -139,6 +140,17 @@ void cmGlobalUnixMakefileGenerator3
}
//
+std::string EscapeJSON(const std::string& s) {
+ std::string result;
+ for (int i = 0; i < s.size(); ++i) {
+if (s[i] == '"' || s[i] == '\\') {
+ result += '\\';
+}
+result += s[i];
+ }
+ return result;
+}
+
void cmGlobalUnixMakefileGenerator3::Generate()
{
// first do superclass method
@@ -189,6 +201,35 @@ void cmGlobalUnixMakefileGenerator3::Generate()
// write the main makefile
this->WriteMainMakefile2();
this->WriteMainCMakefile();
+
+ if (this->CommandDatabase != NULL) {
+*this->CommandDatabase << std::endl << "]";
+delete this->CommandDatabase;
+this->CommandDatabase = NULL;
+ }
+}
+
+void cmGlobalUnixMakefileGenerator3::AddCXXCompileCommand(
+const std::string &sourceFile, const std::string &workingDirectory,
+const std::string &compileCommand) {
+ if (this->CommandDatabase == NULL)
+{
+std::string commandDatabaseName =
+ std::string(this->GetCMakeInstance()->GetHomeOutputDirectory())
+ + "/cxx_commands.json";
+this->CommandDatabase =
+ new cmGeneratedFileStream(commandDatabaseName.c_str());
+*this->CommandDatabase << "[" << std::endl;
+} else {
+*this->CommandDatabase << "," << std::endl;
+}
+ *this->CommandDatabase << "{" << std::endl
+ << " \"directory\": \"" << EscapeJSON(workingDirectory) << "\","
+ << std::endl
+ << " \"command\": \"" << EscapeJSON(compileCommand) << "\","
+ << std::endl
+ << " \"file\": \"" << EscapeJSON(sourceFile) << "\""
+ << std::endl << "}";
}
void cmGlobalUnixMakefileGenerator3::WriteMainMakefile2()
diff --git a/Source/cmGlobalUnixMakefileGenerator3.h b/Source/cmGlobalUnixMakefileGenerator3.h
index cdc9460..a152e01 100644
--- a/Source/cmGlobalUnixMakefileGenerator3.h
+++ b/Source/cmGlobalUnixMakefileGenerator3.h
@@ -112,6 +112,10 @@ public:
/** Record per-target progress information. */
void RecordTargetProgress(cmMakefileTargetGenerator* tg);
+ void AddCXXCompileCommand(const std::string &sourceFile,
+const std::string &workingDirectory,
+const std::string &compileCommand);
+
protected:
void WriteMainMakefile2();
void WriteMainCMakefile();
@@ -178,6 +182,8 @@ protected:
size_t CountProgressMarksInTarget(cmTarget* target,
std::set& emitted);
size_t CountProgressMarksInAll(cmLocalUnixMakefileGenerator3* lg);
+
+ cmGeneratedFileStream *CommandDatabase;
};
#endif
diff --git a/Source/cmMakefileTargetGenerator.cxx b/Source/cmMakefileTargetGenerator.cxx
index 9dcd8f1..c14b789 100644
--- a/Source/cmMakefileTargetGenerator.cxx
+++ b/Source/cmMakefileTargetGenerator.cxx
@@ -249,6 +249,62 @@ void cmMakefileTargetGenerator::WriteCommonCodeRules()
}
//
