Rough KDevelop 4.6 Planning

[Sergey Vidyuk]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20121225/9b7aec0a/attachment.sig>