Re: [CMake] install( TARGETS module ...)

2011-07-02 Thread Michael Hertling
On 07/01/2011 03:32 PM, Mathieu Malaterre wrote:
> Dear all,
> 
>   I am trying to change the default behavior of cmake which installs
> MODULE to the LIBRARY destination. For example:
> 
> ...
> add_library(test MODULE test.c)
> install(TARGETS test
>   RUNTIME DESTINATION bin
>   LIBRARY DESTINATION lib
>   ARCHIVE DESTINATION lib/static
>   )
> ...
> 
>   Will install test.dll to lib, while a SHARED target would have been
> installed to bin. Is there an easy work around ? I cannot change
> MODULE to SHARED in add_library().
>   I would also like to keep installation to lib, in case of UNIX
> system (basically I want the SHARED behavior for install() but with
> MODULE).
> 
> Thanks for suggestion,

The only solution I'm aware of is a Windows-selective destination, e.g.:

ADD_LIBRARY(test MODULE ...)
IF(WIN32)
SET(MODDST bin CACHE STRING "...")
ELSE()
SET(MODDST lib CACHE STRING "...")
ENDIF()
INSTALL(TARGETS test
  RUNTIME DESTINATION bin
  LIBRARY DESTINATION ${MODDST}
  ARCHIVE DESTINATION lib/static
  ...
)

Regards,

Michael
___
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] Strange behaviour with -D option

2011-07-02 Thread Michael Hertling
On 07/01/2011 12:02 PM, pellegrini wrote:
> Hello everybody,
> 
> there is a behaviour I do not understand when using cmake with -D option.
> 
> In my project I defined a few CACHE variables. One of them is GUI to 
> specify whether or not my project should be
> built with graphical library support.
> 
> So in my main CMakeLists.txt I wrote something like:
> 
> SET(GUI FALSE CACHE BOOL "do the build in GUI mode")
> PROJECT(crysfml Fortran)
> ...
> 
> When launching cmake with:
> cmake -G "NMake Makefiles" -D CMAKE_Fortran_COMPILER=ifort -D GUI=TRUE 
> ..\..\.
> 
> I always get the following message
> 
> #
> GUI VALUE =  TRUE
> -- Configuring done
> You have changed variables that require your cache to be deleted.
> Configure will be re-run and you may have to reset some variables.
> The following variables have changed:
> CMAKE_Fortran_COMPILER= ifort
> 
> -- The Fortran compiler identification is Intel
> -- Check for working Fortran compiler: 
> C:/Intel/Compiler/11.1/054/bin/ia32/ifort.exe
> -- Check for working Fortran compiler: 
> C:/Intel/Compiler/11.1/054/bin/ia32/ifort.exe  -- works
> -- Detecting Fortran compiler ABI info
> -- Detecting Fortran compiler ABI info - done
> -- Checking whether C:/Intel/Compiler/11.1/054/bin/ia32/ifort.exe 
> supports Fortran 90
> -- Checking whether C:/Intel/Compiler/11.1/054/bin/ia32/ifort.exe 
> supports Fortran 90 -- yes
> GUI VALUE = FALSE
> -- Configuring done
> -- Generating done
> -- Build files have been written to: 
> C:/Datas/Eclipse/workspace/crysfml/build/ifort_release_win
> #
> 
> and the worse it that when deleting the cache and rebuilding it, the GUI 
> variable is switched to FALSE as you can see in the two MESSAGE commands 
> I put in my code (GUI VALUE =). Though, I would tend to think that the 
> -D command should have the last word.
> 
> There should be something I completely missed.
> 
> thanks a lot
> 
> see you
> 
> Eric

FYI, see [1,2]. ATM, until 9980 is addressed, the best you can do when
changing compilers is throwing away the build tree, starting all over
with a fresh/empty one and specifying the compilers via the CC/CXX/FC
environment variables, the usually recommended way. As an alternative,
provide one build tree per set of compilers from the first. In case of
numerous -D settings, you might use CMake's -C option for convenience.

Regards,

Michael

[1] http://www.mail-archive.com/cmake@cmake.org/msg34486.html
[2] http://public.kitware.com/Bug/view.php?id=9980
___
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] Launching a script after user picks components in component-based installers

2011-07-02 Thread Mathias Gaunard
With a component-based installer such as NSIS, the user can choose the 
components that he wants to install.


