state info, project management

[Bernd Gehrmann]

On Sat, 02 Oct 1999 Gerard Jungman wrote:
>If I 'cvs update' my sources, which contain committed changes from
>a non-IDE collaborator, obviously any previous project state in my
>sandbox will become irrelevant and possibly dangerous.

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. 

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