Wishlist - better project management

[Ralf Nolden]

On Tuesday, 21. August 2001 06:53, you wrote:

Hi,

thanks for your comments. If you have a look at the HEAD version (3.0), there 
have been some improvements on this done already. As mentioned earlier, the 
usability and the C/C++ compiler settings will be changing in September there 
when I have more time. If you have some minutes then I would be pleased for 
any help there as I don't own a copy of VC++ to have any comparison. So your 
comments on how to make things easier would help a lot here :)

Ralf

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

-- 
We're not a company, we just produce better code at less costs.
--------------------------------------------------------------------
Ralf Nolden
nolden at kde.org

The K Desktop Environment	The KDevelop Project
http://www.kde.org		http://www.kdevelop.org


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