Buildset vs. Selection

[Kishore]

On Saturday 17 Jan 2009 11:30:37 pm Kishore wrote:
> 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.

I made a little program to demonstrate what I mean. Its just to give an idea. 
I wanted to do a reorder in the build set but I don't know how to do that yet.
-- 
Cheers!
Kishore
-------------- next part --------------
A non-text attachment was scrubbed...
Name: buildset.tar.gz
Type: application/x-compressed-tar
Size: 3362 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20090118/dcd58878/attachment.tar.gz>
-------------- 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/20090118/dcd58878/attachment.sig>