[CMake] cmake-gui on windows and qt5 dlls

[Christian Ehrlicher]

Hi,

 

I recently upgraded from cmake 3.3 to 3.9 on windows and got some problems during my build because it looks like the pre-compile binaries for windows are now shipping Qt5 - dlls instead static compile libs (since 3.5 afaics).

The problem is, that I had the path to cmake *before* the path to my own Qt5 libaries. So during the build / run of my application, the wrong libraries were loaded and I got a symbol lookup error.

Would it be possible to use the static Qt5 libs instead or maybe prefix the Qt5 libs shipped with cmake-gui somehow?

 

Thx,

Christian
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] State of CMAKE_MSVCIDE_RUN_PATH

[Christian Ehrlicher]

Hi,

 

It looks like there's a variable CMAKE_MSVCIDE_RUN_PATH to add additional paths which ar eused during add_custom_command/add_custom_target runs. But this variable is not documented anywhere ... is it safe to use this variable in CMake scripts?

 

Thx,

Christian
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] QT4/5_WRAP_CPP / INTERFACE_INCLUDE_DIRECTORIES

[Christian Ehrlicher]

Hi,

 

I wonder if it is a documentation error or an error in QT4/5_CREATE_MOC_COMMAND. The documentation states, that INTERFACE_INCLUDE_DIRECTORIES is taken from the given target but the code says, that INCLUDE_DIRECTORIES is used:


If the  is specified, the
  INTERFACE_INCLUDE_DIRECTORIES and INTERFACE_COMPILE_DEFINITIONS from
  the  are passed to moc.

Code:

set(targetincludes "$")

 

 

The two properties have different content and when I use an INTERFACE library as target, it does not work (forbidden property):


TARGET_INCLUDE_DIRECTORIES(foo
  PUBLIC
    /home/public
  INTERFACE
    /home/interface
  PRIVATE
    /home/private
)
get_target_property(targetincludes foo INTERFACE_INCLUDE_DIRECTORIES)
message(STATUS "ifc incl: ${targetincludes}")
get_target_property(targetincludes foo INCLUDE_DIRECTORIES)
message(STATUS "incl: ${targetincludes}")

-->
-- ifc incl: /home/public;/home/interface
-- incl: /home/public;/home/private

 

Thx,

Christian


-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Creating dependencies between static imported targets.

[Christian Ehrlicher]

Am 21.08.2016 um 09:24 schrieb Yaron Cohen-Tal:

Hi,

Using ""target_link_libraries" between static libraries is allowed, 
however doing it with static imported targets fails with:


"Cannot specify link libraries for target "" which is not 
built by this project.


However, this is necessary in order to define dependencies between the 
targets, which is necessary when solving dependencies (when those 
targets are eventually linked into e.g. an executable built by the 
project). How, then, can I create dependencies between imported targets?
INTERFACE_LINK_LIBRARIES is what you're looking for. See also 
https://cmake.org/cmake/help/v3.5/manual/cmake-buildsystem.7.html#imported-targets 
for more information.


HTH,
Christian

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] CMake keeps on referencing an uninstalled Qt

[Christian Ehrlicher]

Hi,

 

Did you really recreated (deleted) your CMakeCache.txt after changing your Qt installation? Or at least removed all references to Qt5 in the CMakeCache.txt (e.g. with cmake-gui)?

 

Christian

 

Von: "Laura Médioni" 
Betreff: Re: [CMake] CMake keeps on referencing an uninstalled Qt

On 10/09/2015 06:48 PM, John Drescher wrote:
> On Fri, Oct 9, 2015 at 9:53 AM, Laura Médioni  wrote:
>> Hi,
>>
>> I am facing a problem with CMake 3.4 under Windows.
>> My CMake project is using Qt. Recently I uninstalled Qt and reinstalled it.
>> Since then, the previous Qt install keeps on appearing in the
>> CMakeCache.txt, leading to link edition errors.
>>
>>
> You may want to look at the CMake Package Registry
>
> https://cmake.org/Wiki/CMake/Tutorials/Package_Registry
>
> John
Thank you very much for your answer. But as I said, there is no track of
"QtSDK" in the Windows registry.

 

 



-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] cmake uses -I instead -isystem when linking private against a library

[Christian Ehrlicher]

Hi,

It looks like '-isystem' is replaced by '-i' from the compile line as 
soon as the library which defined the path as system include path is 
linked as 'PRIVATE'.

See this testcase:

project(isystem)
cmake_minimum_required(VERSION 3.0)

add_library(lib1 SHARED foo.cpp)
set_property(TARGET lib1 PROPERTY INTERFACE_INCLUDE_DIRECTORIES
${CMAKE_SOURCE_DIR}/include)
set_property(TARGET lib1 PROPERTY INTERFACE_SYSTEM_INCLUDE_DIRECTORIES 
${CMAKE_SOURCE_DIR}/include)


add_library(lib2 SHARED foo.cpp)
target_link_libraries(lib2
  PUBLIC
lib1
)
add_library(lib3 SHARED foo.cpp)
target_link_libraries(lib3
  PRIVATE
lib1
  PUBLIC
lib2
)
add_library(lib4 SHARED foo.cpp)
target_link_libraries(lib4
  PUBLIC
lib3
)

now lib4.cpp is compiled with -I ${CMAKE_SOURCE_DIR}/include ...

I'm not quite sure if the dependency chain is valid here and it can be 
easily fixed by moving lib1 from PRIVATE to PUBLIC in 
target_link_libraries(lib3) but since lib3 links public to lib2 and lib2 
public to lib1 I expected that lib4 should also use '-isystem'


Should I file a bug report on this?
Christian



--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Automoc for ui files?

[Christian Ehrlicher]

Am 31.10.2012 10:37, schrieb Rolf Eike Beer:

Am , schrieb Andreas Pakulat:

Hi,

On Wed, Oct 31, 2012 at 12:02 AM, David Doria daviddo...@gmail.com 
wrote:

I just learned about automoc, and it is fantastic! I have been able to
get rid of all of my manual QT4_WRAP_CPP calls. Is there a similar way
to get rid of my QT4_WRAP_UI calls? They are equally as bulky to write
out manually :)


No. In theory it could be doable though by checking for ui_* includes,
but unlike with moc's there's usually a lot less files and there's not
so much to configure for them either (think about QObject's in cpp
files requiring mocc'ing the cpp). Also many people don't keep their
.ui files alongside the code but in a separate directory which would
be a problem for an auto-ui function.


I wonder if we could just do the right thing if one adds the ui 
files to the list of source.



Whats wrong with QT4_WRAP_UI()?


Christian
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] QtCreator generator?

[Christian Ehrlicher]

Am Samstag, 12. November 2011, 00:05:20 schrieb David Doria:
 On Fri, Nov 11, 2011 at 5:56 PM, John Drescher dresche...@gmail.com wrote:
  There should have been a *.sln file that you open.?
  
  Not for a Code Blocks -NMake Makefile project.
  
  John
 
 Ok, I guess I am getting my two threads confused.
 
 *To use QtCreator*
 The consensus is to use the Code Blocks - NMake Generator. This has
 generated successfully a .cbp file (Code Block Project, I'm assuming).
 However, QtCreator seems unaware that this is a project and just opens it
 as plain text? How do I now open this project in QtCreator?
 
Open the CMakeLists.txt and adjust the build dir to the one you created.


Christian
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Getting closer building cmake-gui...

[Christian Ehrlicher]

Am Freitag, 13. Mai 2011, 17:11:34 schrieb Dick Munroe:
 I figured out you had to have the QT4 SDK on the system, downloaded and
 installed that.  I configure cmake successfully and the cmake gui shows
 up in my VS 2005 project.  When I try to build it though, the build for
 cmake-gui fails when trying to run rcc.exe in the QT4 sdk.
 
 After some poking around with dependency walker, it appears that two
 DLLs aren't installed on my XP system:
 
 IESHIMS.DLL
 WER.DLL
 
 both of which appear to be related to Vista rather than XP.
 
 Am I hosed? is this a problem with the QT4 SDK? or is there some way to
 get the right DLLs installed?  Downloading IESHIMS seems to work find,
 but I'm faced with a bunch of different WER implementations, none of
 which seem to be for XP.
 
Why do you want to build cmake by yourself at all? Just use the binary version 
and all will work as expected...

Christian
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake with Qt on Windows 7 MinGW

[Christian Ehrlicher]

Am 23.12.2010 12:39, schrieb Lukas Woodtli:



Everything builds without error.
But if I launch my application I get an error :

The procedure entry point _Z17qt_message_output9QtMsgTypePKc could not 
be located in the dynamic link library QtCore4.dll

It's a common problem - you're using the wrong QtCore4.dll


Christian
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] cmake qt4 opengl

[Christian Ehrlicher]

 Original-Nachricht 
 Datum: Mon, 13 Dec 2010 12:48:23 +
 Von: luxInteg 
 An: cmake@cmake.org
 Betreff: [CMake] cmake qt4  opengl

 Greetings,
 
 This is towards banishing  my  cmake/qt4 idiocy.
 
 
 my CMakeLists.txt has these:-
 
 
   FIND_PACKAGE( Qt4 REQUIRED )
 
   set( QT_USE_OPENGL TRUE )

FindQt4.cmake:
# When using the components argument, QT_USE_QT* variables are automatically set
# for the QT_USE_FILE to pick up.  If one wishes to manually set them, the
# available ones to set include:
#QT_DONT_USE_QTCORE
#QT_DONT_USE_QTGUI
...
#QT_USE_QTOPENGL
#QT_USE_QTSQL

HTH
Christian
-- 
Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief!  
Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] makefile to CMakeLists.txt, possible?

[Christian Ehrlicher]

Am Freitag 03 September 2010, 21:19:28 schrieb Alexander Neundorf:
 On Friday 03 September 2010, Michael Jackson wrote:
 ...
 
  I was just thinking about this the other day. One specialized area
  that would be helped by threads would be in some project configuration
  where we have CMake looking for about 20 different headers and another
  20 or so types. Generally none of this is dependent on the other.
  
 Something where I could have a
  
  parallel_section()/end_parallel_section() section where I could
  list all the tests and CMake could run them in parallel if the builder
  allows it or there are enough cpu resources available.
  
 Just a thought.
 
 Maybe really some parallel capability could be added specifically to the
 try_compile() command.
 Which calls cmMakefile::TryCompile(), which calls
 cmGlobalGenerator::TryCompile(), which ends up in
 cmGlobalGenerator::Build(), which finally calls
 
 if (!cmSystemTools::RunSingleCommand(command, outputPtr,
retVal, 0, verbose, timeout))
 
 Maybe just this one call could be put into threads somehow ?
 
A short non-representation 'valgrind -tool=callgrind cmake .' shows that when 
no configure checks need to be done, 25 percent of the time is used for 
strstr() /  SystemTools::ReplaceString() ... wouldn't this be also a good 
point to start optimizing?


Christian
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CTest xml encoding

[Christian Ehrlicher]

David Cole schrieb:
 On Thu, Feb 25, 2010 at 1:33 PM, Christian Ehrlicher
 ch.ehrlic...@gmx.de mailto:ch.ehrlic...@gmx.de wrote:
 
 Am 25.02.2010 18:23, schrieb David Cole:
  Is the Text block exactly the same with cmake 2.6.2 and cmake
  2.8.0...? Can you try it with our latest CMake 2.8.1 release
 candidate?
  ( http://www.cmake.org/files/v2.8/?C=M;O=D )
 
  It should be properly utf-8 encoded with cmake 2.8.1 -- we fixed some
  bugs related to that, but I thought the fix was in the 2.8.0
 release...
 
 Tried with 2.6.2 and 2.8.0 - same result. I'll test 2.8.1rc tomorrow and
 also take a look if 2.8.0 was really used - not that PATH fooled me...
 
  Also, note: for results to show up properly on a CDash dashboard, you
  must update the CDash version to its latest release: 1.6.2...
 
 Did this yesterday :)
 
 Another question: It looks like my test results are not uploaded
 although they're locally available. Any idea what's wrong here or where
 I can start debugging?
 All other xml files show up fine.
 
 
 Does ctest say it had problems submitting Test.xml? You can run it with
 --debug to get more verbose info about what's happening during a
 submission...
 
Ok, all problems solved. The encoding is correct now - tested with
2.8.1rc3. I did not test 2.8.0.

The upload problem was a php config problem. I forgot to install
php-zlib package. I should have looked into the php logfile earlier...

Thx for the help,
Christian
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] CTest xml encoding

[Christian Ehrlicher]

Hi,

I've a problem with the encoding of the build output:
Textlt;-30gt;lt;-128gt;lt;-104gt;PROGNAMElt;-30gt;lt;-128gt;lt;-103gt;
 initialized and declared 
lt;-30gt;lt;-128gt;lt;-104gt;externlt;-30gt;lt;-128gt;lt;-103gt;/Text

The output here is:
warning: ‘PROGNAME’ initialized and declared ‘extern’


