Hi Doug, any chance I could get this reviewed? I have another feature for the compilation database (correctly handling relative directories) that I would like to implement in the new structure.
Cheers, Daniel On Mon, Jul 23, 2012 at 1:11 PM, Daniel Jasper <[email protected]> wrote: > Any thoughts on this design? > Cheers, > Daniel > > > On Fri, Jul 20, 2012 at 2:11 PM, Daniel Jasper <[email protected]> wrote: > >> I moved the class-comment back and properly propagated the error instead >> of printing it to outs(). I don't know about using Diagnostics. Could we >> get to that in a different patch to clearly separate those changes? >> >> Cheers, >> Daniel >> >> >> On Fri, Jul 20, 2012 at 12:41 PM, Manuel Klimek <[email protected]>wrote: >> >>> I'd like the class-comment for JSONCompilationDatabase to still >>> include what's now in the file comment, so it's visible in doxygen. >>> >>> Also, I'd prefer to use a result value to capture the error message >>> instead of llvm::outs'ing in findCompilationDatabaseFromDirectory. >>> Perhaps we should also switch this to Diagnostics? >>> >>> Cheers, >>> /Manuel >>> >>> On Fri, Jul 20, 2012 at 12:30 PM, Daniel Jasper <[email protected]> >>> wrote: >>> > Attached is a patch to do most of this restructuring, kindly asking for >>> > review. >>> > >>> > In particular, it does: >>> > - Restructure the compilation database architecture to using LLVM's >>> registry >>> > concept. It should now be possible to link in additional compilation >>> > databases. >>> > - Separate the JSONCompilationDatabase from CompilationDatabase to >>> show the >>> > loose coupling and serve as an example. >>> > >>> > >>> > >>> > >>> > On Thu, Jul 19, 2012 at 3:17 PM, Stephen Kelly <[email protected]> >>> wrote: >>> >> >>> >> On 07/19/2012 01:32 PM, Manuel Klimek wrote: >>> >> > On Thu, Jul 19, 2012 at 1:10 PM, Stephen Kelly <[email protected]> >>> >> > wrote: >>> >> >> Chandler Carruth wrote: >>> >> >> >>> >> >>> That said, the latest version of CMake already has support for >>> JSON + >>> >> >>> Ninja -- we didn't contribute it, so I don't know what strategy >>> they >>> >> >>> followed, but you should look at that and talk to the ninja and >>> CMake >>> >> >>> developers before going too far here. >>> >> >>> >>> >> >> I wrote it and pretty much followed the same thing Manuel did in >>> the >>> >> >> Makefile generator. >>> >> >> >>> >> >> The commit which actually adds the feature is trivial: >>> >> >> >>> >> >> >>> >> >> >>> http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=db839bec7d076b54c5e9ad0d19386a26557a509e >>> >> >> >>> >> >> Manuel mentioned before that he'd like to see ninja being able to >>> >> >> generate a >>> >> >> database without cmake too though: >>> >> >> >>> >> >> >>> >> >> >>> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/3678/focus=3697 >>> >> >> >>> >> >> As Chandler said, it's not in a release yet, but will be in the >>> next >>> >> >> release >>> >> >> in a few weeks. Feel free to test the release candidate (I would >>> >> >> appreciate >>> >> >> if you did) >>> >> > I know multiple people who are refusing to work without this any >>> more, >>> >> > I've been using it since it landed in "next". So consider this part >>> >> > pretty well tested (at least on the llvm codebase). >>> >> > >>> >> >>> >> Good to hear :) >>> >> >>> >> Thanks, >>> >> >>> >> Steve. >>> >> >>> >> _______________________________________________ >>> >> cfe-commits mailing list >>> >> [email protected] >>> >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits >>> > >>> > >>> >> >> >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
