Ordering the build set

[Andreas Pakulat]

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

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

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

Andreas