I'm using utf-8 as default locale on openSUSE 11.2/64Bit, cmake 2.6.2 and 2.8.0.
I tried to set the LANG to en_US.UTF-8 but it did not help...

What's going wrong here?

Thx,
Christian
-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CTest xml encoding

[Christian Ehrlicher]

Am 25.02.2010 18:23, schrieb David Cole:
 Is the Text block exactly the same with cmake 2.6.2 and cmake
 2.8.0...? Can you try it with our latest CMake 2.8.1 release candidate?
 ( http://www.cmake.org/files/v2.8/?C=M;O=D )
 
 It should be properly utf-8 encoded with cmake 2.8.1 -- we fixed some
 bugs related to that, but I thought the fix was in the 2.8.0 release...
 
Tried with 2.6.2 and 2.8.0 - same result. I'll test 2.8.1rc tomorrow and
also take a look if 2.8.0 was really used - not that PATH fooled me...

 Also, note: for results to show up properly on a CDash dashboard, you
 must update the CDash version to its latest release: 1.6.2...
 
Did this yesterday :)

Another question: It looks like my test results are not uploaded
although they're locally available. Any idea what's wrong here or where
I can start debugging?
All other xml files show up fine.

Thx,
Christian

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Function for visibility definitions

[Christian Ehrlicher]

Hilton Medeiros schrieb:
 Thanks for pointing that mistake, I fixed it.
 
 About g++: g++ is gcc with -lstdc++
 
 What is wrong with a simple CMake file?
 I know what is good about it, if CMake had it built in
 neither me nor any CMake user would need to write neither a simple
 header file nor a simple CMake file.
 
I don't see how this should work without a header file. How should i use
those defines in my source at all?
The better have a simple header-file...


Christian



signature.asc
Description: OpenPGP digital signature
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] How to *not* delete generated files on 'make clean'

[Christian Ehrlicher]

Hi,

I'm using QT4_CREATE_TRANSLATION() to automatically update my ts-files for 
translations. Now my problem is that cmake is to smart and deletes my generated 
ts-files during 'make clean'. Is there a way to work around this? In general 
it's fine that cmake deletes the output of an add_custom_command() but in this 
case ... :)

Thx,
Christian
-- 
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] How to *not* delete generated files on 'make clean'

[Christian Ehrlicher]

 Von: Hendrik Sattler
 Zitat von Christian Ehrlicher
  I'm using QT4_CREATE_TRANSLATION() to automatically update my   
  ts-files for translations. Now my problem is that cmake is to smart   
  and deletes my generated ts-files during 'make clean'. Is there a   
  way to work around this? In general it's fine that cmake deletes the  
   output of an add_custom_command() but in this case ... :)
 
 It is the same as with .po files: there is no sense in automatically  
 updating them on a build (except that it takes time to do so).
 There are two cases:
 - The translations are already up-to-date - no changes.
 - The translations are not up-to-date - after the automatic update,  
 they still don't have any additional translations.
 
I just want to have updated ts-files and then check them in. I don't translate 
the ts-files by myself.
I've an option where I can enable/disable the ts-update. Using an additional 
target would work but... 


Christian
-- 
Hilfe für Haiti! Spende per SMS: Sende UI HAITI an die Nummer 81190.
Von 5 Euro je SMS (zzgl. SMS-Gebühr) gehen 4,83 Euro an UNICEF.
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] [v2.8-rc1] - Strange new warning in FindQt4.cmake

[Christian Ehrlicher]

Hi,

I get this warning:

-8--
CMake Warning (dev) at cmake/modules/FindQt4.cmake:826 (SET):
  Local variable QT4_QTUITOOLS_LIBRARY is set to


optimized;D:/kde/kde-msvc/lib/QtUiTools.lib;debug;D:/kde/kde-msvc/lib/QtUiTo
olsd.lib

  but the CACHE entry of the same name is set to

D:/kde/kde-msvc/lib/QtUiTools.lib

  The local variable is hiding the cache value.

  Policy CMP0015 is not set: The set() CACHE mode and option() command make
  the cache value visible.  Run cmake --help-policy CMP0015 for policy
  details.  Use the cmake_policy command to set the policy and suppress this
  warning.
Call Stack (most recent call first):
  cmake/modules/FindQt4.cmake:859 (_QT4_ADJUST_LIB_VARS)
  cmake/modules/MacroOptionalFindPackage.cmake:19 (FIND_PACKAGE)
  CMakeLists.txt:52 (macro_optional_find_package)
This warning is for project developers.  Use -Wno-dev to suppress it.
-8--


Whats wrong here?

Christian



signature.asc
Description: OpenPGP digital signature
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] [v2.8-rc1] does't find freetype on windows

[Christian Ehrlicher]

Hi,

FiFreetype with 2.8.0-rc1 (and maybe lower) doesn't find freetype on
windows because ft2build.h isn't searched inside include/freetype2
Adding 'include/freetype2' to PATH_SUFFIXES in the first FIND_PATH
statement solves the problem.


Christian



signature.asc
Description: OpenPGP digital signature
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Use FIND_LIBRARY to search link for an executable?

[Christian Ehrlicher]

Hi,

I've an external project which made the decision to create an executable which 
exports symbols. This means if you want to write a plugin for this project you 
have to link your plugin against this executable.
Now I've the problem that FIND_LIBRARY doesn't find this executable. Does 
anybody knows a hack to be able to link against an executable which is not 
built by the project?

I'm really lost here but I can't convince them to fix it... :(
Managing an own patch to work around this problem isn't a good long-term 
perspective.

Thx,
Christian
-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Use FIND_LIBRARY to search link for an executable?

[Christian Ehrlicher]

 Von: Michael Wild
 
 On 18. Sep, 2009, at 8:14, Christian Ehrlicher wrote:
 
  Hi,
 
  I've an external project which made the decision to create an  
  executable which exports symbols. This means if you want to write a  
  plugin for this project you have to link your plugin against this  
  executable.
  Now I've the problem that FIND_LIBRARY doesn't find this executable.  
  Does anybody knows a hack to be able to link against an executable  
  which is not built by the project?
 
  I'm really lost here but I can't convince them to fix it... :(
  Managing an own patch to work around this problem isn't a good long- 
  term perspective.
 
  Thx,
  Christian
 
 find_program?
 
You're right - I did not know that TARGET_LINK_LIBRARIES accepts this.
 And that is a REALLY broken design (and AFAIK only works on Windows).
 
I'm currently investigating and think it doesn't work on linux at all (which 
would be very good for me). I'm getting duplicate symbols :)

--
FIND_PROGRAM(STAGE_LIB STAGE PATHS /opt/3dviewer/bin)
ADD_LIBRARY(dummy SHARED dummy.cpp)
TARGET_LINK_LIBRARIES(dummy ${STAGE_LIB})
--
/usr/local/bin/c++  -fPIC -g  -shared -Wl,-soname,libdummy.so -o libdummy.so 
CMakeFiles/dummy.dir/dummy.cpp.o /opt/3dviewer/bin/STAGE
/opt/3dviewer/bin/STAGE: In function `_fini':
/usr/src/packages/BUILD/glibc-2.9/cc-nptl/csu/crti.S:37: multiple definition of 
`_fini'
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../lib64/crti.o:/usr/src/packages/BUILD/glibc-2.9/cc-nptl/csu/crti.S:37:
 first defined here
/opt/3dviewer/bin/STAGE: In function `_init':
/usr/src/packages/BUILD/glibc-2.9/cc-nptl/csu/crti.S:25: multiple definition of 
`_init'
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../lib64/crti.o:/usr/src/packages/BUILD/glibc-2.9/cc-nptl/csu/crti.S:25:
 first defined here
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: 
libdummy.so: version node not found for symbol vtable for 
__cxxabiv1::__class_type_info@@CXXABI_1.3
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: 
failed to set dynamic section sizes: Bad value
collect2: ld returned 1 exit status
--

I should have tried this earlier :)

Thx,
Christian

-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] How to build 2 targets from the same source, differing in -D_SWITCHES_ only

[Christian Ehrlicher]

 Von: Marcel Loose lo...@astron.nl
 CC: cmake@cmake.org
 Betreff: Re: [CMake] How to build 2 targets from the same source, 
 differing in -D_SWITCHES_ only

 Hi Eike,
 
 I think the only safe and reliable way to do this is create several
 build directories, e.g. build/type_1 and build/type_2.
 When running cmake in build/type_1, you should add -D_TYPE1_ to the
 preprocessor flags; same for build/type_2.
 
Why? Does SET_TARGET_PROPERTIES() with COMPILE_FLAGS not work?


Christian
-- 
Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate
für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] FindQt4.cmake returns too much irrelevant information

[Christian Ehrlicher]

Alan W. Irwin schrieb:
 I have just discovered that for -DCMAKE_BUILD_TYPE=Debug, the
 combination of
 FindQt4.cmake and UseQt4.cmake inserts the keywords debug, optimized, AND
 general into the QT_LIBRARIES list to divide the list into three sections.
 But only the debug section of that list is used by target_link_libraries
 for
 the -DCMAKE_BUILD_TYPE=Debug case.
 
 Could we have a cleaner design that doesn't specify the
 target_link_libraries keywords and which simply returns in QT_LIBRARIES
 whatever is relevant for the CMAKE_BUILD_TYPE that is specified?
 
CMAKE_BUILD_TYPE is not set for MSVC and other IDE generators so this
will not work. This would also mean that you can't change the buildtype
without doing a complete research of the existing libraries.
And CMAKE_BUILD_TYPE isn't use for some generators + is not set when you
run cmake on a clean builddir without any options.


Christian
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Moving QT getting FIND_PACKAGE( Qt4 ) to work

[Christian Ehrlicher]

Am Montag 27 April 2009 18:47:07 schrieb Anders Backman:
 Hi all.
 I have a problem where I pack the necessary stuff from qt into a dependency
 zip file (.h, .lib, .dll and qmake.exe).

 I have the path to qmake setup, so that qmake can be found.

 Then I unpack that to some specified directory and run cmake on my own
 code.

 My projectgs CMakeLists.txt call FIND_PACKAGE( Qt4 ) which among other
 things call:

 qmake -query QT_INSTALL_LIBS (

 Now this returns with the ORIGINAL build directory, not the new one where
 qmake actually exists.

 Is there anything one can do to fix this?
 I want CMake to use qmake so that it can locate things in relative to where
 qmake actually is, and not where it was when I built qt.
This is not a cmake problem - you can't move the qt installation around. If 
you want to do this you have to provide a proper qt.conf ( 
http://doc.trolltech.com/4.5/qt-conf.html )

HTH
Christian
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Why does cmake adds /STACK:10000000 for msvc linker?

[Christian Ehrlicher]

Hi,

I don't understand the reason behind this. We've a very huge memory
footprint because of this on kde4/windows - kded4.exe has ~30 Threads
which means 300MB of stack!

Is there an easy way to change this?


Thx,
Christian
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] How can I manage the Qt4's .rc file with CMake?

[Christian Ehrlicher]

Kermit Mei schrieb:
 On Mon, 2009-03-30 at 18:15 +0200, Pau Garcia i Quiles wrote:
 On Mon, Mar 30, 2009 at 6:04 PM, Kermit Mei kermit@gmail.com wrote:
 Hello community! I want to change my program's icon on windows, and it
 wrote with Qt4. I looked up the assistant, it told me the following.

 But I don't know how to use it in cmake?
 Just add the .rc file to the sources list, like it was another .cpp file:

 ADD_EXECUTABLE( myexe source1.cpp source2.cpp resource.rc )

 And, another question: If I use MinGW+Qt, but not M$ VC++, can I use it?
 I think so, yes.
 
 Hi Pau, What you said I have tried. But nothing changed in the view of
 myexe, it is also a ugly white area with a blue barrier;p
 I do it like this:
 IF(WIN32)
   ADD_EXECUTABLE(qfrt WIN32 qfrt.cpp qfrt.rc)
 ELSE(WIN32)
   ADD_EXECUTABLE(qfrt qfrt.cpp)
 ENDIF(WIN32)
 
 And the content of qfrt.rc is:
 IDI_ICON1   ICONDISCARDABLE :/icon/myapp.ico
 
 and I also tried ./gui/icon/myapp.ico where the .ico file exists.
 
 Thank you, all the same. And hope more help;p
 
This is working fine on windows with msvc but will not work with mingw:
http://public.kitware.com/Bug/view.php?id=4068


Christian
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] [Cmake] How to delete cache files? Debug, Release Configuration

