Ordering the build set

[Ivan Shapovalov]

On 16 октября 2012 01:37:44 Andreas Pakulat wrote:
> Hi,
> 
> On Mon, Oct 15, 2012 at 7:10 PM, Aleix Pol <aleixpol at kde.org> wrote:
> > On Mon, Oct 15, 2012 at 7:05 PM, Ivan Shapovalov <intelfx100 at gmail.com> 
wrote:
> >> Seems that our build set ("Project Selection") doesn't keep the order of
> >> items added to it across kdevelop restarts. Actually, added items of
> >> each project are written to the project file when the project is closed,
> >> and added back when it's loaded again. So, when kdevelop is started,
> >> items are positioned in the same order in which the projects are
> >> loaded...
> 
> I don't see a problem with that, there is no relation between the
> projects in KDevelop - and thats intentional.
> 
> >> And, if one works on interdependent projects (especially when kdevelop
> >> crashes too often due to issues with qtscript), that could be really
> >> annoying.
> >> 
> >> So I propose three possible solutions:
> >> 
> >> 1. Implement a GUI of "item dependencies"; store dependencies in project
> >> files themselves; on project load try to satisfy dependencies for each
> >> item.
> This is wrong IMHO. KDevelop is not a build-system and hence there is
> intentionally no support for managing project-dependencies. If you
> want to setup dependencies between your projects use a buildsystem
> that does this and open that in kdevelop (for example with cmake's
> external project support).

At least, kdevplatform-kdevelop pair doesn't use these possibilities...

> 
> >> 2. Same as (1), but automatically add all items which are before X to X's
> >> dependencies.
> 
> See above, KDevelop is not supposed to handle project dependencies -
> at least at this point. Starting to add support for that will open a
> can of worms.
> 
> >> 3. Store the (ordered) list of "all items in build set" on a per-session
> >> basis.
> 
> If its really necessary to have a global ordering of items, then do it
> this way. It does break the idea of sharing build-sets among
> developers as well as making it harder to use the same build-set in
> different sessions. (I had separate sessions for
> kdevplatform+kdev-custom-buildsystem and kdevplatform+kdevelop but
> sharing the build-set from kdevplatform).

This idea is actually independent of and orthogonal to sharing the build sets 
in project configuration files. I'm not going to remove [Buildset] section 
from .kdev4/$projectname.kdev4, but rather add a second list of build items to 
the session config. So it will not break build set sharing (and, hopefully, 
other paradigms) in any way.

> 
> >> Whether to remove the items from that list is subject to discussion; we
> >> may
> >> remove them never (thus keeping a full history), or remove when user
> >> explicitly removes an item. Note that keeping that list in sync with the
> >> actual build set is senseless - then we'll lose all ordering information
> >> when a session is closed.
> 
> I don't get any of that. If you store the build-set in the session,
> then you get a list. If the user removes an item from the buildset you
> need to remove it from the stored list. If the user closes a project
> then all items from that project need to be removed from the buildset.
> I don't see any way of keeping 'removed' items in an on-disk store,
> thats just confusing IMO.

It's needed to keep the items in ordering list unless user explicitly removes 
them from the build set. Otherwise, when a project is closed, its build items 
will be removed from both the build set and the ordering list, and when a 
project is then reloaded, all ordering will be lost.
OTOH, when user explicitly removes an item, it actually makes sense to also 
remove it from the ordering list.

Regards,
Ivan.