AW: AW: C/C++ projects don't work for suse 7.2, suse7.3 and upcoming kdevelop 2.0.2

[Markus Kuehni]

Walter wrote:

> To finish my 2.000001 cents:
> WANTED code which updates Makefile.ams, Makefile.(dist|cvs),
> configure.in(.in) and admin-dir (and also considering the actual content
> of the old files or using *.kdevprj).

Hi

I'm pretty new to KDevelop and much of U*X, so please forgive me (and tell
me) if the following is naive:

What always bugs me with these auto*-approaches is the ballast you have to
carry with you. One of the biggest difficulties for a newbie is simply
finding out which files are input and which are output in all that clutter
(*.in.in.in).

In most cases of KDevelop-ed projects (from scratch) all you'd need to save
is

1. the wizard template type used to boot-strap the project
2. a list of the file added afterwards
3. the settings set through one of KDevelops dialogs

Of course I know you can directly go to the auto*-files and change things,
but if I *don't* *want* *to* , I should be able to let KDevelop know.

There should be a global option called "let KDevelop manage my project"
which operates only on the above input and if necessary (when tools and
templates change) re-generates/overwrites all auto*-files.

This way a "pure" KDevelop project (within the concept of one of the wizard
templates) could be distributed in a very compact and abstract form that is
capable to evolve and adapt to different platforms (Windows, one day?).
There would just be the .kdevprj file (minus the auto*-files content),
ChangeLog & Co. and the real source files.

Please don't misunderstand me: I know auto*-tools are very powerful and
valuable for distribution and configuration and they should still be used in
the background (on U*X).

-- Mark


-
to unsubscribe from this list send an email to kdevelop-devel-request at kdevelop.org with the following body:
unsubscribe »your-email-address«