[Christian Ehrlicher]

 Von: Nadir SOUALEM
 In my CMakeLists.txt, i use such things like:
 
 FIND_LIBRARY(LIB_UMFPACK LIB_UMFPACK 
 /opt/UMFPACK5.0.3/build/linux_eclipse/LIB_UMFPACK/${CMAKE_BUILD_TYPE})
 
 So when i run:
 cmake -DCMAKE_BUILD_TYPE=Debug
 
 in my CMakeCache.txt, i find
 
 //Path to a library.
 LIB_UMFPACK:FILEPATH=/opt/UMFPACK5.0.3/build/linux_eclipse/LIB_UMFPACK/Debug/libLIB_UMFPACK.a
 
 When i try to do:
 cmake -DCMAKE_BUILD_TYPE=Release
 
 in my CMakeCache.txt, i still  find libLIB_UMFPACK.a on Debug Mode:
 //Path to a library.
 LIB_UMFPACK:FILEPATH=/opt/UMFPACK5.0.3/build/linux_eclipse/LIB_UMFPACK/Debug/libLIB_UMFPACK.a
 
 if i remove CMakeCache.txt:
 rm CMakeCache.txt
 
 and i try
 cmake -DCMAKE_BUILD_TYPE=Release
 
 I found the good mode ... So, my question is the following one:
 is there a way (command line, configuration of CMakeLists.txt, ...) to 
 force reloading my CMakeCache.txt,
cd build-dir  rm -rf *  cmake source_dir
If you want to have a single command, write an alias.


Christian


-- 
Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: 
http://www.gmx.net/de/go/multimessenger01
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake and multiple Microsoft compilers on windows

[Christian Ehrlicher]

John Drescher schrieb:

On my windows XP box, I have VC6, 2003, 2005 and 2008 installed and I
have selected VS2005 for the build however all the CMake checks are
happening for VC6. It does not seem to cause any harm but what about
header and library differences between the compilers? I mean all the
checks for stl ... are probably for the stl that is included with vc6
and not vs2005 (which I know is not the same).

You have to make sure your build environment is set up correct. This is 
normally done by selecting the correct 'Visual Studio Command Prompt' 
from the start menu.



HTH
Christian
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake and multiple Microsoft compilers on windows

[Christian Ehrlicher]

John Drescher schrieb:

On Fri, Mar 20, 2009 at 3:02 PM, Christian Ehrlicher
ch.ehrlic...@gmx.de wrote:

John Drescher schrieb:

On my windows XP box, I have VC6, 2003, 2005 and 2008 installed and I
have selected VS2005 for the build however all the CMake checks are
happening for VC6. It does not seem to cause any harm but what about
header and library differences between the compilers? I mean all the
checks for stl ... are probably for the stl that is included with vc6
and not vs2005 (which I know is not the same).


You have to make sure your build environment is set up correct. This is
normally done by selecting the correct 'Visual Studio Command Prompt' from
the start menu.



Makes sense. So then I should be opening cmake-gui from the compiler's
command prompt instead of the shortcut on the desktop. Not a big deal
I am one to use the command prompt all the time windows or linux..


I'm not very familar with cmake-gui but I don't see another option.

Christian
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Bug? CMP0008 and inability to use .a libraries with MSVC

[Christian Ehrlicher]

 Von: Braddock Gaskill
 I am unable to use static GnuWin32 libraries using the lib*.a naming
 convention with an MSVC 8 2005 target.
 
.a libraries are static libraries for MinGW. When you're using msvc you have to 
link against .lib.
It sometimes works that msvc can also link against a .a but that's not intented 
and therefore cmake doesn't allow it.


Christian
-- 
Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: 
http://www.gmx.net/de/go/multimessenger01
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Toggling a Preprocessor macro for targets within a single project

[Christian Ehrlicher]

 Von: Andreas Pokorny
 Hello,
 Wow that was fast. Thanks a lot.
 
 2009/2/20 Eric Noulard eric.noul...@gmail.com:
  [...]
 
  SET_TARGET_PROPERTIES(PlatformLib PROPERTIES
  DEFINE_SYMBOL USE_TRACER)
 
  Then you shouldn't have to ADD_DEFINITIONS and REMOVE_DEFINITIONS?
 
 
 I do not understand why.. but DEFINE_SYMBOL did not work, but
 COMPILE_FLAGS -DUSE_TRACER
 did. So SET_TARGET_PROPERTIES is the sledgehammer for getting it done :)
 
DEFINE_SYMBOL only works for shared libraries. see cmake documentation: 
DEFINE_SYMBOL sets the name of the preprocessor symbol defined when compiling 
sources in a shared library.


Christian
-- 
Jetzt 1 Monat kostenlos! GMX FreeDSL - Telefonanschluss + DSL 
für nur 17,95 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Toggling a Preprocessor macro for targets within a single project

[Christian Ehrlicher]

Michael Jackson schrieb:
 
 On Feb 20, 2009, at 4:59 AM, Eric Noulard wrote:
 
 2009/2/20 Christian Ehrlicher ch.ehrlic...@gmx.de:
 Von: Andreas Pokorny
 Hello,
 Wow that was fast. Thanks a lot.

 Obviously I was too fast reading the doc :-)

 [...]

 SET_TARGET_PROPERTIES(PlatformLib PROPERTIES
DEFINE_SYMBOL USE_TRACER)

 Then you shouldn't have to ADD_DEFINITIONS and REMOVE_DEFINITIONS?


 I do not understand why.. but DEFINE_SYMBOL did not work, but
 COMPILE_FLAGS -DUSE_TRACER
 did. So SET_TARGET_PROPERTIES is the sledgehammer for getting it
 done :)

 DEFINE_SYMBOL only works for shared libraries. see cmake
 documentation: DEFINE_SYMBOL sets the name of the preprocessor
 symbol defined when compiling sources in a shared library.

 Thank you  Christian
 ...for reading the doc more carefully  than I do :-)


 -- 
 Erk

 
 and I _think_ that DEFINE_SYMBOL only will work on windows as it is
 there to facilitate the dllImport/dllexport functionality used by
 windows for exporting/importing symbols from shared libraries.
 
 I may be wrong on that as I am going on memory at this point.
 
This is wrong - you've a similar option with gcc - the visibility attribute.


Christian



signature.asc
Description: OpenPGP digital signature
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] FindBoost.cmake

[Christian Ehrlicher]

Patrick Spendrin schrieb:

Hello,

as I am just working with some boost headers that do reside in a 
different include directory, I would like to ask to apply the appended 
patch.
It will not only find versions where headers are in 
prefix/include/boost/boost_1_34 (which is currently the default for 
windows) but also prefix/include/boost/boost-1_34 (as it is currently on 
non-Win32 platforms).
The patch would only lead to unwanted effects if somebody is using the 
difference between win32 and non-win32 versions currently (e.g. he has 
boost-1_34 and boost_1_34 in the same directory). As this seems to 
strange to be used, I'd think the patch is safe enough to be applied.


There's an open bug to fix this here: 
http://public.kitware.com/Bug/view.php?id=8173


But no reaction so far...


Christian



signature.asc
Description: OpenPGP digital signature
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] FindBoost (once again...)

[Christian Ehrlicher]

Hi,

FindBoost does not work for me on windows because of a wrong pathname:

  if (WIN32 AND NOT CYGWIN)
set(_boost_PATH_SUFFIX boost_${_boost_VER})
  else (WIN32 AND NOT CYGWIN)
set(_boost_PATH_SUFFIX boost-${_boost_VER})
  endif (WIN32 AND NOT CYGWIN)

I installed boost with bjam and a directory prefix/include/boost-1_37/ 
is created. Therefore the above assumption that it's boost_1_37 is wrong.


Also the latest cvs binary for win32 still does not have support for 
boost 1.37.



Christian
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] FindBoost (once again...)

[Christian Ehrlicher]

Andreas Pakulat schrieb:

On 23.11.08 14:43:19, Christian Ehrlicher wrote:

Hi,

FindBoost does not work for me on windows because of a wrong pathname:

  if (WIN32 AND NOT CYGWIN)
set(_boost_PATH_SUFFIX boost_${_boost_VER})
  else (WIN32 AND NOT CYGWIN)
set(_boost_PATH_SUFFIX boost-${_boost_VER})
  endif (WIN32 AND NOT CYGWIN)

I installed boost with bjam and a directory prefix/include/boost-1_37/  
is created. Therefore the above assumption that it's boost_1_37 is wrong.


I suspect that the author used a binary boost package, but IIRC it wasn't
me, so don't really know.


But why should the binary packages use another include dir? Strange... :(
Also the latest cvs binary for win32 still does not have support for  
boost 1.37.


Thats not a problem, see the top of FindBoost.cmake, you can set
Boost_ADDITIONAL_VERSIONS prior to find_package to use newer boost
packages.


Good idea but the sources are not mine.
And I don't care that 2.6.2 did not find it but 1.37 is out since three 
weeks and cmake cvs still doesn't contain this version so I wanted to 
make sure it's in 2.6.3 :)



Christian



signature.asc
Description: OpenPGP digital signature
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Does CMAKE_DEBUG_POSTFIX not affect executables?

[Christian Ehrlicher]

Hi,

Looks like CMAKE_DEBUG_POSTFIX does not affect executables anymore:

8--
set(CMAKE_DEBUG_POSTFIX d)
add_executable(test main.cpp)
#set_target_properties(test PROPERTIES DEBUG_POSTFIX d)

get_target_property(dbg_location test DEBUG_LOCATION)
message(STATUS dbg_location: ${dbg_location})
8--
result:
...
-- dbg_location: /home/ehrlicher_c/cmake-test/test

The documentation says that CMAKE_DEBUG_POSTFIX affects all targets.
set_target_properties(test PROPERTIES DEBUG_POSTFIX d) does successfully change 
the debug postfix for the specified target.


Is this a bug or did I understand something wrong?

Thx,
Christian
-- 
Feel free - 5 GB Mailbox, 50 FreeSMS/Monat ...
Jetzt GMX ProMail testen: http://www.gmx.net/de/go/promail
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] get_target_property(...LOCATION) does not handle DEBUG_POSTFIX in vcproj mode

[Christian Ehrlicher]

Hi,

When creating a VisualStudio project, get_target_property(...LOCATION) does not 
handle DEBUG_POSTFIX correct. I always get the target name without the debug 
postfix.
I need to do some post build steps but due to the wrong targetname it's 
currently impossible... so is this a bug or a known limitiation? And how to 
work around this?


Thx,
Christian
-- 
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten 
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] [cmake] windows dll and TARGET_LINK_LIBRARIES

[Christian Ehrlicher]

 Original-Nachricht 
 Datum: Fri, 10 Oct 2008 09:21:12 +0200
 Von: Sören Freudiger [EMAIL PROTECTED]
 An: cmake@cmake.org
 Betreff: [CMake] [cmake] windows dll and TARGET_LINK_LIBRARIES

 Hi
 How to handle windows dll dependences in CMake.
 
 
 CMakeList.txt
 =
 
 ADD_LIBRARY(MY_DLL MODULE  ${ALL_SOURCES} ) #-- MSVC generates MY_DLL.dll
 and one
 # small MY_DLL.lib that has to
 be linked
 # to projects using MY_DLL.dll
 
 ADD_EXECUTABLE(test main.cpp)
 TARGET_LINK_LIBRARIES(test.exe MY_DLL) #-- CMake error. module linking
 not
 possible
 
 # HACK:
 IF(WIN32)
   TARGET_LINK_LIBRARIES(test.exe
 $(SolutionDir)$(ConfigurationName)\\${LIB_NAME}.lib) 
 ENDIF()
 
 =
   
 Question:
 How do I avoid the hack??
 
By using the correct add_library keyword SHARED instead MODULE. See cmake 
documentation:
... MODULE libraries are plugins that are not linked into other targets but 
may be loaded dynamically at runtime using dlopen-like functionality.

HTH
Christian
-- 
GMX Kostenlose Spiele: Einfach online spielen und Spaß haben mit Pastry Passion!
http://games.entertainment.gmx.net/de/entertainment/games/free/puzzle/6169196
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] [New Module] FindXXX module for RTI

[Christian Ehrlicher]

Gotthard, Petr schrieb:

Philip,
 
I have updated the FindRTI.cmake based on your comments. Many thanks.
 
One explanation:
I have to manipulate CMAKE_FIND_LIBRARY_PREFIXES because under Windows 
some RTI libraries have the lib prefix, while others don't. (By 
default there is no lib prefix under Windows.) I thought it may be 
safer to allow both  and lib prefixes under all systems.
 

This is ... wrong :)

In 'normal' cases libfoo.dll is a mingw dll, foo.dll a msvc one and 
cygfoo.dll a cygwin dll. But nobody seems to care :(



Christian



signature.asc
Description: OpenPGP digital signature
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] how to link with a system library ?

[Christian Ehrlicher]

Steven Samuel Cole schrieb:

Eric Noulard schrieb:

2008/9/21 Steven Samuel Cole [EMAIL PROTECTED]:
I would like to link a system library into an executable, GTK in this 
case.

What I'm trying to do is

include(FindGTK)

target_link_libraries(myexec $GTK_LIBRARIES)

add_executable (myexec sources)

Result:

CMake Error: Attempt to add link library GTK_LIBRARIES to target 
myexec

which is not built by this project.

What am I doing wrong ?


You may be missing curly brace around variable could you try:


target_link_libraries(myexec ${GTK_LIBRARIES})



Thanks for your help! :-)

${GTK_LIBRARIES} instead of $GTK_LIBRARIES fixes the CMake Error 
problem, but I still get GTK link errors. Also, even though I do 
include_directories(${GTK_INCLUDE_DIR}), I still get

