Windows patches

[Patrick Spendrin]

Am 04.07.2012 16:20, schrieb Stephen Kelly:
> Patrick Spendrin wrote:
> 
>> Hi everybody,
>>
>> I am now half way through building kdelibs frameworks branch on windows.
>>
>> Some things I want to mention:
>> - most unittests are console applications on Windows and so they need to
>> be linked against the stub library qtmain.lib. I committed a patch which
>> does this already for quite a lot of the tests etc. but since this ugly
>> and easy to forget it would be really cool if we could get this in cmake
>> itself and have a way to link against a stub library if a non-GUI
>> application is built (like a LINK_INTERFACE).
> 
> This surprises me. I always thought it was gui applications that need to 
> link to qtmain.lib. Funny how easy it is to get the wrong idea... :)
> 
> I'm also surprised because we use set(CMAKE_WIN32_EXECUTABLE ON) in ecm to 
> create WIN32_EXECUTABLEs by default. This might mean that the feature is 
> broken in cmake (I added it in CMake 2.8.8), so please provide more 
> information.

Ok, I checked again and the executables that do get build are actually
non-gui apps, so likely it really doesn't work. If you can point me to
the patch I can actually take a closer look. One more thing to mention
is though that for non-gui apps the streams for stdout, stderr and stdin
do not exist, so some apps need to be build without it then.

> 
>> Since this will not happen before at least 2.8.10, I will fix this in
>> the ugly way for now.
>>
>> - A lot of KDE libraries can be build without using kdewin (which is
>> kind of a posix compat layer), so I try to get libraries working without
>> it first. I won't succeed on all libraries though.
> 
> It might make sense to get as much as possible into Qt. For example, create 
> a qSetEnv which calls ::setenv or SetEnvironmentVariable.

I had some problems with stuff like mode_t, chmod etc.
It won't be easy to get this into Qt.

> 
> Additionally, instead of changes like 
> 
> +#if defined(Q_CC_MSVC)
> +#undef interface
> +#endif
> 
> we should prefer to rename the 'interface' variable to something else. 
> Especially as it is in a private file in this case, but also for public API 
> which conflicts, we should consider changing the API.

Yes, I would actually prefer that. Especially interface brings common
errors.

> 
> 
>> - due to the way our generate export header script works, some adaptions
>> are needed for building & linking static libraries (you need to set a
>> -D${TARGET}_STATIC_DEFINE=1). If possible this should be moved to a
>> property in cmake as well.
> 
> Yes, hopefully easy with CMake 2.8.10.

Ok, if there is something to test or improve, please just send me more
information.

> 
>> Please comment on these issues! ;-)
> 
> Thanks for your efforts on this,
> 
> Steve.

regards,
Patrick