[cmake-developers] [PATCH] fix #4186 kdevelop bug

Bill Hoffman bill.hoffman at kitware.com
Tue Jan 23 19:54:34 EST 2007


Alexander Neundorf wrote:
> On Tuesday 23 January 2007 21:01, Bill Hoffman wrote:
>   
>> Alexander Neundorf wrote:
>>     
>>> Hi,
>>>
>>> the attached patch fixes bug #4186, which caused that some files could be
>>> listed multiple times in the kdevelop filelist file.
>>> Additionally it gets rid of the tiny files
>>> cmLocalKdevelopGenerator.h/cxx, by putting this tiny class inside
>>> cmGlobalKdevelopGenerator.cxx.
>>>       
>> I would rather keep the tiny files.  As a matter of style I do not like
>> "public" classes that are not in a separate
>> file.  Think Java, you can not have class in a file that is not the same
>> name...
>>     
>
> The only thing this class does is to set the member ForceVerboseOutput to true 
> in its ctor. 
>
> Just today I had the effect that we can now build our project under Windows 
> both with Cygwin UNIX makefiles as well as with MS nmake makefiles.
> Now there is the KDevelop project generator, which is a subclass from 
> UnixMakefileGenerator3. 
> Once we have KDE4, KDevelop will also run under Windows. Then people might 
> want to use it with mingw makefiles, or nmake makefiles or cygwin makefiles. 
> These projects will always consist of makefiles and some additional project 
> files.
> The same could be done for other programming editors which I just played 
> around with today, like Programmers Notepad. Having a multitude of generators 
> because there are maybe 5 different makefile types and each accompanied by 2 
> or 3 or 4 IDEs/programming editors would easily make like 20 generators and 
> more. Maybe something can be done so that it is possible to select a makefile 
> generator and chose an "IDE generator" to them via cmake (i.e. not fixed in 
> the code).
> So I think it should be made easy to write generators which just create some 
> files additionally to any of the makefile generators. Not having to subclass 
> the local generators and having to deal with more files can help in this 
> regard.
>
> So in the attached patch I added a setter to cmLocalUnixMakefileGenerator3.
> Better this way ?
>   
This patch is better and consistent with the way nmake is done.  I have 
been thinking that the makefile variants
might be specified in some sort on config file. So, you might be able to 
add a new make generator completely from
the platform directory.  Currently, there is really only one makefile 
generator, and class ivars are used to control
behavior and those values are set by the various global generators. 

-Bill





More information about the cmake-developers mailing list