[patch] Link Okteta for Windows (kdeutils/okteta/)

[Friedrich W. H. Kossebau]

Hi all,

Am Mittwoch, 14. Mai 2008, um 13:56 Uhr, schrieb Jaroslaw Staniek:
> Friedrich W. H. Kossebau said the following, On 2008-05-14 13:15:
> > Hi Jarosław,
> >
> > Am Dienstag, 13. Mai 2008, um 15:43 Uhr, schrieben Sie:
> >> Friedrich,
> >> Attached patch which helps to link Okteta without any problems on
> >> Windows (msvc).
> >
> > Thanks. Applied the changes for
> > 	core/ksectionlist.*
> > 	program/libkakao/core/tests/testdocumentfilesynchronizerfactory.cpp
> > 	core/kabstractbytearraymodel.h
> > but for the rest, well, the main part, I need some more discussion, see
> > below:
>
> then let's go to kde-windows at kde.org; CC'd now and reattaching the patch
> for reference...

Am subscribed now for the discussion.

> >> The main change was to add a few exports and link the main library
> >> directly instead via the static libs.
> >
> > I do not like that too much, honestly.
> > The added exports are just needed for the tests, not for the runtime
> > code. And the static libs you removed are making it easy for me to keep
> > an overview locally, to control include dirs/dependencies and to move
> > stuff around.
>
> I guess cmake tracks the deps reasonable well. At least projects bigger
> than Okteta have no problems. Optionally static libs could nbe replaced
> with dynamic libs (exactly the same complexity) if you have problems with
> link times on a non-msvc compiler.

No, sorry, there meant dependencies in terms of other libs used by including 
headers. E.g. okteta/program/libkakao/core/CMakeLists.txt contains
--- 8< ---
project( kakaocore )

include_directories(
  document
  io
  system
)
--- 8< ---
which prevents me (and others) from adding dirty hacks using headers from libs 
which might be part of the program (e.g. liboktetacore) but are not intended 
to be used here. So libkakaocore stays independent from liboktetacore and 
could be easily turned into a shared lib later on. A better term might 
be "visibility at compile time" or "Encapsulation". See now what I mean? I 
could take the whole subdirectory and move it somewhere else, without needing 
to change any build instructions other than add_subdirectory() (I think).

> > Could we instead please try to make static libs work also with msvc? I
> > will be glad to cooperate. But your proposed changes just go too much
> > against my development style, sorry.
>
> This style is pretty new to me these days (I remember it when autotools
> were in use though) :)
>
> > What are the problems msvc has with the current build instructions?
>
> [  6%] Building CXX object
> okteta/core/CMakeFiles/oktetacore.dir/kpiecetablebytearraymodel.obj
> kpiecetablebytearraymodel.cpp
> [  6%] Building CXX object
> okteta/core/CMakeFiles/oktetacore.dir/kwordbufferservice.obj
> kwordbufferservice.cpp
> [  6%] Building CXX object
> okteta/core/CMakeFiles/oktetacore.dir/kbookmarklist.obj kbookmarklist.cpp
> [  6%] Building CXX object
> okteta/core/CMakeFiles/oktetacore.dir/ksection.obj ksection.cpp
> [  7%] Building CXX object
> okteta/core/CMakeFiles/oktetacore.dir/ksectionlist.obj ksectionlist.cpp
> Linking CXX shared library ..\..\bin\oktetacore.dll
>     Creating library ..\..\bin\oktetacore.lib and object
> ..\..\bin\oktetacore.exp [  7%] Built target oktetacore
> [  7%] Generating testoktetacore_automoc.cpp
> [  7%] Building CXX object
> okteta/core/CMakeFiles/testoktetacore.dir/testoktetacore_automoc.obj
> testoktetacore_automoc.cpp
> c:\kde4\tmp\kdeutils-20080202\work\msvc2005-debug\okteta\core\moc_kbytearra
>ymodel.cpp(45)
>
> : warning C4273: 'staticMetaObject' : inconsistent dll linkage
>
> c:\kde4\tmp\kdeutils-20080202\work\msvc2005-debug\okteta\core\../../../../.
>./../svn/trunk/KDE/kdeutils/okteta/core/kbytearraymodel.h(43)
>
> : see previous definition of 'public: static QMetaObject const
>
> KHECore::KByteArrayModel::staticMetaObject'
> c:\kde4\tmp\kdeutils-20080202\work\msvc2005-debug\okteta\core\moc_kbytearra
>ymodel.cpp(45)
>
> : error C2491: 'KHECore::KByteArrayModel::staticMetaObject' : definition of
>
> dllimport static data member not allowed
> c:\kde4\tmp\kdeutils-20080202\work\msvc2005-debug\okteta\core\moc_kbytearra
>ymodel.cpp(51)
[...]

I guess the problem could be somewhere there: For convenient testing purposes 
there is another lib built from the same sources (testoktetacore next to 
oktetacore), just static, so without visibility flags, that way the unit 
tests do not need to explicitely include all needed source files, but can 
just link against the static version of the lib.
"Built target oktetacore", at least.

Or were the errors the same for all the static libs below the directory 
okteta/program?

Friedrich