state info, project management

[Gerard Jungman]

Bernd Gehrmann wrote:
> The core of the problem is that KDevelop uses its own project
> files and generates Makefiles from that. The only approach
> which would _really_ solve the problem is to use Makefile.am's
> as the native project file format. I've made some experiments
> with this approach, but gave up after a short time. It works
> well for 90% of the project targets, but the remaining 10%
> make it horribly complicated.

I agree. I tried this once myself a couple years ago. No fun.

But the point I am trying to make is a little different. One way
to say it is that, at a certain minimum level of functionality
(a base for the project concept (?)), the IDE should not tangle up
its state with the state of the sources, but should float above
them, in a kind of nearly stateless limbo -- a kind of read-only
view of the project directories. I will explain this in detail
below with a (longwinded) example.


>> Another use is when you want to browse somebody else's sources, but not
>> make any changes. Then you have no need to create any persistent state
>> info,
>> and you probably don't want to either.
>
> Right. Now look at a typical KDE Makefile.am. It contains stuff
> like this:
> 
>   SUBDIRS = $(TOPSUBDIRS)
> 
>   $(top_srcdir)/configure.in: configure.in.in $(top_srcdir)/subdirs
>         cd $(top_srcdir) && $(MAKE) -f admin/Makefile.common configure.in ;\
>         if test -d kfloppy; then \
>           (cd kfloppy/e2fs && autoconf) \
>         fi   
>
>   install-data-local:
>         $(mkinstalldirs) $(appsdir)
>         $(INSTALL_DATA) $(srcdir)/support/karm.desktop $(appsdir)
>
> Any good idea how to manage this? I have not.
>
> Bernd.

I think what I am saying is simpler than this. That's why I wanted
to make the point about decoupling as much as possible the project
management from other functions such as source browsing and editing.

I am suggesting a kind of lightweight usage mode, where the IDE
manages as little state as possible, and basically just acts
as a source browser which knows how to talk to the editor and
how to type 'configure; make' for me. This in itself would
be progress (fiddling with emacs is not a solution for me;
I used it for years, never liked it, and I personally think
all those emacs fiddlers are a bit odd... an IDE should not be a
part of your editor, your editor should be a part of an IDE... and
don't even get me started on emacs-lisp... ACCKKKK).

This may seem trivial, but it is not easy to make the current
version act this way, since projects as implemented are too
heavyweight a concept.

One way to say it is that currently the distinction between
project types is centered on the creation of the projects
and the functionality of the wizard. After they are created,
they more or less act the same, as far as I can tell. But
really I would want to have different kinds of projects,
in terms of how they are treated, not just how they are created.
The focus on creation of projects tends to obscure the distinction
between the state of the sources and the management state,
causing them to get tangled up, which I already mentioned.
Thinking about cooperating with developers who do not
use the IDE helps make it clear what the minimum lightweight
functionality is.

Here is a longwinded description of a real session:

Say for the moment that I had an existing project, with
automake/configure stuff already set up, possibly stored
in a remote repository. I get the files and put them in
a directory called foobar, which is the name of the project.
First I want to let kdevelop know about the files, so I go to
the wizard and select "custom project". I turn off "GNU standard files"
since I have all that stuff. I try to create the custom project
named "foobar", but I am not allowed to create a project in
a directory which already exists. Ok, makes sense for most projects,
though it is annoying here. So I 'mv foobar foobar-orig' and continue.
Note that it insists the projectname is "Foobar" instead of "foobar",
and nobody likes computers to tell them what to do; nevermind, go on
and assume it will not affect anything.
The wizard creates the subdirectory foobar/foobar, which is annoying
because it has nothing to do with my existing source. I want to remove
that subdirectory, but that's where the templates are stored.
Ok, I will leave it there for now, since I spent the time to
customize the templates and I kinda like them. So now I try
to add the source files. My original source tree has a single
subdirectory called src/. I go to "add existing files" and try to
add "$HOME/foobar-orig/src" to "$HOME/foobar". The message says
"You must choose a destination, that is in your project-dir!". Ok,
I have no idea what that message really means. I try to
add "$HOME/foobar-orig/src/*" to "$HOME/foobar/src"; the message
says "You must choose a valid dir as a destination". Ok, that I
understand;
'mkdir foobar/src'. Now "$HOME/foobar-orig/src/*: file does not exist".
Hmmm. Ok, go through the file selection dialog; ignore the fact that
the file selection list does not scroll automatically when I am doing
a multi-select... that's not kdevelop's problem specifically, though
it is highly annoying. Ok, so it copies all the files, applies the
templates, and parses them. Minor problem, the cursor seems to
be stuck with the watch icon anywhere outside the editor window.
Nevermind. Now I can browse the source and edit. Good.
Let's say I change a couple files and add some files.
This part all works fine. Now I commit my changes to the remote
repository and quit for the day. I do not commit the .kdeprj file,
since it has no meaning for my collaborators.
The next day 'cvs update' my sources.
Now I have to carefully check if anybody has added files,
because I need to use the "add existing files" function when
I start kdevelop; not good. And, of course, if I lose the .kdeprj
file, I am screwed and have to go through the whole business
over again.


Now instead imagine the following scenario:

I have my source files as at the start above, in a directory
called foobar. I start kdevelop and go to "new project". But
there I select "new lightweight project". It asks for the
project directory, and I tell it "foobar". It asks if it should
scan all subdirectories recursively, I say yes. It asks if
any files should be left unscanned, I say "no" for the moment,
since that is the case. Then it goes forth and scans all the source,
creating the browser information. It remembers the names of all the
files
it scanned, relative to the project root directory. It also remembers
which files it was told to ignore. It stores this information, not
in a .kdeprj file in the project directory but somewhere appropriate
in the $HOME/.kde/ hierarchy. All it remembers is file names.
It can also store the template files in the same place, outside the
project
itself. Now I work on the project, commit my changes, possibly releasing
and wiping out the project directory. The next day I check it
out again, start kdevelop, and open the lightweight project,
possibly telling it which directory is the project root since
it might have changed. It looks at its list of files for the project,
both the "scan" list and the "ignore" list and compares it to the files
in the project. If there are files in the project directory
which are not on either the scan or the ignore lists, it asks if
they should be added to the scan list and scanned.
If some files have been removed from the project directory, it removes
them from the scan list.

Very simple, and effective for the case at hand. There is very little
state to manage, and it can never get out of synch. Furthermore, it
doesn't tangle up its state with the state of the sources, which I
think is very important; the IDE should just float above everything
in this case.

This is the sort of minimum functionality that I think could form
the base of the design. More involved and stateful scenarios, like
the current design's project concept, can be layered on top of that
minimum functionality. I think this would be a good orthogonalization
of the different IDE functionalities and would lead to a very flexible
environment.


Anyway, I hope you had the patience to read all that. It's a simple
enough observation, but I wanted to state it as clearly as I could.

Thanks.

--
G. Jungman