gtk/gtk.h: No such file or directory.

Has anyone ever seen this working ?

Are you sure you have set GTK_INCLUDE_DIR at all?

- cmake documentation FIND_PACKAGE() should help here



Christian



signature.asc
Description: OpenPGP digital signature
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Query about FindXXX files

[Christian Ehrlicher]

Leo Breebaart schrieb:

In CMake 2.6.1, the header for FindTIFF.cmake says:

# This module defines
#  TIFF_INCLUDE_DIR, where to find tiff.h, etc.
#  TIFF_LIBRARIES, libraries to link against to use TIFF.
#  TIFF_FOUND, If false, do not try to use TIFF.
# also defined, but not for general use are
#  TIFF_LIBRARY, where to find the TIFF library.

However, after executing:

  FIND_PACKAGE(TIFF)

my CMakeCache.txt now has the following entries:

TIFF_INCLUDE_DIR:PATH=/usr/include
TIFF_LIBRARY:FILEPATH=/usr/lib/libtiff.so

So, in other words, the not for general use TIFF_LIBRARY
variable is placed in my cache, while the promised TIFF_LIBRARIES
variable is not.

Is there a reason why you want to have the other vars in CMakeCache.txt? 
Isn't it enough to have them available?



Christian
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Query about FindXXX files

[Christian Ehrlicher]

Leo Breebaart schrieb:

Christian Ehrlicher [EMAIL PROTECTED] writes:


Leo Breebaart schrieb:

In CMake 2.6.1, the header for FindTIFF.cmake says:

# This module defines
#  TIFF_INCLUDE_DIR, where to find tiff.h, etc.
#  TIFF_LIBRARIES, libraries to link against to use TIFF.
#  TIFF_FOUND, If false, do not try to use TIFF.
# also defined, but not for general use are
#  TIFF_LIBRARY, where to find the TIFF library.

However, after executing:

  FIND_PACKAGE(TIFF)

my CMakeCache.txt now has the following entries:

TIFF_INCLUDE_DIR:PATH=/usr/include
TIFF_LIBRARY:FILEPATH=/usr/lib/libtiff.so

So, in other words, the not for general use TIFF_LIBRARY
variable is placed in my cache, while the promised TIFF_LIBRARIES
variable is not.

Is there a reason why you want to have the other vars in
CMakeCache.txt? Isn't it enough to have them available?


Yes, it should be, I suppose. 


My use case is that I have in my sources a 3rd party non-CMake
library that I need to include in my overall build. So I have
'cmakified' that library, and since it relies on libtiff, I call
the FIND_PACKAGE(TIFF) in that CMakeFile, so it can also compile
standalone.

Now elsewhere in my sources I have an application that actually
uses the 3rd party library, but which of course still needs to
link to libtiff as well. So I was attempting to add
${TIFF_LIBRARIES} to that application's TARGET_LINK_LIBRARIES,
when I discovered the issues in my earlier message.

Once you called FIND_PACKAGE(TIFF) all TIFF_foo vars are set to the 
correct value - at least it should be (and I never had problems with this)



Christian



signature.asc
Description: OpenPGP digital signature
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] cmake + Qt4 compilation problem

[Christian Ehrlicher]

 Von: Luis Roberto P. Paula
 Hello everyone!
 
 I'm trying to compile a simple application using Qt4 with cmake, but I'm
 stucked in this error:
 
 [ 33%] Generating ui_mivgui.h
 Scanning dependencies of target viewer
 [ 66%] Building CXX object CMakeFiles/viewer.dir/main.o
 [100%] Building CXX object CMakeFiles/viewer.dir/mivgui.o
 Linking CXX executable viewer
 CMakeFiles/viewer.dir/mivgui.o: In function `MivGui::MivGui(QWidget*)':
 mivgui.cxx:(.text+0x14e): undefined reference to `vtable for MivGui'
 mivgui.cxx:(.text+0x158): undefined reference to `vtable for MivGui'
 CMakeFiles/viewer.dir/mivgui.o: In function `MivGui::MivGui(QWidget*)':
 mivgui.cxx:(.text+0x2c6): undefined reference to `vtable for MivGui'
 mivgui.cxx:(.text+0x2d0): undefined reference to `vtable for MivGui'
 CMakeFiles/viewer.dir/mivgui.o: In function `MivGui::tr(char const*, char
 const*)':
 mivgui.cxx:(.text._ZN6MivGui2trEPKcS1_[MivGui::tr(char const*, char
 const*)]+0x1e): undefined reference to `MivGui::staticMetaObject'
 collect2: ld returned 1 exit status
 make[2]: *** [viewer] Error 1
 make[1]: *** [CMakeFiles/viewer.dir/all] Error 2
 make: *** [all] Error 2
 
snip
 
 CMakeLists.txt
 --
 
 SET(SOURCES_CPP
  main.cxx
  mivgui.cxx)
 MESSAGE( STATUS ${SOURCES_CPP} )
 
 SET(SOURCES_H
  mivgui.h)
 MESSAGE( STATUS ${SOURCES_H} )
 
 SET(SOURCES_UI
  mivgui.ui)
 MESSAGE( STATUS ${SOURCES_UI} )
 
 FIND_PACKAGE(Qt4 REQUIRED)
 
 include(${QT_USE_FILE})
 
 QT4_WRAP_UI(SOURCES_UI_H ${SOURCES_UI})
 
 #qt4_automoc(${SOURCES_H})
 
Why did you comment out this line?
You need to moc your header - otherwise you'll get linker errors like above.


Christian
-- 
GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
Jetzt dabei sein: http://www.shortview.de/[EMAIL PROTECTED]
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] cmake + Qt4 compilation problem

[Christian Ehrlicher]

 Von: Christian Ehrlicher 
  Von: Luis Roberto P. Paula
  Hello everyone!
  
  I'm trying to compile a simple application using Qt4 with cmake, but I'm
  stucked in this error:
  
  [ 33%] Generating ui_mivgui.h
  Scanning dependencies of target viewer
  [ 66%] Building CXX object CMakeFiles/viewer.dir/main.o
  [100%] Building CXX object CMakeFiles/viewer.dir/mivgui.o
  Linking CXX executable viewer
  CMakeFiles/viewer.dir/mivgui.o: In function `MivGui::MivGui(QWidget*)':
  mivgui.cxx:(.text+0x14e): undefined reference to `vtable for MivGui'
  mivgui.cxx:(.text+0x158): undefined reference to `vtable for MivGui'
  CMakeFiles/viewer.dir/mivgui.o: In function `MivGui::MivGui(QWidget*)':
  mivgui.cxx:(.text+0x2c6): undefined reference to `vtable for MivGui'
  mivgui.cxx:(.text+0x2d0): undefined reference to `vtable for MivGui'
  CMakeFiles/viewer.dir/mivgui.o: In function `MivGui::tr(char const*,
 char
  const*)':
  mivgui.cxx:(.text._ZN6MivGui2trEPKcS1_[MivGui::tr(char const*, char
  const*)]+0x1e): undefined reference to `MivGui::staticMetaObject'
  collect2: ld returned 1 exit status
  make[2]: *** [viewer] Error 1
  make[1]: *** [CMakeFiles/viewer.dir/all] Error 2
  make: *** [all] Error 2
  
 snip
  
  CMakeLists.txt
 
 --
  
  SET(SOURCES_CPP
   main.cxx
   mivgui.cxx)
  MESSAGE( STATUS ${SOURCES_CPP} )
  
  SET(SOURCES_H
   mivgui.h)
  MESSAGE( STATUS ${SOURCES_H} )
  
  SET(SOURCES_UI
   mivgui.ui)
  MESSAGE( STATUS ${SOURCES_UI} )
  
  FIND_PACKAGE(Qt4 REQUIRED)
  
  include(${QT_USE_FILE})
  
  QT4_WRAP_UI(SOURCES_UI_H ${SOURCES_UI})
  
  #qt4_automoc(${SOURCES_H})
  
 Why did you comment out this line?
 You need to moc your header - otherwise you'll get linker errors like
 above.
 
 
Oh, I frogot something.

You've to add '#include mivgui.moc' at the end of mivgui.cxx to make sure 
automoc works like expected.
This is because cmake uses the 'automake-way' of creating moc files. Search 
cmake wiki and mailing list - this was discussed often :)


HTH
Christian

-- 
GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
Jetzt dabei sein: http://www.shortview.de/[EMAIL PROTECTED]
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Install path problem on MinGW

[Christian Ehrlicher]

Jussi Pakkanen schrieb:

Hi

I'm using CMake for Cuneiform (https://launchpad.net/cuneiform-linux). In my 
root CMakeLists.txt I have effectively the following:

set(LIBDIR lib)

And then in source subdirectories I build shared libraries and install them with

install(TARGETS [library name] LIBRARY DESTINATION ${LIBDIR})

This works perfectly on Linux, OSX and FreeBSD. Recently a user tried to build 
Cuneiform with MinGW. He reports that the install command mentioned above gives 
the following kinds of errors (one for each library):

CMake Error at cuneiform_src/Kern/ccom/CMakeLists.txt:7 (install):
  install Library TARGETS given no DESTINATION!

CMake then stops without generating makefiles. I asked him to add 
message(STATUS Lib subpath in ccom is ${LIBDIR}.) above the install command. CMake prints the correct value for LIBDIR so it should be set properly.


What could be causing this? I have no Windows machines so I can't debug this 
myself, nor do I have all that much MinGW experience.

Thanks for your help.


You only install the LIBRARY but not the ARCHIVE (the static import lib 
automatically created when you export functions from a lib on windows). 
A static library is also treated as ARCHIVE by cmake on windows.

So either remove LIBRARY or add a destination for ARCHIVE.
Another thing which comes to my mind is that a library is treated as 
RUNTIME - but I'm unsure atm :)


So best is - remove 'LIBRARY' and you'll be fine.


HTH
Christian



signature.asc
Description: OpenPGP digital signature
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] The right way to link a library from multiple directories

[Christian Ehrlicher]

Sebastian Krause schrieb:

Andreas Pakulat [EMAIL PROTECTED] wrote:

Thats not going to work on all platforms. There are various platforms
which don't allow static libs to be linked into shared libs.

But it should be possible to gather the sources in the subdirs into a
variable that the parent cmake-file knows and pre-sets to empty. And
then also set the compile flags by using set_source_files_properties().


Yup, that's the other way I already tried. But that way had two
problems:

- In Visual Studio all files were shown as if they would belong to
  the same directory, the directory structure I have in the file
  system is not represented in VS. Is there a way to manually define
  how the file structure should be shown in IDEs?

Search http://www.cmake.org/Wiki/CMake_2.6.0_Docs for 'source_group'


- The whole project contains about 1000 files and MinGW fails on
  linking. I still have to find out the exact error, but I was
  suspecting that it might be because of the maximum length of the
  parameters.


Use cmake 2.6


HTH
Christian



signature.asc
Description: OpenPGP digital signature
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] make arguments

[Christian Ehrlicher]

 Von: Milan Dorak
 I can't find in documentation or anywhere else, how can i pass argument 
 to make command.
 I need 'make -j 3'. don't care if it's in CMakeLists.txt or CTest script.
 
Since when does cmake executes make directly? It's only creating makefiles for 
make...


Christian
-- 
GMX Kostenlose Spiele: Einfach online spielen und Spaß haben mit Pastry Passion!
http://games.entertainment.gmx.net/de/entertainment/games/free/puzzle/6169196
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Add_definitions() also affects RC_FLAGS ?

[Christian Ehrlicher]

Hi,

We've something like this in one of our scripts:

add_definitions(-EHsc)
and we add a .rc - file to the sources.
Now rc.exe fails because of unknown command '-EHsc' because 
add_defintions() is also dded to RC_FLAGS... :(


[ 85%] Building RC object ksirk/ksirk/CMakeFiles/ksirk.dir/ksirk.res
fatal error RC1106: invalid option: -EHsc


Any idea how to fix this?
Christian
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Add_definitions() also affects RC_FLAGS ?

[Christian Ehrlicher]

Bill Hoffman schrieb:

Christian Ehrlicher wrote:

Hi,

We've something like this in one of our scripts:

add_definitions(-EHsc)
and we add a .rc - file to the sources.
Now rc.exe fails because of unknown command '-EHsc' because 
add_defintions() is also dded to RC_FLAGS... :(


[ 85%] Building RC object ksirk/ksirk/CMakeFiles/ksirk.dir/ksirk.res
fatal error RC1106: invalid option: -EHsc


Any idea how to fix this?



Don't use add_definitions for compiler flags.  Use CMAKE_CXX_FLAGS or 
CMAKE_C_FLAGS.



thx,
Christian
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] porting to cmake 2.6 from 2.4.6

[Christian Ehrlicher]

 Von: David Blado
 Hi all,
 
 I recently took up the task of porting to 2.6 (again…fell off my plate
 for a while ☺ )
 
 I’m seeing this when running cmake:
 CMake Error: Cannot determine link language for target libraryX.
 
 All of the source files listed are cpp files:
 SET(SRCS
   fileA
 )
 
 fileA is really fileA.cpp but I’ve noticed that I can ignore the .cpp
 extension and CMake will find it.
 
Here you answered your question by your own - don't forget to add the .cpp 
extension. I would say that it worked with 2.4 was by accident. I can't find 
any documentation which says that this is possible.


Christian
-- 
GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
Jetzt dabei sein: http://www.shortview.de/[EMAIL PROTECTED]
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] eclipse nmake include folders

