Buildset vs. Selection

[Andreas Pakulat]

On 17.01.09 23:30:37, Kishore wrote:
> On Saturday 17 Jan 2009 5:45:16 pm Andreas Pakulat wrote:
> > On 17.01.09 17:12:27, Kishore wrote:
> > > 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?

Those dependencies would be stored in kdevelop's "metadata" (i.e. .kdev4/
config files)
 
> > 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.

Thats simply too much state. A project is either open, then you want to
work on it, or closed. I don't see any reason to introduce a third state,
which all plugins would need to handle then as well. 

Andreas

-- 
Things will be bright in P.M.  A cop will shine a light in your face.