KDE/kdelibs/cmake/modules

[Sebastian Sauer]

On Saturday 21 October 2006 23:41, you wrote:
> > 1. r597592
> >
> > -if (NOT QT_DBUSXML2CPP_EXECUTABLE)
> > -   message(FATAL_ERROR "Qt4 qdbusxml2cpp was not found. Make sure it has
> > been built and installed by Qt")
> > -endif (NOT QT_DBUSXML2CPP_EXECUTABLE)
> > +if (NOT WIN32)
> > +   if (NOT QT_DBUSXML2CPP_EXECUTABLE)
> > +      message(FATAL_ERROR "Qt4 qdbusxml2cpp was not found. Make sure it
> > has been built and installed by Qt")
> > +   endif (NOT QT_DBUSXML2CPP_EXECUTABLE)
> > +endif (NOT WIN32)
> >
> > This part is needed since the Qt 4.2.1 qmake does compile qdbusxml2cpp
> > only for unix-systems
>
> When you would have asked at kde-windows, we would have told you that
> you need windbus and that we're currently working on this topic.

Great to hear that there is progress. In fact I walked through the ml-archives 
and failed to find infos about it. Also I don't found any at kdelibs.com. 
Also it seems I am not the only one who failed to find informations about 
this since I got mail from another devel who asked about details + pointed my 
finally to the solution (according to his mail he found it by seeking through 
the web rather then beeing pointed to that by e.g. a quick link at 
kdelibs.com or a doxygen-comment or something like this). For sure it is nice 
to hear that there is work done on it, but let me provide here the same 
critic I already offered to other projects within KDE: if there is no single 
word, link or other kind of informations about a topic written down, then the 
topic just does not exist and even worse some others may like to start to 
have there own solutions for a problem that is already worked on.
It is just plain difficult for someone like me who like to get into the topic 
to get an overview. Also things like "if you have asked me" don't help here. 
Well, in fact I talked with Jaroslaw about what I am doing the time I did it 
since in my eyes he's still the "knowledge-base" if it comes to kde on 
windows. But seems that wasn't enough in that case. Well, now I know, but how 
should I know before? Ask at n mailinglist, forums and irc-rooms?
Anyway, those part got reverted in svn.

> > 2. r597606
> >
> > -   # add the winsock2 library, using find_library or something like this
> > would probably be better
> > -   set(KDEWIN32_LIBRARIES ${KDEWIN32_LIBRARY} user32 shell32 ws2_32)
> > +   # add the winsock2 library
> > +   find_library(WIN32_USER32_LIBRARY NAMES user32 PATHS
> > $ENV{WINDIR}/system32)
> > +   find_library(WIN32_SHELL32_LIBRARY NAMES shell32 PATHS
> > $ENV{WINDIR}/system32)
> > +   find_library(WIN32_WS2_LIBRARY NAMES ws2_32 PATHS
> > $ENV{WINDIR}/system32) +   set(KDEWIN32_LIBRARIES "${KDEWIN32_LIBRARY}
> > ${WIN32_USER32_LIBRARY} ${WIN32_SHELL32_LIBRARY} ${WIN32_WS2_LIBRARY}")
> >
> > You may note the "set(KDEWIN32_LIBRARIES ${KDEWIN32_LIBRARY} user32
> > shell32 ws2_32)" which was there before I touched the code and just got
> > replaced. The set() was totaly wrong anyway and I wonder it compiled at
> > all since at least it was missing additional "-chars ( so,
> > set(KDEWIN32_LIBRARIES "${KDEWIN32_LIBRARY} user32 shell32 ws2_32") ) but
> > maybe <cmake 2.4.3 did not throw an error before while 2.4.3 does cause
> > user32 is not an known keyword not was it a variable.
>
> 1.) you can't link agains shared libs on win32 (mingw can, but it's a
> feature added by Ralf Habacker)
> 2.) user32, shell32 and ws2_32 is enough since cmake expands them to the
> correct static import libs (libfoo.a/ foo.a for mingw amd foo.lib for
> msvc) - they're  also available on your system 8see MinGW\lib)

Please note, that this is not about plattform, compilers or whatever. It is 
just plain _wrong_ cmake-syntax and therefore I really doubt that the old rev 
would compile on newer cmake's (even on older cmake's it should not do what 
is expected, but propably it doesn't throw an error there). Also please note 
that someone wrote before the note "use find_library" above the wrong line. 
So, what I did was 1) fix the cmake-error and 2) solve the todo. I really 
fail to see why this should be more wrong then the code that was there 
before?
Anyway, since your last commit commented it already out cause it's not needed 
at all, I would see this thing as solved, or?

> > 3. r597618
> >
> > # FindZLIB.cmake
> > set(ZLIB_INCLUDE_DIR ${KDEWIN32_INCLUDES})
> > find_library(ZLIB_LIBRARY NAMES zlib PATHS ${KDEWIN32_LIBRARY_PATH})
> > ...
> >
> > if you look again at it, you may note that the relevant added code is in
> > a "if(MINGW)" block, so it should be independend of compiling on MS
> > Visual Studio except you use MINGW on MSVS? Then it should be propably
> > checked for that condition imho.
>
> But it's superflous - why would you check for this twice? I don't think
> this is needed for mingw only and it's checked for on other places (main
> CMakeLists.txt)