[Christian Ehrlicher]

 Von: Mehdi Rabah
 On Tue, Jun 17, 2008 at 9:24 PM, Christian Ehrlicher [EMAIL PROTECTED]
 wrote:
 
  Bill Hoffman schrieb:
 
  Alexander Neundorf wrote:
 
  On Tuesday 17 June 2008, Christian Ehrlicher wrote:
  ...
 
  How do you define which vsvars32.bat (or vsvars64.bat) to use? I've
 more
  than one compiler on my system...
 
 
  The first time you would have to run cmake in the right environment
 (i.e.
  where the correct vcvars.bat has been executed).
  But I don't have a windows here, so I am not the best person for
 this...
 
 
  I realize some people get confused by this.  However, I don't think it
 is
  too much to ask that you have a correct environment setup for using the
  compiler.  We ask no less on Linux/Unix.  If gcc is incorrectly
 installed,
  and can't find headers, we don't try and add -I stuff to fix the
 problem...
 
   That's my opinion too - I don't see the point why it should be so hard
 to
  set up the correct environment so that it must be done by cmake.
 
 
 Hi,
 
 The point is not to setup the compiler, it is to have cmake include path
 pointing to standard locations. For example where STL header are
 (like/usr/lib/gcc-lib/i386-redhat-linux/3.3.2/include on
 linux), to avoid extra configurations step in the IDE, not for the
 compiler.
 I talk especially about Eclipse CDT, in which STL automatic completion
 work
 well under linux, but not under windows.

This looks like a Eclipse bug rather than something cmake can do for you. As 
you already said - they're standard locations for the compiler so why should 
cmake care in any way?
And as before - I've more than one compiler on my system...


Christian

-- 
GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
Jetzt dabei sein: http://www.shortview.de/[EMAIL PROTECTED]
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] eclipse nmake include folders

[Christian Ehrlicher]

Alexander Neundorf schrieb:

On Tuesday 17 June 2008, Bill Hoffman wrote:

Alexander Neundorf wrote:

Currently, for the NMake generator one needs to have sourced the
vsvars32.bat file to set up the environment so that cmake can find the
tools etc. Since, the user sources this file at CMake time and then
this environment will not be available when running eclipse, I put the
the values of: PATH, INCLUDE, LIB, and LIBPATH into the .project file
under

If somebody comes up with a nice way to do this automatically (like
reading the env. vars on the first cmake run, converting them into cmake
vars and storing them in the cache so they can be used later on with
include_directories() etc.) maybe the cmake devs would accept such a
patch.

Not so easy.  Those variables have to be around at make time, and not
just cmake time.  I suppose you could push all that to the command line
of the compiler.   You would have to modify the -I and -LIBPATH for all
invocations of the compiler. 


Some file like Modules/Platforms/Windows-cl.cmake could on the first run:
-get these env vars
-convert them to cmake vars
-call include_directories(the converted INCLUDE)
-call link_directories(the converted LIBPATH)
-call link_libraries(the converted LIB)

Would this or something in that direction work ?

How do you define which vsvars32.bat (or vsvars64.bat) to use? I've more 
than one compiler on my system...



Christian
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] eclipse nmake include folders

[Christian Ehrlicher]

Bill Hoffman schrieb:

Alexander Neundorf wrote:

On Tuesday 17 June 2008, Christian Ehrlicher wrote:
...

How do you define which vsvars32.bat (or vsvars64.bat) to use? I've more
than one compiler on my system...


The first time you would have to run cmake in the right environment 
(i.e. where the correct vcvars.bat has been executed).

But I don't have a windows here, so I am not the best person for this...



I realize some people get confused by this.  However, I don't think it 
is too much to ask that you have a correct environment setup for using 
the compiler.  We ask no less on Linux/Unix.  If gcc is incorrectly 
installed, and can't find headers, we don't try and add -I stuff to fix 
the problem...


That's my opinion too - I don't see the point why it should be so hard 
to set up the correct environment so that it must be done by cmake.



Christian
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] shared libraries .lib .dll

[Christian Ehrlicher]

 Von: Ingrid Kemgoum
 hi
 i've done what you told be (not to define de -D..) and i do have a .lib
 too
 but the problem of the link with the dll still exist.
 maybe it's my fault
 there is my code in the three directories(i'm using visual 8 2005 and
 cmake
 2.6)
When you don't define the -DMAKE_FOO than you have the same problem like in the 
beginning. The .lib is there because you did not make a clean build after the 
change (so it's an old one).
See SET_TARGET_PROPERTIES and DEFINE_SYMBOL how to define a symbol for a single 
target only.


Christian
-- 
GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
Jetzt dabei sein: http://www.shortview.de/[EMAIL PROTECTED]
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] shared libraries .lib .dll

[Christian Ehrlicher]

 Von: Ingrid Kemgoum 

 i'm very sorry but it's like chinese for me. u told me not to define the
 symbol so i skip the
 SET_TARGET_PROPERTIES(Hello PROPERTIES DEFINE_SYMBOL HELLO_EXPORTS) in the
 library directory
 
 and when i dont use it i have 2 link problems like this:
 
 LINK : H:\workspace\cmakeExample\proWinDyn\lib\Debug\Hello.dll not found
 or
 not built by the last incremental link; performing full link
 
 Creating library H:\workspace\cmakeExample\proWinDyn\lib\Debug\Hello.lib
 and
 object H:\workspace\cmakeExample\proWinDyn\lib\Debug\Hello.exp
 
 LINK : H:\workspace\cmakeExample\proWinDyn\bin\Debug\helloDemo.exe not
 found
 or not built by the last incremental link; performing full link
 
I don't see a single error here - just some useless warnings.

 on the contrary, when i put it (set_target_prop) in the library directory
 i
 have the link problem of the dll in execution (but tje .lib is generated
 with a warning)

You really should not mix up ADD_DEFINITIONS() and SET_TARGET_PROPERTIES(... 
DEFINE_SYMBOL).


And plz. reply to the list.

Christian

-- 
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten 
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] shared libraries .lib

[Christian Ehrlicher]

 Von: Ingrid Kemgoum
 hi,
 i'm trying to build a c++ project and i have a dynamic library. it is
 created a .dll but MSVC ask for a .lib.
 Is there a way to produce both .dll and .lib from the library?
 
 Thanks and regards.
 
You have to do it by your own by defining the functions which you want to 
export. See also ml archive: 
http://www.cmake.org/pipermail/cmake/2008-June/022105.html


Christian
-- 
GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
Jetzt dabei sein: http://www.shortview.de/[EMAIL PROTECTED]
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Import library not generated under Visual Studio

[Christian Ehrlicher]

 Von: Martin Apel
 Hi all,
 
 I am trying to port a project using CMake 2.6 from Linux to Windows. The 
 project build works without problems under Linux. However when trying to 
 build the project inside Visual Studio 8 after having generated the 
 project files using CMake, no import libraries are generated.
 The library build step is specified by using
   ADD_LIBRARY(Base SHARED EXCLUDE_FROM_ALL ${LocalSrc})
 which I would expect to generate rules to create the DLL AND the 
 corresponding import library. The DLL is built, but the import library 
 is missing. Looking at the build log file in Visual Studio, there is no 
 call to lib.exe, which I would expect.
 I am not a Windows specialist, so I may be missing something simple 
 completely.
 
 Any help would be appreciated.
 
cmake itself does not do anything to create an import lib. This is all done by 
the linker. If it finds symbols which are exported, it automatically creates 
the import lib.
So it looks like you don't export any symbols.


Christian

-- 
GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
Jetzt dabei sein: http://www.shortview.de/[EMAIL PROTECTED]
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] [PATCH] FindQt4.cmake qt4_automoc improvements

[Christian Ehrlicher]

Alexander Neundorf schrieb:

On Thursday 29 May 2008, Christian Ehrlicher wrote:

Tanguy Krotoff schrieb:

On Thu, May 29, 2008 at 8:48 PM,  [EMAIL PROTECTED] wrote:
The bug that I got with QT_DEBUG/QT_NO_DEBUG not being defined is a
pretty hard one.
I simply would like other devs not to spend time on such stupid
issues, so how can this be prevented?

We hit this problem some time ago and fixed it locally.
FindQt4.cmake from kdelibs has a fix for this - I thought alex already
merged this back to FindQt4 from cmake.


I try to merge partly from time to time, but the differences have become quite 
big, also because the one from cmake must be more general than the one from 
KDE (for KDE it's ok if FindQt4.cmake just supports the Qt versions we 
require, i.e. currently = 4.3.0)

So there are some things which will stay different.


np, but the ndebug thing should be easy to merge, or?


Christian
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] [PATCH] FindQt4.cmake qt4_automoc improvements

[Christian Ehrlicher]

Tanguy Krotoff schrieb:

On Thu, May 29, 2008 at 8:48 PM,  [EMAIL PROTECTED] wrote:
The bug that I got with QT_DEBUG/QT_NO_DEBUG not being defined is a
pretty hard one.
I simply would like other devs not to spend time on such stupid
issues, so how can this be prevented?


We hit this problem some time ago and fixed it locally.
FindQt4.cmake from kdelibs has a fix for this - I thought alex already 
merged this back to FindQt4 from cmake.




Christian



signature.asc
Description: OpenPGP digital signature
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] cmake (no longer?) complains about missing files

[Christian Ehrlicher]

Hi,

I don't know if it's the intended behaviour or not:


I create a file on build time with add_custom_command.
ADD_CUSTOM_COMMAND(OUTPUT ${CMAKE_BINARY_DIR}/my_source.cpp
   COMMAND makeMySource ARGS ${CMAKE_BINARY_DIR}/my_source.cpp 
)

and add it to an executable:

add_executable(myExecutable ${CMAKE_BINARY_DIR}/my_source.cpp)


cmake does not complain when the file does not exist. For instance when I 
forgot the add_custom_command() or misspelled the filename. Instead I get an 
error from make.
I know there was a change from 2.6.0rc9 to 2.6.0final which fixed an error when 
a file was created on build-time but the add_custom_command() wasn't already 
defined.
I also don't know what 2.4 did in such a case.


Is this the correct behaviour?
Christian

-- 
Pt! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake questions

[Christian Ehrlicher]

 Von: dizzy
 On Thursday 22 May 2008 12:03:01 Oleg Puchinin wrote:
  Hello !
 
snip
  2. How to build target with debug info ?
 
 There are several solutions here. A not very portable aproach is to add 
 whatever compiler flags you wish to the compile command used, using
 cmake's 
 SET_TARGET_PROPERTIES and setting the COMPILE_FLAGS property (see the man 
 page again, this time on SET_TARGET_PROPERTIES).
 
Why not simply setting CMAKE_BUILD_TYPE to Debug ??


Christian
-- 
Desperate Housewives - das Spiel!
Pikante Skandale, schockierende Details unter: http://flat.games.gmx.de
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake and MinGW on Windows

[Christian Ehrlicher]

 Von: Shriramana Sharma
 Hello.
 
 I would like to use CMake to build some CMake-ready Qt-based
 applications on Windows using MinGW.
 
 I get an error saying Make was not found. I used
 -DCMAKE_MAKE_PROGRAM=path to mingw. But then I got an error saying
 C compiler could not compile the test program.
 
 I tried on the CMake wiki but both the MinGW-related pages I found:
 
 http://www.cmake.org/Wiki/CMake_MinGW_Compiler_Issues
 http://www.cmake.org/Wiki/CmakeMingw
 
 did not solve my problem. Please can anyone give clear instructions as
 to how to use CMake with MinGW, especially for compiling Qt programs
 on Windows?
 
 Thanks in advance.
 
There are no special things to do. Looks like your PATH environment variable is 
missing the path to 'bin' directory from MinGW. Otherwise mingw32-make and gcc 
would be found by cmake without any additional parameters.


Christian
-- 
Pt! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] cmake 2.6 and find_library with MinGW generator

[Christian Ehrlicher]

 Von: Hendrik Sattler
 Christian Ehrlicher schrieb:
  during your new warning when mixing libs in target_link_libraries 
  (CMP0003) I changed target_link_libraries(foo ws2_32) to
 
  find_library(WS2_32_LIBRARY ws2_32)
  target_link_libraries(foo ${WS2_32_LIBRARY})
 
  but now cmake finds ws2_32.dll in system32 instead the correct one 
  (ws2_32.dll.a / ws2_32.a) in mingw dir.
 Set the LIB environment variable to the MinGW lib dir. While you are at 
 it, do the same for INCLUDE.
 This is comparable to the setup for cl.
 
