Buildset vs. Selection

[Kishore]

On Saturday 17 Jan 2009 5:45:16 pm Andreas Pakulat wrote:
> 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.

How would kdevelop understand such dependency? like if kdelibs were one 
project and kdebase were the other, how would kdevelop know that it needs to 
build and install kdelibs before kdebase?

> 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.

Sorry if I were not clear enough but I am not inclined towards the active 
target concept of kdev3. Let me try to explain again. Currently. there are two 
states for a project. Either is open or it is closed. When a project is open, 
one can edit its sources and take advantage of all features such as code 
completion, quick open... etc. But when the project is closed, it is not 
visible but for the "Recent projects" menu. What I am suggesting is an 
intermediate third state where the project is closed but not removed. To work 
on the project, the user has to check it and uncheck it if otherwise.
-- 
Cheers!
Kishore

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20090117/2c393668/attachment.sig>