hmmm... I fail to see any code that is relevant in 
kdelibs/cmake/modules/CMakeLists.txt ?! The problem here is, that the within 
kdelibs and cmake.org distributed Find*.cmake files don't handle any non unix 
paths at all and even after seeking again and again through the existing 
code, I don't see any area where it's handled...
But for sure it would be nice to get a hint (and write it down on kdelibs.com) 
on this issue since in my eyes (and others seem to have the same intention 
here), such solutions/workarounds should go to the Find*.cmake files rather 
then be located in a (at least for me still hard to find) main 
CMakeLists.txt. That makes understanding and maintaing the things much easier 
imho.

Re mingw only; I don't have a MSVC around nor do I know anything about the 
internals of MSVC. So, I absolutly don't know if MSVC would need the "dirty 
workaround that just works for me with Qt 4.2.1+cmake 2.4.3" or if it would 
break things on MSVC. That's why the "workaround" got move in a "if(MINGW)" 
block + a comment to propably move such code once others did look over it to 
either the matching Find*.cmake or at least to e.g. FindKDEWIN32.cmake to 
have it outside of the growing FindKDEInternal.cmake.

So, all I am able to say is that it fixes compiling for me on my setup's. If 
it breaks compiling on other setup's then we should propably try to get both 
setup's working rather then just to revert things what in turn means again 
that my setup won't work what can't be a good (or the best) solution. I for 
sure understand that having it working on the "standard-setup" that is 
described at the kdelibs.com tutorial has propably the highest priority, but 
from my point of view that does not should limit us to get it working even on 
other setup's with other/newer Qt+cmake -releases.

I apologise if it looks as I try/tried to break things here for long-time 
devels who are familar with the matter. My only intention is/was to have it 
actualy just working on my setup. The reason why I don't just followed the Qt 
4.1.x tutorial on kdelibs.com but tried to get it working with other/newer 
releases seems to be - in my eyes - also very clear; >=Qt 4.2 is the 
standard, minimum and stable release. So, I try to get it working exactly 
with that one (and once 4.3 is released also with that release).

> > 4. r597624
> >
> > - find_file(GNUWIN32_DIR_tmp gnuwin32 win32libs
> > + find_file(GNUWIN32_DIR_tmp gnuwin32 kdewin32 win32libs
> >
> > This one was needed cause the kdewin32-package (where the relevant
> > GnuWin32 files are located) is not named win32libs any longer (what was
> > iirc the case for Qt3, or?)
>
> You should not mix gnuwin32 and kdewin32 ...
> gnuwin32: a summary of all relavant external libs needed for kdelibs,
> downloadable somewhere on Ralf Habackers sites, I also have an updated
> version of this under the name 'win32libs' - both names are not that
> optimal.
> kdewin32: a small layer needed to emulate some posix function not
> available on win32

yeah. Guess I got confused here by the name win32libs. Anyway, the matching 
commit got also reverted :) For sure long time solution would be to don't 
have the paths+names hardcoded.

> > Anyway... where exactly does it break? The only thing that really changed
> > for all compilers was the 4. mention above. So, does revert it fix the
> > break? btw, without 1. and 2. it does _not_ compile on win32/mingw for me
> > :-(
> >
> > btw, Laurent pointed me
> > to "http://sourceforge.net/project/showfiles.php?group_id=171968" which
> > should help to get it finally compiled (biggest prob I saw so far was the
> > missing dbus-lib).
>
> Imho it would be the best to revert all your changes and try again. If
> you have problems, you should ask at kde-buildsystem or kde-windows for
> help and then you maybe can check in the changes, if needed!

hmmm... now it's difficult to reply to that without sounding like someone 
who's a bit frustrated about the "revert everything, even the parts that are 
fixing bugs" part.

So,
1. At least parts of it _are_ needed cause before it does not compile and now 
it does (on my setup, if it breaks yours please provide details where it 
breaks and I'll provide n hours/days to solve it and get it working for both 
of us).
2. While I like to have reviews and constructive feedback cause that's the 
best way to learn and while I'll try to do so next time(s), I really don't 
understand the "revert anything" part. As you may note above 2 cases where 
reverted while I absolutly don't see any reason to revert e.g. the fixed (and 
juding from your last commit unneeded) cmake-line or the wrong handling of 
REQUIRED at FindGNUWIN32.cmake. Are we at a stage where we try to keep 
status-quo (what means does not work for my setup) or do we try to fix 
things?
3. So, to ask again and to be able to fix things; where does it break now on 
your setup?

-- 
Sebastian Sauer aka dipesh[sebsauer]
http://www.dipe.org/public_key.asc
Fingerprint: 8F1E 219B 16E6 4EC7 29CC F408 E193 65E2 9134 2221
Coder in http://www.koffice.org && http://www.kmldonkey.org