Re: [CMake] WIN32_EXECUTABLE - Config specific settings for visual studio generated project files?
Thanks Stefan, this worked well. My exact usage using your recommendations was as follows: if(WIN32) set_target_properties(WindowApplicationExample PROPERTIES LINK_FLAGS_DEBUG "/SUBSYSTEM:CONSOLE") set_target_properties(WindowApplicationExample PROPERTIES RELWITHDEBINFO "/SUBSYSTEM:CONSOLE") set_target_properties(WindowApplicationExample PROPERTIES LINK_FLAGS_RELEASE "/SUBSYSTEM:WINDOWS") set_target_properties(WindowApplicationExample PROPERTIES MINSIZEREL "/SUBSYSTEM:WINDOWS") endif(WIN32) This allows per-config setting of weather or not to use a console in visual studio, although it does not change the actual Subsytem setting in the Linker section, it does add it to the Additional Options setting in the Command Line section, which is then appended to the list of these settings and produces the same result. Thanks for the help! Jason On Mon, Oct 6, 2008 at 10:49 AM, Stefan Buschmann <[EMAIL PROTECTED]>wrote: > Jason Eubank schrieb: > >> Hello, >> >> I am wondering if it is possible to set the target property >> 'WIN32_EXECUTABLE' on a per-config basis (i.e. you can set link-flags on a >> per-config basis using LINK_FLAGS_). From reading the documentation >> this does not seem possible and if you set this property then all >> configurations (in Visual Studio) use the same subsystem setting. >> > I don't know whether or not CMake is able to set a property on a > per-configuration basis. I doubt this is possible (yet), but could be that > I'm wrong here. > > But you could simply set the appropriate flags for a console/win32 > application yourself, without using this flag at all. The only differences I > could find between a win32 application and a console application are > - Linker flag: "/SUBSYSTEM:CONSOLE" for console apps and > "/SUBSYSTEM:WINDOWS" for win32 apps > - Preprocessor definition: '_CONSOLE' for console apps > > Setting these using LINK_FLAGS_ and COMPILE_DEFINITIONS_ > should do exactly what you want. The only problem I see that could possibly > arise is that you can't depend on the WIN32_EXECUTABLE flag in your CMake > file(s) anymore, to test for it or use it in any other way later. > > Another solution that comes to my mind is to always create a win32 > application, and then open a console window later by using the win32 > function 'AllocConsole' in your code. I never really needed this, but I know > those functions are there to create or attach a console window to a win32 > application. Have a look at the documentation for this function. > > Stefan > > ___ > CMake mailing list > CMake@cmake.org > http://www.cmake.org/mailman/listinfo/cmake > ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Using cmake -E copy_directory with subversion
Hello,
I have come across a problem using CMake with SVN.
I have a src/shaders directory containing files with extension ".glsl". I
need to create a rule to copy these files in my build directory, since my
program will need them at runtime.
For now, i have:
ADD_CUSTOM_TARGET( install_shaders ALL ${CMAKE_COMMAND} -E copy_directory
${CMAKE_HOME_DIRECTORY}/shaders/
${CMAKE_CURRENT_BINARY_DIR}/${CMAKE_CFG_INTDIR} )
The problem is that _everything_ in src/shaders is copied to the build
directory, including the hidden .svn directory! So now after running a make,
i can't commit anything since SVN complains about having the same
destination URL for src/shaders and the build directory.
I tried to fix it with:
ADD_CUSTOM_TARGET( install_shaders ALL ${CMAKE_COMMAND} -E copy
${CMAKE_HOME_DIRECTORY}/shaders/*.glsl
${CMAKE_CURRENT_BINARY_DIR}/${CMAKE_CFG_INTDIR} )
But CMake reports an error.
I would really appreciate any possible help,
thanks a lot!
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] WXDialog question
The following code is in WXDialog: SET( wxWidgets_USE_LIBS std html adv xml xrc ) FIND_PACKAGE(wxWidgets REQUIRED) This failed. I replace std with "base core" and it configured (though I haven't built it). Is support for WXDialog current? It's in the source distribution. Thanks, James ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] XCode 3.0
CMake should be supporting Xcode through 3.1 when run on Leopard. Are you having some issues with this? Xcode will automatically select the best number of compile processes to use when compiling. There are over rides that you can do using the "defaults" system. Google around for them. Apple now allows multiple versions of Xcode to be installed. Use the xcode-select tool to select which of your installed versions to use. Each Xcode has a version of GCC tied to it so I am not sure trying to use another one would be supported. There used to be "gcc-select" under Xcode 2.x but I don't seem to have that anymore on my Xcode 3.1 installation. Maybe I should have installed the 10.3.9 SDK to get that. Mike On Oct 6, 2008, at 4:50 PM, Neal Meyer wrote: Are there any plans or WIP for support XCode 3.0-3.1 projects? To support the build targets in parallel option. Also is there an easy way to set the GCC version that is used by the XCode project? so the projects will use the latest version of GCC rather then 4.0. -Neal ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Specifying the 'make' you want with a ctest script
With a new-style ctest script like this, you should set CTEST_BUILD_COMMAND
and CTEST_BUILD_FLAGS to specify the make executable and arguments to it if
you need values different than those ctest uses by default. If you set
those, there is no need to set the MAKECOMMAND in the cache.
HTH,
David
On Wed, Sep 24, 2008 at 8:12 PM, Wheeler, Frederick W (GE, Research) <
[EMAIL PROTECTED]> wrote:
> CMake List:
>
> Here is a snippet of a ctest script I'm using.
>
> ...
> CTEST_EMPTY_BINARY_DIRECTORY( "${CTEST_BINARY_DIRECTORY}" )
> FILE( WRITE "${CTEST_BINARY_DIRECTORY}/CMakeCache.txt"
> "${CTEST_INITIAL_CACHE}" )
> CTEST_CONFIGURE( BUILD "${CTEST_BINARY_DIRECTORY}" RETURN_VALUE res )
> CTEST_READ_CUSTOM_FILES( "${CTEST_SOURCE_DIRECTORY}" )
> CTEST_BUILD( BUILD "${CTEST_BINARY_DIRECTORY}" RETURN_VALUE res )
> CTEST_TEST( RETURN_VALUE res )
> ...
>
> The problem I'm having is that during the CTEST_BUILD command, 'make'
> (the default?) seems to be used, instead of the
> MAKECOMMAND:STRING=C:/cygwin/home/26507/make -k that I put into
> the initial CMakeCache.txt with the FILE( WRITE ... command. Setting
> MAKECOMMAND in the initial cache used to work for me with earlier
> versions of ctest and the earlier style of ctest script.
>
> My question: Is there some special CTEST_ variable that needs to be
> set to the make I want to use?
>
> Another option I guess I have is to wait for cygwin to upgrade make to
> the newer version that works with the Makefiles produced by CMake.
> I'm sure that will happen any day now.
>
> Thanks,
> Fred Wheeler
> ___
> CMake mailing list
> CMake@cmake.org
> http://www.cmake.org/mailman/listinfo/cmake
>
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] XCode 3.0
Are there any plans or WIP for support XCode 3.0-3.1 projects? To support the build targets in parallel option. Also is there an easy way to set the GCC version that is used by the XCode project? so the projects will use the latest version of GCC rather then 4.0. -Neal ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] WIN32_EXECUTABLE - Config specific settings for visual studio generated project files?
Jason Eubank schrieb: Hello, I am wondering if it is possible to set the target property 'WIN32_EXECUTABLE' on a per-config basis (i.e. you can set link-flags on a per-config basis using LINK_FLAGS_). From reading the documentation this does not seem possible and if you set this property then all configurations (in Visual Studio) use the same subsystem setting. I don't know whether or not CMake is able to set a property on a per-configuration basis. I doubt this is possible (yet), but could be that I'm wrong here. But you could simply set the appropriate flags for a console/win32 application yourself, without using this flag at all. The only differences I could find between a win32 application and a console application are - Linker flag: "/SUBSYSTEM:CONSOLE" for console apps and "/SUBSYSTEM:WINDOWS" for win32 apps - Preprocessor definition: '_CONSOLE' for console apps Setting these using LINK_FLAGS_ and COMPILE_DEFINITIONS_ should do exactly what you want. The only problem I see that could possibly arise is that you can't depend on the WIN32_EXECUTABLE flag in your CMake file(s) anymore, to test for it or use it in any other way later. Another solution that comes to my mind is to always create a win32 application, and then open a console window later by using the win32 function 'AllocConsole' in your code. I never really needed this, but I know those functions are there to create or attach a console window to a win32 application. Have a look at the documentation for this function. Stefan ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] FindPETSc attempt, FindMPI brittleness, common dependencies
Attached is an attempt at a FindPETSc module. Since PETSc is often
linked to many libraries (more than 40, configuration dependent, in many
different directories) it is unreasonable to ask the user to provide all
libs. This module uses PETSC_DIR and PETSC_ARCH (when using the PETSc
build system these must be environment variables so we check there if
these are not in cache) to determine the correct paths. It parses the
link line in order, creating a reverse order list of library paths to be
used as HINTS for find_library.
I have noticed two problems with FindMPI. First, even when I specify
MPI_COMPILER to be a nonstandard path, it still finds MPIEXEC in
/usr/bin. Second, while it uses MPI_LINK_PATH as HINTS, it first
constructs the full list of libraries and then finds all the libraries.
This will not work correctly if the link line is `-L/A -la -L/B -lb' and
/B/liba.so exists. I think that the same construction as in FindPETSc
needs to be used here.
Currently my FindPETSc module sets PETSC_MPIEXEC and PETSC_COMPILER,
these can be used to set MPIEXEC and MPI_COMPILER in order to let the
PETSc configuration determine which MPI is used.
I have another library which uses a related configuration method. There
is a file /path/to/lib/iMesh-Defs.inc which is intended to be included
in the Makefile and sets variables IMESH_INCLUDES and IMESH_LIBS. I am
using a similar scheme of writing a temporary Makefile, using
exec_program [1] to extract the variables through the Makefile,
constructing a reverse-order list of library paths as I traverse
IMESH_LIBS, and using this as HINTS to find_library. Maybe this
functionality could be put in a separate module?
The link line could probably be improved by retaining only the last
occurrence of each library. REMOVE_DUPLICATES works on my system, but I
think it would break when the link line is `-la -lb -la' where libb
depends on liba. Am I wrong?
How can we determine at configuration time whether a given set of
libraries are linked against the same MPI (and other common intermediate
libs such as ParMetis, Zoltan, HDF5, etc)? This is critical since
different MPI implementations are not binary-compatible (for instance
MPI_Comm has size 4 on x86_64 MPICH and size 8 with Open MPI or LAM).
The current approach is entirely manual (the *user* must know the link
tree of each library intermediate lib and manually check consistency in
advanced mode) and can build cleanly but fail in a nasty way (seg fault
at runtime).
[1] execute_process is broken for me with CMake 2.6.2.
execute_process (echo foo bar OUTPUT_VARIABLE THIS_IS_EMPTY)
exec_program (echo ARGS foo bar OUTPUT_VARIABLE THIS_HAS_STRING)
Jed
# - Try to find PETSc
# Once done this will define
#
# PETSC_FOUND - system has PETSc
# PETSC_INCLUDE_PATH - the PETSc include directories
# PETSC_LIBRARIES - Link these to use PETSc
# PETSC_COMPILER - Compiler used by PETSc
# PETSC_DEFINITIONS - Compiler switches required for using PETSc
# PETSC_MPIEXEC - Executable for running MPI programs
#
# Setting these changes the behavior of the search
# PETSC_DIR - directory in which PETSc resides
# PETSC_ARCH - build architecture
#
# Redistribution and use is allowed according to the terms of the BSD license.
# For details see the accompanying COPYING-CMAKE-SCRIPTS file.
#
# If unset, try environment
if (NOT PETSC_DIR)
set (PETSC_DIR $ENV{PETSC_DIR})
endif (NOT PETSC_DIR)
if (NOT PETSC_ARCH)
set (PETSC_ARCH $ENV{PETSC_ARCH})
endif (NOT PETSC_ARCH)
# Crude attempt to determine PETSC_DIR, not useful since we can't
# determine PETSC_ARCH
if (NOT PETSC_DIR)
find_path (PETSC_DIR include/petsc.h
PATHS /usr /usr/local $ENV{HOME}/petsc)
endif (NOT PETSC_DIR)
# The configuration is current if both PETSC_DIR and PETSC_ARCH are
# equal to their saved values. On the first pass, these will match if
# nothing is in the environment, this is okay since PETSC_INCLUDE_PATH
# and PETSC_LIBRARIES are unset.
set (PETSC_CONFIG_CURRENT TRUE)
if (NOT "${PETSC_DIR}" STREQUAL "${PETSC_DIR_PRIVATE}")
set (PETSC_CONFIG_CURRENT FALSE)
endif (NOT "${PETSC_DIR}" STREQUAL "${PETSC_DIR_PRIVATE}")
if (NOT "${PETSC_ARCH}" STREQUAL "${PETSC_ARCH_PRIVATE}")
set (PETSC_CONFIG_CURRENT FALSE)
endif (NOT "${PETSC_ARCH}" STREQUAL "${PETSC_ARCH_PRIVATE}")
# Determine whether the PETSc layout is old-style (through 2.3.3) or
# new-style (not yet released, petsc-dev)
if (EXISTS ${PETSC_DIR}/${PETSC_ARCH}/include/petscconf.h) # new
set (PETSC_CONF_BASE ${PETSC_DIR}/conf/base)
elseif (EXISTS ${PETSC_DIR}/bmake/${PETSC_ARCH}/petscconf.h) # old
set (PETSC_CONF_BASE ${PETSC_DIR}/bmake/common/base)
else (EXISTS ${PETSC_DIR}/bmake/${PETSC_ARCH}/petscconf.h)
# The layout is not recognized, how can we give a meaningful warning?
endif (EXISTS ${PETSC_DIR}/${PETSC_ARCH}/include/petscconf.h)
if (PETSC_CONFIG_CURRENT AND PETSC_INCLUDE_PATH AND PETSC_LIBRARIES)
# Do nothing: all variables are in cache
elseif (PETSC_DIR AND PETSC_ARCH AND CMAKE_MAKE_P
Re: [CMake] (CPack) Separate packaging of subdirectories
On Fri, Oct 3, 2008 at 1:22 AM, 0xd34df00d <[EMAIL PROTECTED]> wrote: > 2008/10/2 Eric Noulard <[EMAIL PROTECTED]>: > > 2008/10/2 0xd34df00d <[EMAIL PROTECTED]>: > >> Hi there! > >> > >> I have a project which consists of main application, few helper > >> libraries and some plugins, each of them is in its own directory with > >> own CMakeLists.txt and target. Targets are added using ADD_LIBRARY and > >> ADD_EXECUTABLE commands. > >> How could I instruct CPack to create separate binary packages for each > >> directory (or such target)? > > > > You may either try to use CPack Component: > > http://www.cmake.org/Wiki/CMake:Component_Install_With_CPack > > but it is not supported by many CPack generator [yet]. > Most of all I'm interested in Deb generator. What's the most correct > solution for it? > > > > > or you'll have to create several projects, > > one for part you want to package separately. > > > > The real question is why do you want to have so many different > > binary packages? > One is for main app, another two for some libraries shared among main > app and some other projects, others (virtually unlimited number) - for > plugins for my application. Theoretically this should be multi-component setup. For RPM this was discussed as "create multiple RPMs from single spec file". Neither RPM nor DEB generators don't support this feature yet. Anyways, you can create several cpack configuration files and put necessary content in each one. (as Eric mentioned). > > > > -- > Rudoy Georg > LeechCraft — http://sourceforge.net/projects/leechcraft and > http://deviant-soft.ws > Spicy — http://deviant-soft.ws > ___ > CMake mailing list > CMake@cmake.org > http://www.cmake.org/mailman/listinfo/cmake > ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Disable warnings in Visual Studio Express 2008
2008/10/2 user790 user790 <[EMAIL PROTECTED]>
> Disabling specific warnings is a simple task so I thought I could do it
> myself but I must admit defeat. A simple CMakeLists.txt like this won't
> work.
>
> project(testcmake)
> # None of this works
> #set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /wd4669")
> set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /wd4669" CACHE STRING "Compilation
> flags" FORCE)
> #set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -wd4669")
> #set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -wd4669" CACHE STRING "Compilation
> flags" FORCE)
> add_executable(foo foo.cxx)
>
> I have tried the same variants with COMPILE_FLAGS and CMAKE_CXX_FLAGS_DEBUG
> / RELEASE with the same unsuccess.
>
1) What does your "unsuccess" mean?
2) You can edit flags from GUI, this should work.
3) If you want to override settings, you can set these flags without
caching. This usually works too.
>
> I only have VS Express 2008 so I can't check whether I am doing something
> wrong or if there is some issue with this particular IDE -- not even sure if
> it is explicitely not supported.
>
> Thanks for your help,
>
> Tom
>
>
> ___
> CMake mailing list
> CMake@cmake.org
> http://www.cmake.org/mailman/listinfo/cmake
>
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] link problem with cmake
On 10/5/08, Alexander Neundorf <[EMAIL PROTECTED]> wrote:
> On Sunday 05 October 2008, Oliver Dole wrote:
> > Hello,
> >
> > I have a link problem with cmake on Linux.
> > I work on owb, a webkit based browser, which uses cmake as build
> > system. Here is how my cmake system works:
> > - build balwtf.a, kjs.a and webcore.a
> > - build libwebkit.so which requires balwtf.a, kjs.a and webcore.a
> > - then I build owb.
> >
> > >From my point of view to do a correct link on linux, I simply should do:
> >
> > g++ -c main.cpp.o -lwebkit -o owb
> > Unfortunately, by default cmake transitively links to targets with
> > which the library itself was linked.
> > so my link is currently the following:
> > g++ -c main.cpp.o -lwebkit -Wl,--whole-archive -lbalwtf -lkjs
> > -lwebcore -o owb
>
>
> Does cmake support whole-archive now ? I didn't know that.
>
kind of...
I have done the followig "ugly" thing to make cmake support it:
if(CMAKE_COMPILER_IS_GNUCXX)
set(WEBKKIT_LD_FLAGS "-Wl,-whole-archive -lbalwtf -lkjs -lwebcore
-Wl,-no-whole-archive")
endif(CMAKE_COMPILER_IS_GNUCXX)
target_link_libraries(webkit-owb
${WEBKKIT_LD_FLAGS}
${EXTERNAL_DEPS_LIBRARIES}
)
>
> > It seems that there is something to do with LINK_INTERFACE_LIBRARIES
> > to remove the default behaviour, but I do not know what. So any help
> > on how to archieve that is welcome.
>
>
> Please use at cmake >= 2.6.2.
> Then specifiy the "link interface" of webkit, it's now done with a new
> argument to target_link_libraries().
> target_link_libraries(webkit kjs balwtf webcore)
> target_link_libraries(webkit LINK_INTERFACE_LIBRARIES ) <- makes the "link
> interface" empty.
> I hope I remember correctly, since I didn't test this right now.
>
Thanks, after an update to cmake 2.6.2 it perfectly works.
> Alex
>
>
>
>
>
>
> >
> > Regards,
> ___
> CMake mailing list
> CMake@cmake.org
> http://www.cmake.org/mailman/listinfo/cmake
>
--
Olivier DOLE
Pleyo
Software Engineer
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