Also they solution is clear I don't like it. MinGW doesn't care about LIB 
(otherwise it wouldn't link against ws2_32.a) so why should cmake do in this 
case?
The problem is the new warning - it suggest that a simple find_library would do 
the job but it doesn't - it breaks compilation. Looks like this warning is the 
first one which I'll disable by default. Maybe also in kde4/win because it's 
imho useless when linking against system libs (on windows).

Christian
-- 
GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
Jetzt dabei sein: http://www.shortview.de/[EMAIL PROTECTED]
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] cmake 2.6 and find_library with MinGW generator

[Christian Ehrlicher]

 Von: Hendrik Sattler
 Christian Ehrlicher schrieb:
  Von: Hendrik Sattler
  Christian Ehrlicher schrieb:
  
  during your new warning when mixing libs in target_link_libraries 
  (CMP0003) I changed target_link_libraries(foo ws2_32) to
 
  find_library(WS2_32_LIBRARY ws2_32)
  target_link_libraries(foo ${WS2_32_LIBRARY})
 
  but now cmake finds ws2_32.dll in system32 instead the correct one 
  (ws2_32.dll.a / ws2_32.a) in mingw dir.

  Set the LIB environment variable to the MinGW lib dir. While you are at
  it, do the same for INCLUDE.
  This is comparable to the setup for cl.
 
  
  Also they solution is clear I don't like it. MinGW doesn't care about
 LIB (otherwise it wouldn't link against ws2_32.a) so why should cmake do in
 this case?
  The problem is the new warning - it suggest that a simple find_library
 would do the job but it doesn't - it breaks compilation. Looks like this
 warning is the first one which I'll disable by default. Maybe also in kde4/win
 because it's imho useless when linking against system libs (on windows).

 Did find_library in CMake 2.4 find he correct one?
Don't know but don't think so - I completly switched to 2.6 a while ago.

 I also think that this could be improved: for MinGW Makefiles 
 generator, cmake could get the base MinGW directory and add
 the lib/ and include/ subdirs to the front of default paths. Then, 
 find_library() would magically work again.
 Do you want to create a bug tracker entry for that issue?
I will - just wanted to discuss it here to see if you maybe can convince me 
that's the correct behaviour for mingw :)

Christian
-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] cmake 2.6 and find_library with MinGW generator

[Christian Ehrlicher]

 Von: Bill Hoffman
 Christian Ehrlicher wrote:
  Hi,
  
  during your new warning when mixing libs in target_link_libraries 
  (CMP0003) I changed target_link_libraries(foo ws2_32) to
  
  find_library(WS2_32_LIBRARY ws2_32)
  target_link_libraries(foo ${WS2_32_LIBRARY})
  
  but now cmake finds ws2_32.dll in system32 instead the correct one 
  (ws2_32.dll.a / ws2_32.a) in mingw dir.
  
 
 
 A!!!
 
 This is the most misunderstood warning of all times  :)
 
 
 You do not have to use full paths for all libraries now.
 You do not have to use full paths for all libraries now.
 
 For system libraries like this one it is much safer to just list them. 
 If you set the policy to NEW, it will just work with no warnings. The 
 warning says that it maybe a problem, but to try it as NEW, and if it is 
 not a problem, then you are good.
 
 For this case I would recommend changing ws2_32 to not being found.  It 
 is a standard library that the compiler should be able to find the 
 appropriate version of.
 
I understood the warning - I know that it is not mandatory. But how useful is a 
warning when the only way to get rid of them is to disable it? I either have to 
fix all places (including the system libs) or disable it and don't care at all. 
That's stupid.


Christian

-- 
Desperate Housewives - das Spiel!
Pikante Skandale, schockierende Details unter: http://flat.games.gmx.de
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] cmake 2.6 and find_library with MinGW generator

[Christian Ehrlicher]

Bill Hoffman schrieb:

Christian Ehrlicher wrote:



I understood the warning - I know that it is not mandatory. 

  But how useful is a warning when the only way to get rid of them is
 

to disable it? I either have to fix all places (including the system libs

 ) or disable it and don't care at all. That's stupid.




OK, so you don't understand the warning.  Not your fault it is just hard 
to write as many others do not understand it.


Here is the problem:

We changed from -L/path/to -lA  to /path/to/library.  In some rare cases 
projects have something like this:


target_link_libraries(foo /path/to/libA.a B)

And B is actually in /path/to/libB.a

We have no easy way of telling the difference between the above and

target_link_libraries(foo /path/to/libA.a somesystemlib)

Where somesystemlib library can be found by the compiler.

So, we had two choices for 2.6:

1. Always add -L/path if there is at least one non-full path library 
linked in.  This makes extra long link lines.


2. Do not add -L/path and give no warning - we will break some projects 
with no warning, and the break will happen with a linker error during 
the build step.


So, what we did was do 1 by default, but give a warning.

So, to make a long story short, setting the policy to NEW is not 
disabling the warning, it is asking CMake to link libraries in the new 
better 2.6 way.  So, the correct fix is to set the policy to NEW, and if 
your stuff links then the warning was in error. If a project has 2.6 as 
the minimum require version there is no warning and things are always 
linked full path.



Thx for the explanation.


Christian



signature.asc
Description: OpenPGP digital signature
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] cmake 2.6 and find_library with MinGW generator

[Christian Ehrlicher]

Hi,

during your new warning when mixing libs in target_link_libraries 
(CMP0003) I changed target_link_libraries(foo ws2_32) to


find_library(WS2_32_LIBRARY ws2_32)
target_link_libraries(foo ${WS2_32_LIBRARY})

but now cmake finds ws2_32.dll in system32 instead the correct one 
(ws2_32.dll.a / ws2_32.a) in mingw dir.




Christian



signature.asc
Description: OpenPGP digital signature
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] cmake 2.6.0, breakages

[Christian Ehrlicher]

 Von: Andreas Pakulat
 On 19.05.08 02:06:51, Dmitry Marakasov wrote:
  * Andreas Pakulat ([EMAIL PROTECTED]) wrote:
  
snip
CMakeFiles/Memonix.dir/CMakeFiles/CompilerIdCXX/CMakeCXXCompilerId.o
gets into project object files (seems like it's because
CMakeFiles/CompilerIdCXX/CMakeCXXCompilerId.cpp gets into
 GLOB_RECURSE.
That's obviously undesired.
   Right, then don't use GLOB_RECURSE when you use srcdir == builddir. In
   fact, don't use srcdir == builddir unless you have good reasons. Apart
   from that you could as well just list all the files in the project in
 a
   variable, instead of using GLOB.
  Agreed. But I still see it as a bug that cmake uses srcdir ==
  builddir AND includes it's own files into glob when doing GLOB.
 
 If you think so, you should open a bugreport. 
 
And don't forget to open a bugreport for unix 'find' too. It also finds its own 
sources when doing a 'find /path/to/find/sources -name *.c ' ...


Christian
-- 
249 Spiele für nur 1 Preis. Die GMX Spieleflatrate schon ab 9,90 Euro.
Neu: Asterix bei den Olympischen Spielen: http://flat.games.gmx.de
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] MinGW and cmake issues...

[Christian Ehrlicher]

Phil Pellouchoud schrieb:

I have been trying to get cmake to work with MinGW.

 


I have trolled around the net and looked for clues and tried a bunch of
things without success.  Here are the particulars:


snip
 


Any ideas?

Did you try to compile a simple hello world from command line? Does it 
work? I don't think so.


What os do you use? What gcc? If you're using vista you need a patch (or 
recent mingw 3.4.5 from sf.net/projects/mingw)



Christian



signature.asc
Description: OpenPGP digital signature
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] MinGW and cmake issues...

[Christian Ehrlicher]

Phil Pellouchoud schrieb:

I did try to compile a simple hello world program, and I can do it on
the command line:
gcc -o test test.cpp

Builds and runs fine.

I am using Windows XP SP2

GCC version is this:
S:\software\packages\utility\buildgcc -v
Using built-in specs.
Target: i386-pc-mingw32
Configured with: ../gcc-4.3.0/configure --prefix=/mingw --disable-nls
--enable-languages=c,c++,fortran,objc,obj-c++,ada,
java --disable-win32-registry --disable-sjlj-exceptions
--enable-libstdcxx-debug --enable-version-specific-runtime-libs
--with-gmp=/mingw/src/gcc/gmp-mpfr-root
--with-mpfr=/mingw/src/gcc/gmp-mpfr-root --enable-libgcj
--enable-concept-checks
 --enable-shared
Thread model: win32
gcc version 4.3.0 (GCC)

S:\software\packages\utility\build

I am using mingw version 5.1.4

See CMakeError.log and CMakeOutput.log what's going wrong. They're in 
your build dir in CMakeFiles subdir.



Christian



signature.asc
Description: OpenPGP digital signature
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] DEFINE_SYMBOL and static libs

[Christian Ehrlicher]

Hi,

is there a rationale behind the fact that DEFINE_SYMBOL for static libs 
is ignored? I do understand that (the automatic) MAKE_foo_LIB is not 
needed here but I don't see a reason why to ignore a user-defined value.


The problem is that I want to compile a lib in static and shared mode 
and it doesn't work because I can't define BUILD_STATIC when compiling 
the static lib and therefore get compiler errors :(




Christian



signature.asc
Description: OpenPGP digital signature
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Strange behaviour of FindCurses.cmake (and cmake 2.6.0?)

[Christian Ehrlicher]

Hi,

when curses is searched twice, the second search fails:

-8
message(STATUS CURSES_HAVE_CURSES_H: ${CURSES_HAVE_CURSES_H})
message(STATUS CURSES_INCLUDE_PATH:  ${CURSES_INCLUDE_PATH})
FIND_PACKAGE(Curses REQUIRED)
message(STATUS CURSES_HAVE_CURSES_H: ${CURSES_HAVE_CURSES_H})
message(STATUS CURSES_INCLUDE_PATH:  ${CURSES_INCLUDE_PATH})
FIND_PACKAGE(Curses REQUIRED)
message(STATUS CURSES_HAVE_CURSES_H: ${CURSES_HAVE_CURSES_H})
message(STATUS CURSES_INCLUDE_PATH:  ${CURSES_INCLUDE_PATH})
-8

gives this output:

-8
-- CURSES_HAVE_CURSES_H:
-- CURSES_INCLUDE_PATH:
-- Found Curses: /usr/lib64/libncurses.so
-- CURSES_HAVE_CURSES_H: /usr/include/curses.h
-- CURSES_INCLUDE_PATH:  /usr/include
CMake Error at /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:52 
(MESSAGE):
  Could NOT find Curses
Call Stack (most recent call first):
  /usr/share/cmake/Modules/FindCurses.cmake:104 
(FIND_PACKAGE_HANDLE_STANDARD_ARGS)
  CMakeLists.txt:8 (FIND_PACKAGE)
-8

Any ideas what's going wrong here? I think it worked fine with 2.4.8 but can't 
test it atm.



Christian 
-- 
GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
Jetzt dabei sein: http://www.shortview.de/[EMAIL PROTECTED]
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Embed an icon into a program

[Christian Ehrlicher]

 Von: Steven Van Ingelgem
 Hi,
 
 
 To embed an icon into a program on Windows with VS, you just add it to
 the source files. This approach however doesn't seem to work with
 MinGW makefiles (on windows too).
 
 Is there anyway I can make this work?
 
 I know there is a tool windres which supposedly takes a .rc file and
 converts it into some precompiled format? Though I would prefer that
 CMake handles it from it's own of course :)
 
 
There's already a feature request in the bugtracker but I can't find it atm. 
But you'll need windres for it anyway.


Christian
-- 
249 Spiele für nur 1 Preis. Die GMX Spieleflatrate schon ab 9,90 Euro.
Neu: Asterix bei den Olympischen Spielen: http://flat.games.gmx.de
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] VS8.0 CompileAs

[Christian Ehrlicher]

 Von: Philippe Fremy
 
   Hi,
 
 For one of my project, I need to compile files with .c extension as C++ 
 files. It's an uncommon need but it exists.
 
 In Visual Sturio, there is a compiler option, /TP that does exactly 
 this. In Visual Studio  2005 project files, it seems to translate into 
 CompileAs property which can be set to 1 (compile as C), 2 (compile as 
 C++) or 3 (compile as the project defines it).
 
 I am using CMake 2.4.8
 
snip

Looking in the cmake documentation for SET_SOURCE_FILES_PROPERTIES and LANGUAGE 
should help.


Christian
-- 
GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
Jetzt dabei sein: http://www.shortview.de/[EMAIL PROTECTED]
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] add_executable and WIN32 option

[Christian Ehrlicher]

 Von: Alin M Elena
 Hi
 
  
 
 I try to use WIN32 option with cmake 2.6 rc6
 
  
 
snip 
 MSVCRT.lib(crtexew.obj) : error LNK2019: unresolved external symbol
 [EMAIL PROTECTED] referenced in function ___tmainCRTStartu
 
 p
 
Read the wiki faq:
http://www.cmake.org/Wiki/CMake_FAQ#Why_am_I_getting_a_linker_error_to__mainCRTStartup_under_WIN32.3F


