Buildset vs. Selection

[Andreas Pakulat]

On 17.01.09 17:12:27, Kishore wrote:
> On Saturday 17 Jan 2009 1:04:41 pm Andreas Pakulat wrote:
> > On 16.01.09 23:17:45, David Nolden wrote:
> > > I think ideally the build-set and selections should somehow be
> > > integrated, so everything is totally clear.
> > >
> > > If you have a build-set then you should always build that. It should not
> > > be possible to hide the build-set widget when the build-set is not empty.
> > >
> > > When you don't have content in the build-set, then the current selection
> > > should be "mirrored" in the build-set widget in grey, so it's always
> > > clear what you're about to build.
> > >
> > > Then you could have a single button to convert the selection into a
> > > "real" build-set.
> >
> > That would make it quite a bit clearer when you're building what, nice
> > idea.
> 
> I also think there should be an easy way to order the sequence of builds for 
> multiple projects. Actually, I think it is a little more complex when the 
> dependency requires that one project be built and installed before it can be 
> built.
> 
> Like for example, kdelibs requires that kdesupport is built _and_ installed 
> before kdelibs itself. I don't know how such requirements can be managed in a 
> clean way. Sorry if this has already been thought of and discussed.

We don't want to do too much dependency tracking ourselves in KDevelop,
most of it should be done by the buildsystem. 

Hence what I planned (not necessarily for 4.0, but definetly for 4.1)
was to allow for defining dependecies between projects in KDevelop. Then
the buildset would automatically re-arrange itself when an item is
added/removed to keep those dependecies intact, i.e. if you have 2
targets from kdelibs and two from kdevelop you'd get the kdelibs ones
first and the other two second.

On top of that, if there are two targets A and B coming from two
different projects and B follows A in the order, kdevelop would
automatically install A instead of simply building it. On top of that,
this would also happen for a possible target C belonging to the same
project as A. 

I don't want a full install on whole projects as that might built parts
the user doesn't want to build. Also automatically adding to the
buildset is IMHO too annoying, I sometimes just open a project to have a
quick look at it, without wanting to build it.
 
> I have a couple of additional related thoughts too. I think it would help to 
> have a selection check box for each project in the project tree. When a new 
> project is added it is automatically selected too. But when unselected, all 
> associated targets in the buildset are also greyed out and hence neither built 
> not installed. Even the code completion cache for these projects could be 
> dumped in order to save some memory and not clutter the quick open dialog with 
> too many files.

No, we don't want "active project" state, thats incomprehensible to most
users as KDevelop3/Automake showed.

Andreas

-- 
You should go home.