TODO

[Roland Krause]

Anatoly, I can hardly agree more about what you said. Being in a very
similar position as you, I got sucked up in trying to improve the
situation myself. I would like to encourage you to join in and maybe
fix the one or other bug or report a crash whenever one occurs.
Stabilization was the major goal from version 1.4 to 2.0 and
implemantation of new features to version 2.x has actually stopped for
the most part. 

However your analysis is quite correct in many points and here are some
comments from another user and part time developer/bug fixer to the
KDevelop-2 version. 

--- Anatoly Korzun <anatoly at callsys.co.uk> wrote:
> 1. Something like a workspace and projects, 
> or a project and subprojects.

This is at present not really possible. It would require a real concept
of a project and such workspaces, which simply does not exist in the
current stable code base. 

> 2. More control over creating static and shared 
> libraries.

automake is actually much simpler as autoconf and libtool. However
these tools have aquired a level of complexity that is quite hard to
understand. Again, the stable code base doesnt really provide any
infrastructure to accomplish some advanced, highlevel editing of
automake projects. The unstable development version of KDevelop aka.
gideon has a much better project management system, although the notion
of a workspace doesnt really fit with most Unix based codebases,
instead, in an automake project you can indeed have multiple binaries
being created and arbitrary combinations of shared and static
libraries. Automake is your tool, what's missing is really a good UI
based frontend . 

> 
> 3. Something that would easily allow (without 
> hacking Makefiles) creating custom build steps 
> for certain files (e.g. running flex, bison, awk, 
> sed, etc.)
>

Here is where automake's possibilities actually end and the power of
autoconf starts. An advanced project management frontend is certainly
the way to go. Shell scripting is already possible. But you will have
to create the scripts by hand.
 
> 4. More choice (or better to say at least some 
> choice) in selecting compiler. I have a big respect 
> to GCC, but sometimes you HAVE to use something 
> different. E.g., GCC doesn't support 64-bit. 
> You can see a similar thing in DDD debugging tool.
>

The latest version of the stable code base has this feature. Please
give it a spin and see what's missing to make it work with SUN's CC
e.g..
 
> 5. Some improvements in working with CVS. Currently 
> you cannot add a new directory to CVS inside KDevelop 
> (at least I was unable:-), you have to do in a 
> command line, and then return to KDevelop to add 
> new files. I also don't see any way to check out 
> any new stuff to the existing project. Ideally 
> it's good to do with CVS everything you can do 
> from a command line while staying in KDevelop.
>

Get cervisia from cervisia.sf.net, add it to your tools menu. Then you
have the equivalent of MS SourceSafe w/o the pricetag and the
"undocumented features".
An alternative to cervisia is LinCVS also available from sourceforge. 
  
> 6. Some tool for creating .pkg (rpm doesn't exist 
> everywhere:-) would be appreciated.
> 
> 7. Finally something that may look like profaning 
> the holy thing. I mean automake and autoconfig. 
> For me (a person who had spent most time on Windows:-) 
> it seems that the whole approach creates more 
> problems than solves.

No. It is more like, "the problem is much, much bigger than it
appears". Fortunately, most Unix platforms are in rapid retreat and we
are going to be left with Linux, Solaris, AIX, OSX and some "free" BSD
flavors. So this is a minimum of 5 platforms, not to mention the
deversification that already is taking place between the Linux
distro's. 
These problems do not exist on the Windows platform. But then "free
software" doesn't exist much either. 
Autoconf needs a replacement, or an understandable, UI based frontend.
Unfortunately, there are no serious contenders in sight. 

> So, why not using just a PLAIN MAKEFILE? 
> Correct me if I am wrong.

Yes, that is already possible, you can have a custom project. I have an
older UI frontend that I wrote for my former employer that allows you
to do exactly that. Unfortunately it never made it into the stable code
base due to some unforeseen circumstances. But I still have it and
could add it. Here's a screenshot of what was there:
http://klondike.dyndns.org/Pictures/kdevelop/customPrjOptions.png.

> I realize that your product is like a gift to other 
> people, so no one can demand anything from you. 

No, but you are heartily invited to share it with us and to help us
make it even better.
Get involved, many small steps make huge improvements possible. 

> I also guess that different people ask you for 
> different things, including support for other 
> languages.

Yes, the ability to use other languages as well as the ability to use
different compilers is actually quite important. SO if people want to
contribute in this direction, and they already did (we have Java,
Objective C, php and python support in the development version) they
are free to do so.  

> However I kindly ask you to focus at C++.

Some of us will still focus on C,C++ and maybe some Fortran, others do
what they need to do. 

> 
> Best regards,
> Anatoly
>  
Your input is greatly appreciated.
Roland



__________________________________________________
Do You Yahoo!?
Check out Yahoo! Shopping and Yahoo! Auctions for all of
your unique holiday gifts! Buy at http://shopping.yahoo.com
or bid at http://auctions.yahoo.com