HTH
Christian
-- 
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten 
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Question about MSVC link-process

[Christian Ehrlicher]

 Von: Ilya Shvetsov
  Are libA.lib targets built by cmake in the same solution?
 No. This is library from extranal engine.
 
The first thing which is obviously wrong is that you write 'foo.lib' instead of 
'foo'. It pins the whole thing to msvc and I'm really gald that it works :)

Also you should not link directly to foo (when it's an external lib) - use 
FIND_LIBRARY(FOO_LIB foo) and then link to ${FOO_LIB} 
(TARGET_LINK_LIBRARIES(Example ${FOO_LIB}). This should enable dependency 
checking afaik.


HTH
Christian
-- 
Psst! Geheimtipp: Online Games kostenlos spielen bei den GMX Free Games! 
http://games.entertainment.gmx.net/de/entertainment/games/free
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] FindQT.cmake on windows

[Christian Ehrlicher]

 Von: Mike Arthur
 On Wednesday 09 April 2008 10:37:39 Andreas Pakulat wrote:
  Thats because qmake is in the PATH on unix usually, I think it works
  autoamtically on windows too if the Qt/bin path is listed in the PATH
  environment variable.
 Is there any reason FindQT couldn't just look (by default) in the default
 Qt 
 Windows install location?
 
What's 'the default install location' on windows?
I've four installations here on my system - and I would blame cmake if it's not 
using the on I need. The only way to do this is by looking for qmake in PATH.


Christian
-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake 2.6.0 RC 6 ready for testing

[Christian Ehrlicher]

 Von: Mathieu Malaterre
 On Wed, Apr 2, 2008 at 8:13 PM, Bill Hoffman
 wrote:
  I am happy to announce that CMake 2.6.0 RC6 is ready for testing.
   You can find the source and binaries here:
  http://www.cmake.org/files/v2.6/.
 
   Here is the list of changes for the 2.6.0 branch so far:
 
   Changes in CMake 2.6.0 RC 6
 
   - Added ChangeLog.manual
   - Allow CMakeImportBuildSettings force compiler to be optional
   - Change cpack deb packager to detect the architecture
   - Fix FindCurses to be backwards compatible with cache variable
  CURSES_LIBRARY
   - Add version variables to FindQt4.cmake
   - Fix CPack Deb generator to not hard code /usr
   - Better default size for cmake-gui help dialog
   - Fix problem where incorrect path was used for cmake.exe when
used to do incremental linking on windows nmake or make
   - Fix build with system libraries on
   - Add color output in kdevelop
   - Create non-verbose makefiles in kdevelop
   - Fix some missing flags for vs IDE flag map
   - Fix MacOSX install symlink crash problem
   - Fix turning of Dev warnings with gui's
   - Fix backwards compatibility issue with FindMPI.cmake
   - Fix for bug 6605, add -L path for optimized in debug sometimes for
backwards compatibility
   - Allow for CMP to be set before any warnings happen
   - Do not use FAT32 hack in VS 2005 and 2008 unless on a FAT32 disk,
causes try-compiles to be 3 times slower if FAT hack is present.
   - Fixes to debian cpack
   - Can now check if a proprty is SET or not
   - Fix for generate with vs 2005 and vista not being able to create
 stamp
  file
   - set_property with an empty value unsets that property now
   - Fix FindQt4 on windows with some \ style paths
 - CPACK_DEBIAN_PACKAGE_CONTROL_EXTRA to add pre/post shell script to deb
 package
 
 Everything's good for me ! Thanks again.
 
For me too - I was now able to compile kdelibs (including kdesupport libs) 
with NMake Makefiles without any problems. Will test the rest of kde including 
MinGW Makefiles today and switch to 2.6 in my complete build env next week when 
all works like expected.


Thx,
Christian
-- 
GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
Jetzt dabei sein: http://www.shortview.de/[EMAIL PROTECTED]
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] an easy way to clean cmake generated files?

[Christian Ehrlicher]

 Von: Ákos Maróy
 Philip Lowman wrote:
  I've filed a feature request for this (i.e. a distclean target for 
  CMake).  It keeps coming up on the mailing list so it probably would 
  make a nice addition to CMake.  I've needed it before too when stubborn 
  coworkers really want to keep using in-source build trees but want to 
  return their source trees to a pristine state.
  
  http://public.kitware.com/Bug/view.php?id=6647
 
 thanks, I added a 'me too' comment already :)
http://www.cmake.org/Wiki/CMake_FAQ#CMake_does_not_generate_a_.22make_distclean.22_target._Why.3F

So I doubt such a target could be added without someone crying why his 
generated file did not get cleaned up...

Christian
-- 
Pt! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] How to make Visual Studio .vcproj with relative paths

[Christian Ehrlicher]

 Von: Olaf van der Spek
 On Tue, Mar 25, 2008 at 12:58 AM, Alexander Neundorf
 [EMAIL PROTECTED] wrote:
   Not really.
   Why do you actually want to ship VS project files ?
 
 To avoid a dependency on cmake. The library user probably doesn't have
 cmake installed and it would be nice if he could directly open the
 .sln file and build the library.
 
You've the dependency on VisualStudio (and maybe other external libs) but are 
afraid of the cmake dependency?
Throw away the idea of shipping indivudal .vcproj files. Today I had to install 
three external libs and every one had a whole bunch of Makefiles (cygwin, gnu, 
osx, sun, ...) and .vcproj - Files (vs6, vs7, vs8 - I wonder if they don't 
support vs9 ;) ). This looks very professional and I won't think about the 
administration effort to keep all of them up-to-date. 
Oh, and because they don't support out-of-source builds they also shipped a 
clean.bat file to clean up all the files created by vs...

A single CMakeLists.txt would make all the above superflous.


Nobody forces you to use CMake - just write and maintain your .vcproj by your 
own ;)


Christian
-- 
Psst! Geheimtipp: Online Games kostenlos spielen bei den GMX Free Games! 
http://games.entertainment.gmx.net/de/entertainment/games/free
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Install Problem.

[Christian Ehrlicher]

 Von: Surya Kiran Gullapalli
 Hi all,
 I'm trying to install a shared library using INSTALL Method on win32
 platform. (Visual Studio 2005)
 
 But what i found was only the dll is getting installed. the import
 library .lib is not getting installed.
 
 I've specified the RUNTIME and LIBRARY options for Install method.
 I've browsed thru the documents but found nothing.
 
 How do i install a import library also for a dll on windows.
 
An import lib is treated as archive in cmake. So oyu have to specify ARCHIVE.


Christian
-- 
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten 
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] [cmake 2.5] Double linking?

[Christian Ehrlicher]

 Von: Bill Hoffman
 Christian Ehrlicher wrote:
  Hi,
  
  When linking a lib with cmake 2.5cvs it looks like the lib is linked
 twice:
  
  --8---
  Linking CXX shared library ..\bin\kdeui.dll
 Bibliothek ..\bin\kdeui.lib und Objekt ..\bin\kdeui.exp werden
  erstellt.
 Bibliothek ..\bin\kdeui.lib und Objekt ..\bin\kdeui.exp werden
  erstellt.
  --8---
  
  
  Any ideas?
  
 Yes, this is my doing.  This is the crazy manifest stuff that you have 
 to do.   Prior to about a week ago incremental linking did not work at 
 all with nmake/make and visual studio 8 and greater.  This is because we 
 embed the manifest with the mt tool.  This invalidates the file for 
 incremental linking. The trick is to embed the manifest into a resource 
 that is incrementally linked into the exe/dll.  So, the second link is 
 an incremental one, and the only thing that should change is the 
 manifest resource, so it should be quick.  For more information on this, 
 see this page:
 http://blogs.msdn.com/zakramer/archive/2006/05/22/603558.aspx
 
 BTW, it should only do the double link the first time, unless the 
 manifest changes.
 
Thx, this also explains the linker warning about non-incremental linking with 
cmake 2.4 :)

Christian
-- 
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] [cmake 2.5] Double linking?

[Christian Ehrlicher]

Hi,

When linking a lib with cmake 2.5cvs it looks like the lib is linked twice:

--8---
Linking CXX shared library ..\bin\kdeui.dll
   Bibliothek ..\bin\kdeui.lib und Objekt ..\bin\kdeui.exp werden
erstellt.
   Bibliothek ..\bin\kdeui.lib und Objekt ..\bin\kdeui.exp werden
erstellt.
--8---


Any ideas?

Thx,
Christian



signature.asc
Description: OpenPGP digital signature
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: RE: [CMake] Compilation speed with CMake/NMake combination, making it faster?

[Christian Ehrlicher]

 Von: Josef Karthauser [EMAIL PROTECTED]
  -Original Message-
  From: Torsten Martinsen [mailto:[EMAIL PROTECTED]
  Sent: 11 December 2007 09:08
  To: Josef Karthauser; CMake ML
  Subject: RE: [CMake] Compilation speed with CMake/NMake combination,
  making it faster?
  
   * We're using an NMake build tree, is NMake particularly
   slow?  Do any of the other makes work more efficiently?
  
  Be aware that nmake builds are much slower than using devenv, as nmake
  starts a cl.exe process for every single file,
  whereas devenv calls cl.exe with several source files. This costs, due
  to the high process overhead on Windows.
 
 I understand that.
It's not a nmake problem but a problem of cmake. cmake does not support batched 
build - already opened a bug long time ago because of this.


Christian

-- 
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten 
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Specifying different flags for debug/release mode

[Christian Ehrlicher]

Hi,

ist there something like target_link_libraries(debug fooD.lib release foo.lib) 
possible for flags?
It's needed to make Qt plugins work (yes, you can't properly build Qt plugins 
on windows with cmake).


Christian

-- 
Pt! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Specifying different flags for debug/release mode

[Christian Ehrlicher]

 Von: Pau Garcia i Quiles
 Quoting Christian Ehrlicher
 
  Hi,
 
  ist there something like target_link_libraries(debug fooD.lib   
  release foo.lib) possible for flags?
  It's needed to make Qt plugins work (yes, you can't properly build   
  Qt plugins on windows with cmake).
 
  From http://www.cmake.org/Wiki/CMake_Useful_Variables
 
 CMAKE_BUILD_TYPE
   Choose the type of build. CMake has default flags for these:
 None (CMAKE_C_FLAGS or CMAKE_CXX_FLAGS used)
 Debug (CMAKE_C_FLAGS_DEBUG or CMAKE_CXX_FLAGS_DEBUG)
 Release (CMAKE_C_FLAGS_RELEASE or CMAKE_CXX_FLAGS_RELEASE)
 RelWithDebInfo (CMAKE_C_FLAGS_RELWITHDEBINFO or
 CMAKE_CXX_FLAGS_RELWITHDEBINFO

This does not help much/ I'm currently using this hack.
The problem is that it's not permanent. And the other one is that imho 
FindQt4.cmake should handle this.
See
http://websvn.kde.org/trunk/KDE/kdelibs/cmake/modules/FindKDE4Internal.cmake?r1=733507r2=734116
http://www.cmake.org/pipermail/cmake/2007-November/017541.html

Therefore I'm looking for an easier solution to solve this.

Christian


-- 
Pt! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Win32: exporting symbols for DLLs - simpler method ?

[Christian Ehrlicher]

Eric Noulard schrieb:
 2007/11/23, Christian Ehrlicher [EMAIL PROTECTED]:
 Eric Noulard schrieb:
 2) is possible if you use .def file instead of 
 __declspec(dllexport/dllimport)
 see e.g.
 http://www.codeproject.com/dll/SimpleDllP3.asp

 This is the old way to export functions and imho very error-prone (you
 have to change your function name on two places for proper export).
 
 Yes that's right.
 
 Also this does not work for linux.
 
 I'm no shared lib specialist but as far as I know when
 you build a shared lib on linux the default behavior
 is to export all symbols?
 
 As far as understood from
  How to Write Shared Libraries
 http://people.redhat.com/drepper/dsohowto.pdf
 
