[despammed] kdevelop.kdevelop

[Izo]

Falk Brettschneider wrote:

>Hendrik, the last official KDevelop version was KDevelop-2.1. And there, it
>was exactly as I want it back again now. The project files of KDevelop-2.x
>don't contain user-specific settings, all such stuff is swapped out to the
>appropriate .kdevses file or kdeveloprc. 
>
The idea is/was good but in KDevelop-2.1.x there were build 
configurations and IDE/GUI state in the kdevses. The build 
configurations are not only the builds as debug/default/tight etc etc 
covering only one build and/or host and reflect only single developers 
ideas - there could be more: I am working on the project where I must 
make builds for various hosts (ix86, ARM, PowerPC, ...) on different 
build architectures (gcc-2.95.3, gcc-3.2, ...). And this is not joke 
anymore and this should be ready for CVS, too, which was not the case 
with the KDevelop-2.1.x since the .kdevses contained also the last 
IDE/GUI state. Serious consideration should be made about what is the 
project data and what is the session data.

So, my opinion is that the builds should go into the .kdevelop.

And besides (which has little to do with the .kdevelop/.kdevses 
dilemma)- I am not assuming using the KDevelop always to build the 
projects - why then have I the configure ? But the problem is, if the 
build configurations are important for me as they are defined and the 
Makefile.am/configure do not contain the build configuration 
information, I should do the master Makefile over the Makefile.cvs's in 
various (sub)projects which has no interaction with the .kdevses-es - I 
thus get the duplicate of the build configurations and thus easily 
incorporate inconsistencies and incompatibilities to my builds when done 
automagically.

Since the .kdevelop and .kdevses are XML, the solution to my problems 
could be some kind of the Makefile (generated at the autotools phase, 
right after the configure script generation or on request in the Build 
menu) which would contain the build configurations specifics and cover 
the build process from the configure phase on - could be invoked as make 
default, make debug, make ARM etc. etc.

Iztok

>The feature of the project file to not to be user-specific (and therefore
>ready for cvs-management) got lost from KDevelop-2 to KDevelop-3. So at present
>this is some kind of a regression. And I think the user acceptance depends
>on such simple questions.
>If you mean .kdevelop format changes during the past alpha versions of
>KDevelop-3, in my opinion, back-compatibility to old alpha versions doesn't make
>sense, as it just blows up the source code, unnecessarily.
>
>CU
>F at lk
>
>  
>
>>So here is a general question about making changes regarding project
>>files:
>>How important is backward compatibility with existing project files? Say 
>>some settings are moved from .kdevelop to .kdevses; is it acceptable 
>>that users existing settings in their .kdevelop files get lost/ ignored 
>>in the process and they have to redo their settings? Or should there be 
>>code that migrates settings if an old style .kdevelop file is encountered?
>>
>>Hendrik
>>
>>PS: I posted a patch a couple of days ago hoping that somebody would 
>>review and submit it to CVS, but did not get any feedback on the list or 
>>per email. I assume nobody read my posting to the part where I asked for 
>>this. So, could somebody please submit it. Alternatively: what is the 
>>procedure for getting access to the CVS?
>>
>>
>>F at lk Brettschneider wrote:
>>    
>>
>>>Hi!
>>>Seems someone has removed the .kdevelop project file for KDevelop3 from 
>>>CVS.
>>>I think it should be in CVS again since it's a proof of concept if that 
>>>file is able to be shared in a team development environment.
>>>
>>>Any user-specific stuff should be moved to the common session file 
>>>(~/.kde/share/config/kdeveloprc) or to the project-specific session file
>>>      
>>>
>>>(.kdevses). Further details on this are at the bottom of white paper 
>>>
>>>      
>>>
>http://developer.kde.org/documentation/library/cvs-api/kdevelop/html/howToAddPlugins.html 
>  
>
>>>..
>>>
>>>Any objections for a reanimation?
>>>
>>>CU
>>>F at lk
>>>      
>>>
>
>  
>