I would need to launch a script (just launching an external program 
would do) after this, telling me where the application was installed, so 
that I can perform additional actions depending on which components were 
installed or so I can autoconfigure the application according to the 
system settings.


Does CMake/CPack allow to do something like this?

I see that RPM appears to allow to specify a shell script for post 
install, but I'd like to have something that works for all 
component-based CPack generators, and all operating systems.

___
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] Problem with CMake _not_ failing due to unsatisfied indirect project dependencies

2011-07-02 Thread Bartosz Brachaczek
Hello,
I received report from a Debian testing user (using cmake 2.8.4 from
Ubuntu repo) that gadu_protocol plugin for Kadu IM[1] was linked
improperly (it didn't link to libgadu) and refused to load. After
small investigation we found out that it was due to missing gnutls.pc
in his system. I'm attaching some logs. Note that Kadu IM checks for
libgadu using the following command:
pkg_search_module (LIBGADU REQUIRED libgadu>=${LIBGADU_MIN_VERSION})

My question here is whether there is a way to force CMake to fail in
such case, informing user about unsatisfied dependencies. Or maybe
it's just a regular bug that I should report to your bug tracking
system?

Cheers,
Bartosz

[1] Sources to browse online available here:
https://gitorious.org/kadu/kadu/trees/0.10.0-beta1.
prefix=/usr
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include

Name: libgadu
Version: 1.11.0
Description: libgadu
Requires:  gnutls
Libs: -L${libdir} -lgadu  -pthread  -lz -lgnutls  
Cflags: -I${includedir}  -pthread  
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- No NETWORK_IMPLEMENTATION defined. Autodetected implementation: Qt
fatal: Not a git repository (or any parent up to mount parent )
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
-- Looking for include files HAVE_EXECINFO
-- Looking for include files HAVE_EXECINFO - found
-- Looking for Q_WS_X11
-- Looking for Q_WS_X11 - found
-- Looking for Q_WS_WIN
-- Looking for Q_WS_WIN - not found.
-- Looking for Q_WS_QWS
-- Looking for Q_WS_QWS - not found.
-- Looking for Q_WS_MAC
-- Looking for Q_WS_MAC - not found.
-- Found Qt-Version 4.7.3 (using /usr/bin/qmake)
-- Found Kadu headers: /usr/local/include/kadu/kadu
-- checking for one of the modules 'qca2'
-- Looking for XOpenDisplay in 
/usr/lib/i386-linux-gnu/libX11.so;/usr/lib/i386-linux-gnu/libXext.so
-- Looking for XOpenDisplay in 
/usr/lib/i386-linux-gnu/libX11.so;/usr/lib/i386-linux-gnu/libXext.so - found
-- Looking for gethostbyname
-- Looking for gethostbyname - found
-- Looking for connect
-- Looking for connect - found
-- Looking for remove
-- Looking for remove - found
-- Looking for shmat
-- Looking for shmat - found
-- Looking for IceConnectionNumber in ICE
-- Looking for IceConnectionNumber in ICE - found
-- Found X11: /usr/lib/i386-linux-gnu/libX11.so
-- Found X11 libraries: /usr/lib/i386-linux-gnu/libX11.so
-- Found X11 Xfixes extension: /usr/lib/i386-linux-gnu/libXfixes.so
-- Using Qt network implementation
-- Plugin: amarok1_mediaplayer
-- Plugin: antistring
-- Plugin: auto_hide
-- Plugin: autoaway
-- Plugin: autoresponder
-- Plugin: autostatus
-- Plugin: cenzor
-- Plugin: chat_notify
-- Plugin: config_wizard
-- Plugin: desktop_docking
-- Plugin: docking
-- Plugin: encryption_ng
-- Plugin: encryption_ng_simlite
-- Plugin: exec_notify
-- Plugin: ext_sound
-- Plugin: falf_mediaplayer
-- Plugin: filedesc
-- Plugin: firewall
-- Plugin: freedesktop_notify
-- Plugin: gadu_protocol
-- checking for one of the modules 'libgadu>=1.11.0'
Package gnutls was not found in the pkg-config search path.
Perhaps you should add the directory containing `gnutls.pc'
to the PKG_CONFIG_PATH environment variable
Package 'gnutls', required by 'libgadu', not found
Package gnutls was not found in the pkg-config search path.
Perhaps you should add the directory containing `gnutls.pc'
to the PKG_CONFIG_PATH environment variable
Package 'gnutls', required by 'libgadu', not found
Package gnutls was not found in the pkg-config search path.
Perhaps you should add the directory containing `gnutls.pc'
to the PKG_CONFIG_PATH environment variable
Package 'gnutls', required by 'libgadu', not found
Package gnutls was not found in the pkg-config search path.
Perhaps you should add the directory containing `gnutls.pc'
to the PKG_CONFIG_PATH environment variable
Package 'gnutls', required by 'libgadu', not found
Package gnutls was not found in the pkg-config search path.
Perhaps you should add the directory containing `gnutls.pc'
to the PKG_CONFIG_PATH environment variable
Package 'gnutls', required by 'libgadu', not found
Package gnutls was not found in the pkg-config search path.
Perhaps you should add the directory containing `gnutls.pc'
to the PKG_CONFIG_PATH environment variable
Package 'gnutls', required by 'libgadu', not found
Package gnutls was not found in the pkg-config search path.
Perhaps you should add the directory containing `gnutls.pc'
to the PKG_CONFIG_PATH environment variable
Package 'gnutls', required by 'libgadu', not found
Package gnutls was not found in the pkg-config search path.
Perhaps you should 

Re: [CMake] Project with .NET Formular (Header with resx)

2011-07-02 Thread Simon Adler
I tried some more.
I changed the Headers in the VS2008 Project (generated by cmake)
manually to type Header-Formula.
I tried to enter the Form-Designer with a double-Click on a Form, but
VS2008 showed me that the form is now corrupt. So i have to alter my
question:

Is it even possible to generate a cmake Projekt using .NET Forms?

Greetings

Simon



On Sat, Jul 2, 2011 at 1:01 PM, Simon Adler  wrote:
> Hello Mailing List
>
> i am quite new to CMake. I have a project i originally build with
> visual studio 2008.
> I try to create a cmake Projekt so i can use cmake in the future.
> I am using .NET Forms which are Headers with associated resx files. In
> Visual-Studio the only
> difference between Headers and Forms are that the FileType differs (In
> the propierties)
>
> How can I change this for a header via cmake?
>
> # find header in current folder
> file (GLOB  fhead "*.h")
> foreach ( filename ${fhead} )
>        GET_FILENAME_COMPONENT( filepath ${filename} PATH )
>        GET_FILENAME_COMPONENT( filebase ${filename} NAME_WE )
>        SET(Source "${filepath}/${filebase}.cpp")
>        SET(Res    "${filepath}/${filebase}.resx")
>        if (EXISTS ${Res}) # a resx exists, so it IS a form
>                SET(FormHeader ${FormHeader} ${filename})
>                if (EXISTS ${Source}) # there is an additional implementation 
> file
>                     SET(FormSource ${FormSource} ${Source})
>                endif (EXISTS ${Source})
>        endif (EXISTS ${Res})
> endforeach ( filename )
>
> With this code i got the forms how i expect it, but every header is
> just a Header and not
> konwn as formular to visual studio
>
> Hope some may give me a hint.
>
> Thank you very much
>
> Simon
>
___
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] Project with .NET Formular (Header with resx)

2011-07-02 Thread Simon Adler
Hello Mailing List

i am quite new to CMake. I have a project i originally build with
visual studio 2008.
I try to create a cmake Projekt so i can use cmake in the future.
I am using .NET Forms which are Headers with associated resx files. In
Visual-Studio the only
difference between Headers and Forms are that the FileType differs (In
the propierties)

How can I change this for a header via cmake?

# find header in current folder
file (GLOB  fhead "*.h")
foreach ( filename ${fhead} )
GET_FILENAME_COMPONENT( filepath ${filename} PATH )
GET_FILENAME_COMPONENT( filebase ${filename} NAME_WE )
SET(Source "${filepath}/${filebase}.cpp")
SET(Res"${filepath}/${filebase}.resx")
if (EXISTS ${Res}) # a resx exists, so it IS a form
SET(FormHeader ${FormHeader} ${filename})
if (EXISTS ${Source}) # there is an additional implementation 
file
 SET(FormSource ${FormSource} ${Source})
endif (EXISTS ${Source})
endif (EXISTS ${Res})
endforeach ( filename )

With this code i got the forms how i expect it, but every header is
just a Header and not
konwn as formular to visual studio

Hope some may give me a hint.

Thank you very much

Simon
___
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