Rough KDevelop 4.6 Planning

[Ivan Shapovalov]

On 25 December 2012 00:31:59 Sergey Vidyuk wrote:
> On Sunday 23 December 2012 20:51:35 Ivan Shapovalov wrote:
> > On 18 December 2012 20:45:10 Milian Wolff wrote:
> > > Hey there, while we are talking about 4.5, I'd like to get some input on
> > > what you think we should do for 4.6 eventually.
> > > 
> > > Personally, for 4.6, I hope to land the two big refactorings I'm working
> > > on
> > > currently:
> > > 
> > > On one hand the Path stuff in the sharedurls branch which promises a
> > > much
> > > more straight forward *and* efficient (local/remote) Path handling in
> > > KDevelop.
> > > 
> > > Secondly, I started another interesting refactoring on the weekend
> > > related
> > > to our ItemRepositories. Looking some more at IndexedString, I managed
> > > to
> > > cleanup its API (removing potential encoding pitfalls) while also
> > > speeding
> > > it up quite considerably (about factor of 2 for string serialization,
> > > and
> > > about 20% for string deserialization). I will concentrate on landing the
> > > IndexedString refactoring first, then also hope to repeat the
> > > optimizations
> > > there for the other item repositories, and - while at it - cleaning up
> > > the
> > > mess of code that is itemrepository.{h,cpp}. I'm confident that by
> > > writing
> > > tests and using our existing tests, I can keep this working without any
> > > big
> > > breakages.
> > > 
> > > These two should result in a very noticeable performance gain, both
> > > memory
> > > and speed wise.
> > > 
> > > After that is done, I hope to have some time to investigate the
> > > "KDevelop
> > > commandline" idea we had at the Vienna sprint - lets see.
> > > 
> > > What do you guys have in mind?
> > > 
> > > Cheers
> > 
> > Hi!
> > 
> > For now I'm planning, like Kevin, to focus on general quality and, in
> > particular, on code quality (i. e. refactorings). So far I'm going to:
> > 
> > 1) Implement some kind of better history+multiple output view (as
> > discussed
> > here some time ago) - but still thinking on how to do it optimally;
> > 
> > 2) Integrate build view and problem reporter;
> > 
> > 3) Complete my WIP on job classes (which began with OutputExecuteJob and
> > cleaning up builder jobs) - that is, factor out common base of VCS job
> > classes and clean them up;
> > 
> > 4) Do something with Git plugin which has already been noted here as a big
> > structural mess;
> > 
> > 5) Introduce "generic build configurations" (now there are build
> > directories in CMake and build configurations in kdev-custombuildsystem)
> > - and make the corresponding controls in the UI like launch
> > configurations currently have;
> > 
> > 6) This probably won't be done for 4.6: write a supplemental "KDevelop 4"
> > generator for CMake (pushing it upstream there) and write an alternative
> > project manager plugin which will read generated file with per-target and
> > per- directory properties instead of parsing CMakeLists files, achieving
> > the exhaustive compatibility at almost no cost. ;)
> > 
> > Notes: The idea behind (5) is fast "Debug"<->"Release" switching, and the
> > one behind (6) is that I can't make existing CMake plugin to resolve
> > "#include <QFile>" and I doesn't feel that fixing a hand-built
> > fundamentally incomplete parser is a right thing to do when there is an
> > existing reference implementation. (Also, our CMake support doesn't
> > handle
> > cross-compilation well.)
> > 
> > Cheers!
> > 
> > - Ivan Shapovalov
> > _______________________________________________
> > KDevelop-devel mailing list
> > KDevelop-devel at kde.org
> > https://mail.kde.org/mailman/listinfo/kdevelop-devel
> 
> Hi
> 
> Few ideas regarding the 6th feature.
> 
> I was thinking about some C library which works with build graph and store
> data in some formal (probably even binary) format from the time I was
> working with scons. This library can be used by build system to populate
> build graph using data from their build scripts and by IDE to know directly
> what is going to be build and which sources are used to build it.
> 
> This library can be used by various IDE and Build system. It should handle
> optimal buld strategy (in order to determine what should be built and what
> not) and optimal parallelization strategy. It should provide predictable
> minimal incremental buld like scons or tup. In other words it should be a
> tool which do one thing but do it great.
> 
> Few month ago I looked through the tup (http://gittup.org/tup/) code in
> order to check if it's simple to split it into tupfile script processor and
> buld graph manager lib. But after digging for a while I decide to play with
> some simple project to uderstand better which interface do I want to have.
> My last patches to KDevelop were actually made in order to fix some issues
> I expirienced during the work with this pet project :)
> 
> My vision of this project is:
>  * library to work with graph and run build + application to run the build
> from command line. Most likely based on tup code in order to not reinvent
> the wheel.
>  * cmake generator
>  * KDevelop plugin
> So looks like exactly what you are talking about.
> 
> I have not too much time to work on open source projects so don't know about
> how long will it take for me to implement. Hope to have some code to
> publish (some experimental probably not yet usable state) around february.
> 
> Sergey

Hm... If I understand you correctly, you are describing a minimalist builder 
application. Actually, there is one already, called ninja.

And I mean a slightly different thing. The generator I'm going to implement 
won't focus on dependencies, parallelization and topology - there is already 
ninja+make for that, and KDevelop doesn't need to provide the same functions 
once again.
Instead, I want the generator to export data in a following manner (XML-like):

<directory path="/path/to/source/directory">
 <define name="SOMETHING" value="1" />
 <includedir path="/usr/include/something" />
 <includefile path="/path/to/config.h" />
 <compiler path="/usr/bin/i486-mingw32-g++" type="gcc" options="-std=c++0x" />
</directory>

...Which can then be easily used by our semantic subsystem without need to 
walk and thoroughly parse CMakeLists.txt.

- Ivan