[bt-devel] Some more patches

[Jaak Ristioja]

Eeli Kaikkonen wrote:
> Jaak Ristioja wrote:
> 
>> The second patch, 0011-Remove-generated-config.h-file.patch makes CMake
>> not generate config.h but instead pass on the BibleTime version via the
>> command line.
>>
>> The third patch, Remove-QT4_AUTOMOC-in-favor-of-QT4_WRAP_CPP.patch makes
>> CMake use QT4_WRAP_CPP instead of QT4_AUTOMOC. This eliminates the need
>> to include the *.moc files in the *.cpp files.
>>
>> !!! CMake should still continue to work after applying these patches !!!
>>
>> Now, having eliminated all major obstacles for this, the fourth patch
>> 0013-Added-preliminary-Qt4-project-files.patch adds some basic Qt
>> project files for BibleTime, which allow one to build BibleTime using
>> qmake instead of CMake. Nevertheless, CMake will still keep on
>> functioning via the build scripts.
>>
>> So you might probably wonder whats the point of making qmake work. Well,
>> using qmake means one can use Qt Creator properly. Yay! =]
> 
> This is quite interesting. However, I won't apply these at least yet.
> These have to be decided together with other developers.
> 
> Getting Creator support is surely a positive thing. But Creator is
> continually "under work" and they are working on better cmake support.
> If cmake is supported directly there's no need for qmake. Cmake has been
> originally selected for us because qmake may be too simple and
> restricitive. It may work now but not necessarily in the future.
> 
> Personally I have used KDevelop even though it doesn't have direct cmake
> support. After running cmake once the project is a normal make file
> based project. Therefore the IDE has only to be able to use old style
> make files. When the build system is changed cmake has to be run
> manually once, but then it's easy to use e.g. KDevelop's Build functions.
> 
> Creator seems not to support other than qmake yet. It would be great to
> have a Qt-based toolchain but I don't see it important enough to change
> our code right now. Things may be different after some months when
> Creator has been developed further and hopefully we have the Windows
> build working. I think Creator is not very useful under Windows without
> working MinGW build - if Visual Studio must be installed, people
> probably rather use VS instead of Creator.
> 
> Now we eagerly wait Martin Gruner to come back from his vacation so that
> he can say something about this. Other's opinions are of course also
> welcome.

Knowing that completely changing the build system wouldn't likely be a
good option at the moment, the patches I provided were designed only to
make qmake support supplementary. That's why I had to patch CMake
support a little to have qmake working.

After applying those patches CMake should continue to work just the way
it did before, and as far as I can tell, it does. So one can just keep
on developing without even noticing the project files as CMake would be
the default and preferred build system. However if one wishes to use
qmake, one would have the option do so (two build systems at the same time).

The project files I provided in the last patch were actually just a demo
(they currently only generate the binary), but I'm quite sure that they
can be tweaked in a way that they generate output just as CMake (same
locations for moc and object files, install target, etc).

To sum up, I consider it safe to apply all of those patches, but in case
you don't want any additional project files in the tree, I suggest
applying only 0011 and 0012 just to get a rid of config.h and #including
*.moc files in *.cpp files. And as I said, my patches won't break CMake
(with the trivial exception of running qmake the first time, which will
currently overwrite the makefile in the root).

Jaak Ristioja