[Kde-bindings] Port of qtguess.pl to CMake

[David Palacio]

On Thu, Mar 26, 2009 at 23:44, David Palacio <> wrote:
> On Jueves 26 Marzo 2009 05:31:13 Richard Dale wrote:
>> On Wednesday 25 March 2009 23:51:33 Pau Garcia i Quiles wrote:
>> > 2009/3/25 David Palacio <>:
>> > > On Miércoles 25 Marzo 2009 11:14:13 David Palacio wrote:
>> > >> Some Smoke generation scripts are incompatible with Windows and MSVC,
>> > >> especially qtguess.pl. I attached what could be a CMake cross-platform
>> > >> replacement for it.
>> > >>
>> > >> Untar on smoke/qt.
>> > >
>> > > Oops, messed up at the last moment.
>> >
>> > There are a few more issues. This is what I ran into when I tried to
>> > build SMOKE and QtRuby with VC++2008 a couple of months ago (I'm
>> > cutting and pasting from an e-mail I sent to Richard and to the guy
>> > who "ported" an old version of QtRuby to Windows) :
>> >
>> > ==========
>> >
>> > - The Perl scripts don't work with ActivePerl (I've so far fixed this)
>> > [ I fixed this by replacing GNU coreutils with Perl code; I guess you
>> > have replaced Perl with CMake scripting, which is much better ]
>> >
>> > - GNU coreutils is expected to be available, which is not the case on
>> > a pure-Win32 environment (I've also fixed this)
>> >
>> > - Smoke: pid's are not using the PROCESS_INFORMATION structure (I have
>> > discussed with Richard a fix for this but I have not tested it yet),
>> > one __declexport/__declimport failure (fixed).
>> >
>> > - QtDBUS is always processed by Kalyptus, even when it does not exist,
>> > which is the case when using the official MSVC Qt on Windows
>> >
>> > - Some issues with the DOM header files, which I have not fixed yet
>> > but are the least of my worries now
>> >
>> > ==========
>> >
>> > The Q_PID being a pointer PROCESS_INFORMATION on Win32 (instead of a
>> > 'long') was the only important one. It should be possible to fix the
>> > issue by special-casing Q_PID: instead of using the 'long' in the
>> > Smoke structure, on Win32 we'd use the void* an cast to
>> > PROCESS_INFORMATION.
>> >
>> > Unfortunately I was very busy when I hit the Q_PID problem (I was only
>> > able to work on the port for a couple of hours) and did not finish it.
>> > I expected to devote some time to the VC++ port in May, but maybe
>> > you'll have completed it by then :-?
>>
>> OK, I can special case Q_PID in the qtruby marshaller with #ifdefs so it
>> does the right thing on Windows, and also WId needs special casing too.
>>
>> I looked at David's cmake qtguess replacement and we can commit that if it
>> works on both Windows and Linux - I'm not enough of a cmake expert to tell
>> if it is good cmake stuff of not - it certainly looks fine to me. Also it
>> would be nice to get the Qyoto C# bindings building on Windows 'out of the
>> box'.
>>
>> -- Richard
> Smoke-Qt compiled fine with MinGW. But I am having issues with VC
> (SMOKE_EXPORT, a missing QT_NO definition. So it will need more testing.
>
> SMOKE_EXPORT. The VC compiler complains at line 66 in smoke.h:
> kdebindings/smoke/smoke.h:66 error C2487: 'classMap' : member of dll interface
> class may not be declared with dll interface
>
> SaroEngels told me to remove that export.
>
> There is still the issue of kalyptus not generating code for other smoke
> modules.
>
> * generate.pl.cmake
> According to the CMake manual, @CMAKE_CURRENT_SOURCE_DIR@ contains the full
> path, so lines as:
> $headerlistpath = $headerlist if ($headerlist =~ /^\//);
> are not needed (and do not make sense in Windows).
>
An update. Step by step description of what I did.

System:
* KDE 4.2.1 MinGW installation
(at C:\KDE)

* Ruby MinGW
(http://www.akitaonrails.com/2008/7/26/still-playing-with-ruby-on-windows)
Add to PATH: C:\ruby18\bin;c:\ruby18\lib

* Perl (the one that comes with the KDE installer works)

* CMake 2.6.3 (downloaded zip from website and put it in c:\kde
Why? I got this error with both kdebindings and konversation:
-- Phonon Version: 4.3.0
-- Found Phonon: C:/KDE/lib/libphonon.dll.a
-- Found Phonon Includes: C:/KDE/include/KDE;C:/KDE/include
-- Found KDE 4.2 include dir: C:/KDE/include
-- Found KDE 4.2 library dir: C:/KDE/lib
-- Found the KDE4 kconfig_compiler preprocessor: C:/KDE/bin/kconfig_compiler.exe

-- Found automoc4: C:/KDE/bin/automoc4.exe
CMake Error at C:/KDE/share/cmake-2.6/Modules/FindPackageHandleStandardArgs.cmak
e:57 (MESSAGE):
  Could NOT find KdepimLibs (missing: KdepimLibs_CONFIG)
Call Stack (most recent call first):
  C:/KDE/share/apps/cmake/modules/FindKdepimLibs.cmake:73 (find_package_handle_s
tandard_args)
  CMakeLists.txt:10 (find_package)

* kdebindings(trunk) source
Put:
http://lists.kde.org/?l=kde-bindings&m=123799737004726&w=2
and
http://lists.kde.org/?l=kde-bindings&m=123800276313726&w=2
in kdebindings/smoke/qt


**BUILD**
Well, it should be a normal MinGW build now:
mkdir build
cd build
cmake .. -DCMAKE_INSTALL_PREFIX=C:\KDE -G "MinGW Makefiles"
mingw32-make smokeqt                 (1)
[[when it is compiling x_*.cpp files, pause (press pause key)
edit smoke/qt/x_13.cpp and search for "pid"
comment the content of that function
press any key]]
[[smokeqt should be built now]]
[[ruby may break Qt at compile time, so it may be needed to patch
qtruby ( http://pastebin.com/m2ed5d487 )]]
mingw32-make qtruby4

It fails at link time with ( http://pastebin.com/m53685c4d )

I am stuck there. There are also other issues when building with
VS2005, as well needing to compile  ruby with the same compiler as
KDE.


(1) It may fail to compile. Which is very strange as the environment
setup works in another pc. I realized that the compiler is not
actually the same:
Works:
gcc -v
gcc version 3.4.5 (mingw special)

Fails
gcc -v
gcc version 3.4.5 (mingw-vista special r3)

So I copied the c:\mingw directory from the other computer.