Wishlist - better project management

[Dan Johnston]

I am not a member of this list, so please send any replies directly to me.

I have generally been disappointed with every unix IDE I've ever used.  As a 
VC++ (I know, boo boo, hiss hiss) developer, nothing in the Unix realm has 
come as close to feeling natural to use as kdevelop has (great job guys).  I 
do have one request, however.  One of the things that VC++ does exponentially 
better than KDevelop does is project management.

One of the best things about visual studio is the fact that you never have to 
edit a Makefile.  Allmost all compiler options are set via the project 
settings dialog.  It supports differentiation between projects (a single 
compile target like a library or application) and a workspace (a collection 
of projects).  It supports the ability to specify different compiler and 
linker options based on what type of build you are doing (debug, release, 
profile, custom, etc.).  Since probably >99% of all users of KDevelop use GNU 
compilers, something like this should at least be an option, at least for 
common settings.   In fact, I don't see why the entire project framework that 
Microsoft uses couldn't be used whole-turkey after being retargeted for GNU 
compilers and decent scripting languages (for Post or Custom build steps).  
You could even make the translation between common dialog settings and actual 
compiler options be a component that could be implemented for different 
compilers.

This doesn't preclude using the current form of project management, just be 
added as an option.  Anyway, that is my pie in the sky request.  My more 
immediate request, should be a simple one.  Why, oh why, for the LOVE OF GOD, 
do you require that new custom projects be created in a new directory and 
that importing existing files into the project causes them to be copied into 
this new directory.  The whole reason for using a custom project is that you 
want to use KDevelop to edit an EXISTING project with already configured 
Makefiles, source control, etc.  Requiring that these files be moved to a new 
directory is ludicrous.  I've gotton around this by doing the file import, 
deleting the copied files, and then hacking the project file to refer to the 
origingal file set.  To be honest, the only reason to really import the files 
is to make the class browser work, but it would be nice if this would just 
work without having to go over major 50meter high hurdles.

All in all, I like KDevelop, it's still a relatively young product and I'm 
sure it will get better with age.  However, if you want to attract more 
commercial interest development on unix (maybe you don't ?), the tools should 
be as easy to use (if not more so) than what Microsoft is selling.  And 
maybe, just maybe, not every wizard should be targeted towards a source 
distribution.

Opposing viewpoints welcome :)

-dan
goblue at ve3d.com

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