Since gcc 4.x has support for __attribute__ ((visibility()). The effect
of this atribute is nearly the same like dllexport on windows - hiding
private symbols to speedup shared lib loading. kde4 is using this (maybe
more an effect because we need it on windows than really using it to
speedup shared lib loading, don't know ;) )
 You'll need a single #define FOO_EXPORT for every lib you create.
 
 Yes I agree with that if you do not use .def.
 
 I'm interested in your problem too because I personnally
 would like to throw away those LIB_EXPORTS prefix from the source.
 I don't understand this.
 
 I wanted to say that I don't like to have all those
 WHATEVER_EXPORTS in my header files.
 I think it makes the header less readable.
The only thing you need is a FOO_EXPORT before every class / function.
When you move out the import/export stuff into an own header (like it's
done in kde4) it's not that unreadable :)


Christian



___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] DLL import/export flag differentiation

[Christian Ehrlicher]

Nicholas Yue schrieb:
 Hi,
 
   I am attempting to migrate the ANN build to CMake for my own ease of
 cross platform maintenance.
 
   The cmake configuration works fine on OSX but have problem Windows
 because of the additional linkage requirement.
 
   I understand that there is no per target DEFINITIONS setup so I'd like
 to hear advice from experience cmake user how I should configure my build.
 
   The library needs the -DDLL_EXPORT while the application must not have
 that set so that it imports the exported symbols.
 
   At the moment, my build fails at the ann_test target because it
 inherits the -DDLL_EXPORT flag from the top.
 
You can you set_target_properties for this. E.g.:
set_target_properties(kdewin32 PROPERTIES DEFINE_SYMBOL MAKE_KDEWIN32_LIB )


HTH
Christian Ehrlicher
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Win32: exporting symbols for DLLs - simpler method ?

[Christian Ehrlicher]

Eric Noulard schrieb:
 2007/11/23, Stephen Collyer [EMAIL PROTECTED]:
 Cmake seems to define, for each library that is built, a symbol
 of the form library_EXPORTS, which can be used to set up
 #defines for the __declspec(dllexport/dllimport) stuff that
 Windows needs.

 However, this means that each library needs a specific symbol
 to allow it to be built with the correct import/export spec e.g.


 class LIB1_EXPORTS Lib1 {
 ...
 }

 class LIB2_EXPORTS Lib2 {
 ...
 }

 and so on. What I'd like to do is to have a single #define
 (LIB_EXPORTS or something) that is set appropriately somehow.
 
 What do you mean?
 1) You want a single LIB_EXPORTS for all libs such that you may write:
 
 class LIB_EXPORTS Lib1 {
  ...
 }
 
 class LIB_EXPORTS Lib2 {
 ...
 }
 
 2) or do you want to have
 
 class Lib1 {
  ...
 }
 but still have symbol exported?
 
 I think 1) is possible if all classes are in the same lib, but
 may be this is obvious. In other cases if LIb1 is using LIb2
 the two libs cannot share the LIB_EXPORTS var because
 the using lib need dllimport while the other need dllexport?
 
 2) is possible if you use .def file instead of __declspec(dllexport/dllimport)
 see e.g.
 http://www.codeproject.com/dll/SimpleDllP3.asp
 
This is the old way to export functions and imho very error-prone (you
have to change your function name on two places for proper export). Also
this does not work for linux.
You'll need a single #define FOO_EXPORT for every lib you create.

 Is this possible ? I don't see how at the moment, but the
 method I'm using at the moment is rather tedious and I'd like
 to simplify it, if possible.
 
 I'm interested in your problem too because I personnally
 would like to throw away those LIB_EXPORTS prefix from the source.
I don't understand this.


Christian



signature.asc
Description: OpenPGP digital signature
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Add search paths for FIND_PACKAGE ?

[Christian Ehrlicher]

Mike Jackson schrieb:
 Actually I run into this ALL the time (tiff, expat, hdf5) and I have
 most of mine stored in non-Standard locations. I end up copying the
 the FindXXX.cmake into my local project directory and then adding some
 code like the following:
 
 SET(EXPAT_INCLUDE_SEARCH_DIRS
   $ENV{EXPAT_INSTALL}/include/expat
 )
 
 SET (EXPAT_LIB_SEARCH_DIRS
   $ENV{EXPAT_INSTALL}/lib
   )
 
 FIND_PATH(EXPAT_INCLUDE_DIR 
   NAMES expat.h
   PATHS ${EXPAT_INCLUDE_SEARCH_DIRS} 
   NO_DEFAULT_PATH
   )
 
 The important part is that I am looking for an environment variable to
 help find the paths/libraries. This type of thing could be added the the
 FindXXX.cmake files so if someone has their libs installed in
 non-standard locations they can set an env variable and let cmake find
 the package that way.
 
 
 Also.. Why would I hard-code paths into a cross-platform build
 system.. that is just asking for trouble. If Stephen has one of his
 associates build his source for him then that associates computer must
 be laid out the EXACT same way which is not going to happed.
 
Search for CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH


Christian
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] setting configuration specific options in visual studio

[Christian Ehrlicher]

 Von: Salvatore Iovene
 CC: cmake@cmake.org
 Betreff: Re: [CMake] setting configuration specific options in visual studio
 On Nov 20, 2007 1:38 AM, Jesse Corrington [EMAIL PROTECTED]
 wrote:
  I searched the archives and couldn't find any good information about
 this
  task, which I would assume is important to many people. I need to set
  options in visual studio that are different in debug and release modes.
 For
  example I need to set preprocessor defines, change compiler flags, link
 with
  different libraries, and other settings.
 
  Is there anyway to do something like this.
 
  IF ( RELEASE )
  ADD_DEFINITIONS( -DREL1 )
  ELSEIF ( DEBUG )
  ADD_DEFINITIONS( -DDEB1 )
  ENDIF ()
 
 Look at the CMAKE_BUILD_TYPE variable in
 http://www.cmake.org/Wiki/CMake_Useful_Variables
 Basically you can have variables like CMAKE_CXX_FLAGS_DEBUG,
 CMAKE_CXX_FLAGS_RELEASE, CMAKE_CXX_FLAGS_WHATEVER, and the correct
 variable is chosen by cmake according to the value of CMAKE_BUILD_TYPE
 (e.g. DEBUG, RELEASE or WHATEVER.
 
This does not apply to the VisualStudio vcproj generator.
Linking with different libraries can be achieved by using 'debug' and 'release' 
keyword in you lib definition. See FindQt4.cmake:

SET(QT_${basename}_LIBRARY   optimized ${QT_${basename}_LIBRARY_RELEASE} 
debug ${QT_${basename}_LIBRARY_DEBUG})


HTH
Christian
-- 
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: Fwd: [CMake] Generating static and shared libs

[Christian Ehrlicher]

Alexander Camek schrieb:
 Hi,
 
 I am using here MinGW C and C++ source code to build some libraries.

 Now what me wonders is that I am getting sometimes static libraries
 additional to my dynamic libraries.

 I think you are talking about the import library

 http://www.mingw.org/MinGWiki/index.php/sample%20DLL
 
 Nope, I don't talk about that.
 
 I am talking about the problem, that when I use ADD_LIBRARY(libname
 SHARED ${SOURCE}) and I let all my files create in a common directory
 setted with LIBRARY_OUTPUT_PATH, then sometimes both are created.
 
 So as an example I find there both kind of files.
 I have got there a libname.dll and a libname.dll.a.
 
 If this is a desired result, then why both the .dll and .dll.a are not
 generated.
 
.dll.a is not a static lib in the way you know it. It's a static import
lib. See below.
 
 I don't know MinGW well but I think its different from static libs.

 Although I always build shared libraries.

 What is the strategy when to build only the dynamic libraries and when
 to build both?

 I think you'll find answers in MinGW docs and not in CMake
 
 I think this is a CMake problem ;).
 
No, you *really* should read on www.mingw.org and inform you about
import libs.


Christian
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: Fwd: [CMake] Generating static and shared libs

[Christian Ehrlicher]

Alexander Camek schrieb:
 Hi,
 
 No, you *really* should read on www.mingw.org and inform you about
 import libs.
 
 I will do that, thanks.
 thought that i had understand them :(
 
I already told you all you have to know
Windows needs 'static import libs' to link against a shared lib. Nothing
more :)


Christian
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Problem with Qt4 and release mode on windows

[Christian Ehrlicher]

[EMAIL PROTECTED] schrieb:
 when I compile a qt plugin in release mode (and therefore link against
 release qt lib) I've the problem that cmake does not set -DQT_NO_DEBUG .
 
 
 In any file you use the Q_EXPORT_PLUGIN2 macro, you can put something like 
 this:
 #if defined(NDEBUG)
 # define QT_NO_DEBUG
 #endif
 at the top of the file.
 
But this is more a hack than a solution - don't think the kde devs will
accept this.
 I don't see a way to do something like
 ADD_DEFINTIONS(-DQT_NO_DEBUG)
 for a release configuration only.
 
I now set the cxx_flags_BUILD_TYPE directly to solve it for now. But
imho there should be something in FindQt4.cmake to adress this issue.


Christian




signature.asc
Description: OpenPGP digital signature
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Problem with Qt4 and release mode on windows

[Christian Ehrlicher]

Hi,

when I compile a qt plugin in release mode (and therefore link against
release qt lib) I've the problem that cmake does not set -DQT_NO_DEBUG .
Because of this Qt assumes we're compiling this plugin in debug mode:

qconfig.h:
==
#if !defined(QT_NO_DEBUG)  !defined(QT_DEBUG)
#  define QT_DEBUG
#endif

which leads to the wrong Q_PLUGIN_VERIFICATION_DATA:

qplugin.h:
==
#  ifdef QT_NO_DEBUG
#define QPLUGIN_DEBUG_STR false
#  else
#define QPLUGIN_DEBUG_STR true
#  endif
#  define Q_PLUGIN_VERIFICATION_DATA \
static const char *qt_plugin_verification_data = \
  pattern=QT_PLUGIN_VERIFICATION_DATA\n \
  version=QT_VERSION_STR\n \
  debug=QPLUGIN_DEBUG_STR\n \
  buildkey=QT_BUILD_KEY\0;


-- an app does not load this plugin because the verification data does
not match.

I'm posting this to cmake and kde-buildsystem list because I don't know
who to blame here - qt because it's not recognizing the NDEBUG flag
(which seems to be a widely used flag) or cmake because it's not adding
QT_NO_DEBUG to the compiler flags.



Christian



signature.asc
Description: OpenPGP digital signature
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] win32 rc files - or any other files besides cpp/cxx

[Christian Ehrlicher]

Mark Wyszomierski schrieb:

Hi,

I'm using cmake for a large project that has some win32 gui apps in
it. In the main project folder I only include those sub projects if
compiling for WIN32. That works fine.

The win32 gui apps have a .rc file in a sub-folder named 'res'. How do
you ask CMake to include those files in the resulting vc++ project?


Just add them to your source files.


Christian



signature.asc
Description: OpenPGP digital signature
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] FIND_LIBRARY mingw

[Christian Ehrlicher]

[EMAIL PROTECTED] schrieb:


Hi Christian,


it looks like FIND_LIBRARY is using a .lib if it can't find a 
.a/.dll.a when using the mingw generator (see also

http://lists.kde.org/?l=kde-windowsm=119248363310566w=2)



Is this a intented behaviour?


Normally under windows you will need to link against a .lib.
CMake default settings is to look for .lib files, so this is a intentend 
behaviour.

So look in the file Windows.cmake in your Cmake installation path, there under 
modules\plattform.
There it is set SET(CMAKE_FIND_LIBRARY_SUFFIXES .lib)


That's not true - on windows with mingw you link against .a
And cmake also search for .a (and .dll.a) but *also* for .lib which is 
imho a bug. When I've an import lib for msvc - foo.lib and one for mingw 
- foo.a I get foo.a for mingw, but as soon as I remove foo.a I get 
foo.lib which is wrong.



Christian



signature.asc
Description: OpenPGP digital signature
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] FIND_LIBRARY mingw

[Christian Ehrlicher]

Alexander Camek schrieb:

Hi Christian


That's not true - on windows with mingw you link against .a
And cmake also search for .a (and .dll.a) but *also* for .lib which is 
imho a bug. When I've an import lib for msvc - foo.lib and one for 
mingw - foo.a I get foo.a for mingw, but as soon as I remove foo.a I 
get foo.lib which is wrong.


Not really, i can also link with a .lib under mingw.
And if you can't link with .lib file under mingw, then it would be a 
mingw bug at all, because both are endings. 
That's the point - you can't mix msvc and mingw libs. You can only mix 
them as long as you stay in plain old C mode!

 It should contain the
correct machine representation. It would iritate me if i could link 
under windows against a elf (linux libs mostly .a ended) and it will 
work correctly.


But that's not the topic here.

So if you look under your installation path, there under Modules and 
Platform. There is a file called Windows-gcc.cmake this will be used if 
you are using under Windows gcc.


There is the part:
IF(MINGW)
  SET(CMAKE_FIND_LIBRARY_PREFIXES lib )
  SET(CMAKE_FIND_LIBRARY_SUFFIXES .dll .dll.a .a .lib)
ENDIF(MINGW)

So it first looks for a dll, then for dll.a, then for .a and after that 
.lib.


So it is not a bug, it is your thinking how it should behave.

It's a bug - because I don't know if foo.lib is a static import lib for 
a plain C or C++ dll


Christian



signature.asc
Description: OpenPGP digital signature
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] FIND_LIBRARY mingw

[Christian Ehrlicher]

Alexander Camek schrieb:
 
 Not really, i can also link with a .lib under mingw.
 And if you can't link with .lib file under mingw, then it would be a
 mingw bug at all, because both are endings. 
 That's the point - you can't mix msvc and mingw libs. You can only mix
 them as long as you stay in plain old C mode!
 
 Nope look at: http://www.mingw.org/mingwfaq.shtml#faq-msvcdll
 
You can be sure that I've some knowledge about this topic... it does not
work because msvc and mingw are ABI incompatible.

Christian
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake