Re: [CMake] cmake on MinGW64; which generator
Dear Christopher, Am 23. Juni 2019 23:31:01 MESZ schrieb Christopher Webster : >On 6/23/19 9:22 AM, Alan W. Irwin wrote: >> >> There are a lot of different platforms that use the MinGW-w64 >compiler >> so you should probably >> describe the platform where you are attempting to use that compiler >in >> more detail. For example, >> it sounds like you are simply taking a normal Window platform and >> downloading the >> MinGW-w64 compiler for that platform, but what is the exact URL for >> that download? > >As Cristian surmised we use msys2/mingw64; we download from >www.msys2.org (the x86_64 option). Then install the mingw64 toolchain, >and use mingw64 shells: > >pacman -Sy msys2-devel >pacman -Sy mingw-w64-x86_64-toolchain >pacman -Sy base-devel >pacman -Sy mingw-w64-x86_64-check >pacman -Sy mingw-w64-x86_64-qt5 >pacman -Sy mingw-w64-x86_64-qwt-qt5 >pacman -Sy mingw-w64-x86_64-doxygen >pacman -Sy mingw-w64-x86_64-boost >pacman -Sy mingw-w64-x86_64-git-lfs >pacman -Sy mingw-w64-x86_64-gsl >pacman -Sy mingw-w64-x86_64-netcdf >pacman -Sy mingw-w64-x86_64-curl >pacman -Sy mingw-w64-x86_64-postgresql >pacman -Sy nano scons vim git procps > >cmake was installed via: > >pacman -Sy cmake try to install and use mingw-w64-x86_64-cmake in the mingw64 shell. Additionally, see this answer and the corresponding thread: https://cmake.org/pipermail/cmake/2018-January/066869.html Kind regards Benjamin > > >> >> I don't have any recent direct experience myself (I have no access to >> Microsoft Windows and Wine Windows bugs are currently blocking access >> to MSYS2), but PLplot developers I am aquainted with have recently >had >> a lot of success with the [MSYS2 >> platform](https://github.com/msys2/msys2/wiki) which is another >exaple >> of a platform that uses the MinGW-w64 compiler. For that platform >> they have found that "Unix Makefiles" and "MSYS Makefiles" generally >> give good results. They haven't yet tried "MinGW Makefiles" but from >> my ancient (MSYS/Wine where MSYS is the predecessor of MSYS2) >> experience for that generator you have to be sure that sh.exe is not >> on your PATH (e.g., by renaming it) before it will work. (I have >> never quite been sure why that was a requirement, but my guess was >the >> "mingw" make version acts differently if it detects sh.exe.) But >> again from my ancient experience the rest of the Unix tools provided >> by MSYS2 including bash.exe will likely work well with the "MinGW >> Makefiles" generator. >> >> I hope this (ancient direct and recent indirect) practical experience >> with "Unix Makefiles", "MSYS Makefiles", "MinGW Makefiles", and >> MinGW-w64 will be of some help to you. >> >> Alan >> __ >> Alan W. Irwin >> >> Programming affiliations with the FreeEOS equation-of-state >> implementation for stellar interiors (freeeos.sf.net); the Time >> Ephemerides project (timeephem.sf.net); PLplot scientific plotting >> software package (plplot.org); the libLASi project >> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); >> and the Linux Brochure Project (lbproject.sf.net). >> __ >> >> Linux-powered Science >> __ > > >-- > >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: >https://cmake.org/mailman/listinfo/cmake -- 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: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] Problem using VS-compiled Clang as a C/C++ compiler.
Hi Anton, Zitat von Anton Yartsev : Here are the results from 'CXX=clang-cl.exe CC=clang-cl.exe cmake -G "Ninja" ..' : $ set CXX=clang-cl $ set CC=clang-cl $ cmake -G "Ninja" .. -- No build type selected, default to Debug -- The C compiler identification is Clang 3.7.1 -- The CXX compiler identification is Clang 3.7.1 -- Check for working C compiler using: Ninja -- Check for working C compiler using: Ninja -- broken CMake Error at C:/Program Files/CMake/share/cmake-3.5/Modules/CMakeTestCCompiler.cmake:61 (message): The C compiler "D:/-Work-/llvm-3.7.1.src/-VS_build VS 2013-/Release/bin/clang-cl.exe" is not able to compile a simple test program. the path to your compiler seems to have spaces in it. I had problems on Windows with spaces or other special characters in the compiler path, too. Please try to locate the compiler in another path and see if it fixes your issue. If it does, maybe the CMake developers could check the path escaping on Windows. Kind regards Benjamin -- 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] Find SDL
Hi Christer,
Zitat von Christer Solskogen :
They are cross compiled for Windows (mingw-w64) which means that they have
different names (libSDL.dll.a for instance) but they are installed in
/opt/cross-mingw-w64/x86_64-w64-mingw32/{include,lib}.
x86_64-w64-mingw32-gcc is using /home/solskogen/obj/cross-mingw-w64 as
sysroot.
cmake have no trouble finding png or zlib.
-- Found ZLIB: /opt/cross-mingw-w64/x86_64-w64-mingw32/lib/libz.a (found
version "1.2.8")
-- Found PNG: /opt/cross-mingw-w64/x86_64-w64-mingw32/lib/libpng.a (found
version "1.6.12")
I have created a small test [1] that downloads and builds SDL2,
installs it, and builds a little test program using SDL2. For
cross-compiling, I am using the mingw-w64 [2] compilers provided in
Debian GNU/Linux. I use the FindSDL2 module that I posted to this
mailing list some time ago [3, 4]. This module has no problem finding
the SDL2 installation:
-- Found SDL2: [… snip …]/cmake-FindSDL-test/install/include/SDL2
(found suitable version "2.0.3", minimum required is "2.0.3")
Have you also installed SDL2, or did you try to find the build directory?
Kind regards
Benjamin
[1] https://github.com/eikel/CMake-FindSDL-Test
[2] https://packages.debian.org/sid/mingw-w64
[3] http://www.cmake.org/pipermail/cmake/2013-August/055518.html
[4] https://github.com/PADrend/Util/blob/master/cmake/FindSDL2.cmake
--
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] Find SDL
Hello Christer, Zitat von Christer Solskogen : Hi! I have a cross compiler, installed into /opt/cross, which is compiled by me. This cross compiler (gcc) is sysroot aware, which means that every header and library is installed into /opt/cross/. In order to get cmake to find SDL (both SDL1 and SDL2) I need to specify SDLDIR. The project I'm using (called hatari, a Atari ST(e) emulator) is also using other libraries like readline and png, which cmake have no problem finding. Is this a bug in cmake? Right now the cmake version I'm using is 2.8.12.2, but this problem have been there since I can remember. in order to help you, I need more information. If I understand you correctly, you do not want to set the environment variable SDLDIR. Instead, you expect the FindSDL module to find SDL without that information. Is that correct? Please give some more information about your installation. In which path exactly is SDL located (where is "SDL.h", where is "libSDL.a" or "libSDL.so")? Kind regards Benjamin -- 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] Find modules for SDL2
Hello,
I have written find modules for SDL2, SDL2_image and SDL2_net (see attachment).
I have tested them on Linux and Windows/MinGW with self-compiled SDL2
libraries. I did neither test with Visual Studio nor on OS X. Feel free to use
them if they are helpful for you (they are licensed under the standard license
of CMake find modules).
My question: Is it good to create new find modules for SDL2, or should the
existing SDL find modules be updated to search for SDL2?
If existing modules should be used: How to handle the case when both SDL and
SDL2 are found?
If new modules should be created: Shall I create a topic branch for the new
modules and create the missing ones (e.g., SDL2_mixer)?
Kind regards
Benjamin# - Find SDL2 library and headers
#
# Find module for SDL 2.0 (http://www.libsdl.org/).
# It defines the following variables:
# SDL2_INCLUDE_DIRS - The location of the headers, e.g., SDL.h.
# SDL2_LIBRARIES - The libraries to link against to use SDL2.
# SDL2_FOUND - If false, do not try to use SDL2.
# SDL2_VERSION_STRING - Human-readable string containing the version of SDL2.
#
# This module responds to the the flag:
# SDL2_BUILDING_LIBRARY
#If this is defined, then no SDL2_main will be linked in because
#only applications need main().
#Otherwise, it is assumed you are building an application and this
#module will attempt to locate and set the the proper link flags
#as part of the returned SDL2_LIBRARIES variable.
#
# Also defined, but not for general use are:
# SDL2_INCLUDE_DIR - The directory that contains SDL.h.
# SDL2_LIBRARY - The location of the SDL2 library.
# SDL2MAIN_LIBRARY - The location of the SDL2main library.
#
#=
# Copyright 2013 Benjamin Eikel
#
# Distributed under the OSI-approved BSD License (the "License");
# see accompanying file Copyright.txt for details.
#
# This software is distributed WITHOUT ANY WARRANTY; without even the
# implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
# See the License for more information.
#=
# (To distribute this file outside of CMake, substitute the full
# License text for the above reference.)
find_package(PkgConfig QUIET)
pkg_check_modules(PC_SDL2 QUIET sdl2)
find_path(SDL2_INCLUDE_DIR
NAMES SDL.h
HINTS
${PC_SDL2_INCLUDEDIR}
${PC_SDL2_INCLUDE_DIRS}
PATH_SUFFIXES SDL2
)
find_library(SDL2_LIBRARY
NAMES SDL2
HINTS
${PC_SDL2_LIBDIR}
${PC_SDL2_LIBRARY_DIRS}
PATH_SUFFIXES x64 x86
)
if(NOT SDL2_BUILDING_LIBRARY)
find_library(SDL2MAIN_LIBRARY
NAMES SDL2main
HINTS
${PC_SDL2_LIBDIR}
${PC_SDL2_LIBRARY_DIRS}
PATH_SUFFIXES x64 x86
)
endif()
if(SDL2_INCLUDE_DIR AND EXISTS "${SDL2_INCLUDE_DIR}/SDL_version.h")
file(STRINGS "${SDL2_INCLUDE_DIR}/SDL_version.h" SDL2_VERSION_MAJOR_LINE REGEX "^#define[ \t]+SDL_MAJOR_VERSION[ \t]+[0-9]+$")
file(STRINGS "${SDL2_INCLUDE_DIR}/SDL_version.h" SDL2_VERSION_MINOR_LINE REGEX "^#define[ \t]+SDL_MINOR_VERSION[ \t]+[0-9]+$")
file(STRINGS "${SDL2_INCLUDE_DIR}/SDL_version.h" SDL2_VERSION_PATCH_LINE REGEX "^#define[ \t]+SDL_PATCHLEVEL[ \t]+[0-9]+$")
string(REGEX REPLACE "^#define[ \t]+SDL_MAJOR_VERSION[ \t]+([0-9]+)$" "\\1" SDL2_VERSION_MAJOR "${SDL2_VERSION_MAJOR_LINE}")
string(REGEX REPLACE "^#define[ \t]+SDL_MINOR_VERSION[ \t]+([0-9]+)$" "\\1" SDL2_VERSION_MINOR "${SDL2_VERSION_MINOR_LINE}")
string(REGEX REPLACE "^#define[ \t]+SDL_PATCHLEVEL[ \t]+([0-9]+)$" "\\1" SDL2_VERSION_PATCH "${SDL2_VERSION_PATCH_LINE}")
set(SDL2_VERSION_STRING ${SDL2_VERSION_MAJOR}.${SDL2_VERSION_MINOR}.${SDL2_VERSION_PATCH})
unset(SDL2_VERSION_MAJOR_LINE)
unset(SDL2_VERSION_MINOR_LINE)
unset(SDL2_VERSION_PATCH_LINE)
unset(SDL2_VERSION_MAJOR)
unset(SDL2_VERSION_MINOR)
unset(SDL2_VERSION_PATCH)
endif()
set(SDL2_INCLUDE_DIRS ${SDL2_INCLUDE_DIR})
set(SDL2_LIBRARIES ${SDL2MAIN_LIBRARY} ${SDL2_LIBRARY})
include(FindPackageHandleStandardArgs)
find_package_handle_standard_args(SDL2
REQUIRED_VARS SDL2_INCLUDE_DIR SDL2_LIBRARY
VERSION_VAR SDL2_VERSION_STRING)
mark_as_advanced(SDL2_INCLUDE_DIR SDL2_LIBRARY)
# - Find SDL2_image library and headers
#
# Find module for SDL_image 2.0 (http://www.libsdl.org/projects/SDL_image/).
# It defines the following variables:
# SDL2_IMAGE_INCLUDE_DIRS - The location of the headers, e.g., SDL_image.h.
# SDL2_IMAGE_LIBRARIES - The libraries to link against to use SDL2_image.
# SDL2_IMAGE_FOUND - If false, do not try to use SDL2_image.
# SDL2_IMAGE_VERSION_STRING
#Human-readable string containing the version of SDL2_image.
#
# Also d
Re: [CMake] Configure never ends when changing compiler
Am Montag, 3. Juni 2013, 12:08:19 schrieb David Demelier: > Hi there, > > After doing a CMake generation, if I try to change the C compiler by > doing cmake -DCMAKE_C_COMPILER=/usr/bin/clang it configures again but > never ends, see : > > Installation directories: > PREFIX /usr/local > MANDIR /usr/local/share/man > DOCDIR /usr/local/share/doc/irccd > MODDIR /usr/local/share/irccd/modules > > Compiling irccd with following options: > Lua support:enabled > Unit tests: disabled > Default config: /usr/local/etc/irccd.conf > > -- 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_C_COMPILER= /usr/bin/clang > > -- Looking for getopt > -- Looking for getopt - found > -- Looking for setprogname > -- Looking for setprogname - found > -- Looking for unistd.h > -- Looking for unistd.h - found > -- Found XDG: /usr/local/include > -- Found OpenSSL: /usr/lib/libssl.so;/usr/lib/libcrypto.so (found > version "0.9.8x") > -- Found LIBIRCCLIENT: /usr/local/include > Installation directories: > PREFIX /usr/local > MANDIR /usr/local/share/man > DOCDIR /usr/local/share/doc/irccd > MODDIR /usr/local/share/irccd/modules > > Compiling irccd with following options: > Lua support:enabled > Unit tests: disabled > Default config: /usr/local/etc/irccd.conf > > -- 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_C_COMPILER= /usr/bin/clang > > -- Looking for getopt > -- Looking for getopt - found > -- Looking for setprogname > -- Looking for setprogname - found > -- Looking for unistd.h > -- Looking for unistd.h - found > -- Found XDG: /usr/local/include > -- Found OpenSSL: /usr/lib/libssl.so;/usr/lib/libcrypto.so (found > version "0.9.8x") > -- Found LIBIRCCLIENT: /usr/local/include > Installation directories: > PREFIX /usr/local > MANDIR /usr/local/share/man > DOCDIR /usr/local/share/doc/irccd > MODDIR /usr/local/share/irccd/modules > > Compiling irccd with following options: > Lua support:enabled > Unit tests: disabled > Default config: /usr/local/etc/irccd.conf > > -- 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_C_COMPILER= /usr/bin/clang > > -- Looking for getopt > ^C > > Is this a known issue? Yes, this sound like: http://public.kitware.com/Bug/view.php?id=13756 > > Cheers, > > -- > Demelier David > -- > > 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 -- 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] Superbuild subprojects and find_package()
Hello John,
On Wednesday 17 April 2013 23:38:36 John Gallagher wrote:
> 3. (This one is unclear.) Somehow build proj1 before configuring proj2, and
> point proj2 at proj1's build directory so it can find Proj1Config.cmake.
> This seems fragile at best (prefix, RPATH, etc issues).
when using ExternalProject, dependencies between projects can look like this
(small excerpt from a superbuild project that I wrote):
…
include(ExternalProject)
# Build ZLIB first
ExternalProject_Add(EP_ZLIB
URL
http://download.sourceforge.net/project/libpng/zlib/1.2.7/zlib-1.2.7.tar.gz
URL_MD5 "60df6a37c56e7c1366cca812414f7b85"
PATCH_COMMAND patch -p0 <
${CMAKE_CURRENT_LIST_DIR}/zlib-CMakeLists.txt-OUTPUT_NAME.patch && patch -p0 <
${CMAKE_CURRENT_LIST_DIR}/zlib-CMakeLists.txt-version-script.patch
INSTALL_DIR ${INSTALL_DIR}
CMAKE_ARGS -DCMAKE_TOOLCHAIN_FILE:FILEPATH=${TOOLCHAIN_FILE}
-DCMAKE_INSTALL_PREFIX:PATH= -DCMAKE_BUILD_TYPE:STRING=Release
)
…
# For building CURL, use ZLIB that has been built before
ExternalProject_Add(EP_LIBCURL
DEPENDS EP_ZLIB
URL http://curl.haxx.se/download/curl-7.27.0.tar.gz
URL_MD5 "f0e48fdb635b5939e02a9291b89e5336"
CONFIGURE_COMMAND /configure --prefix=
--host=${ARCH_TRIPLET} --disable-static --disable-manual
--with-zlib= CC=${CMAKE_C_COMPILER} LD=${CMAKE_LINKER}
INSTALL_DIR ${INSTALL_DIR}
)
Kind regards
Benjamin
--
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] detecting if c++11 available
Hello Brad,
Am Mittwoch, 20. Februar 2013, 00:36:18 schrieb Brad Bell:
> My goal is to use some new c++11 features if they are available,
> otherwise to stick to the c++03 features. I need to build test programs
> that check for correctness as well as distribute an include file library.
>
> Is there a way in cmake to detect if c++11 is available and to use it
> when it is available ? I would like this to be system and compiler
> independent.
>
I am using the following code:
include(CheckCXXCompilerFlag)
CHECK_CXX_COMPILER_FLAG("-std=c++11" COMPILER_SUPPORTS_CXX11)
CHECK_CXX_COMPILER_FLAG("-std=c++0x" COMPILER_SUPPORTS_CXX0X)
if(COMPILER_SUPPORTS_CXX11)
set_property(TARGET MyTarget APPEND_STRING PROPERTY COMPILE_FLAGS
"-std=c++11 ")
elseif(COMPILER_SUPPORTS_CXX0X)
set_property(TARGET MyTarget APPEND_STRING PROPERTY COMPILE_FLAGS
"-std=c++0x")
else()
message(FATAL_ERROR "The compiler ${CMAKE_CXX_COMPILER} has no C++11
support. Please use a different C++ compiler.")
endif()
Kind regards
Benjamin
>
>
> --
>
> 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
--
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] When should I use add_subdirectory and when ExternalProject?
Am Montag, 4. Februar 2013, 09:23:20 schrieb Ansis Māliņš: > If I have a dependency (e.g. SDL2) that seems to work with add_subdirectory > just fine, should I still use ExternalProject_Add instead? Given both ways > work, what should I prefer? What are the tradeoffs? Hello Ansis, most of the time, you do not want to have external libraries (like SDL2) inside your source directory structure. Therefore, I do not think that add_subdirectory is the right way. For libraries installed on your system, you should use find_package. ExternalProject_Add does not integrate so well into the build of the project. You can use it to bootstrap (download, patch, build, and install external dependences). Kind regards Benjamin -- 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] enabling c++11 features?
Am Donnerstag, 17. Januar 2013, 10:30:59 schrieb Witold E Wolski:
> I would like to use the override keyword
> I added to my root CMakeLists.txt file
> SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++0x") (I am using gcc 4.6)
>
> However I am still getting an error i.e:
>
> error: ‘override’ does not name a type
Explicit virtual overrides are not availabe in GCC 4.6.
http://gcc.gnu.org/projects/cxx0x.html
>
> for the following declaration
>
> void getRT(std::vector & rt) const override;
>
>
>
> regards
--
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] Version in name of shared library
Am Donnerstag, 6. September 2012 um 10:01:36 schrieb Michael Wild:
> On 09/06/2012 09:43 AM, Anton Sibilev wrote:
> > Hi all!
> >
> > I'm making shared library with add_library(xxx SHARED xxx.c) and as
> > result I got 'libxxx.so'.
> > I want to create lib with name like 'libxxx.so.1', can you please help,
> > how to make this?
> >
> > Point is not to create link or copy libxxx.so -> libxxx.so.1, but to
> > create it initially.
> >
> > Thanks!
>
> You need to set the VERSION and SOVERSION target properties:
>
> http://cmake.org/cmake/help/v2.8.8/cmake.html#command:set_target_properties
Right. One example:
set(MYLIB_VERSION_MAJOR 0)
set(MYLIB_VERSION_MINOR 1)
set(MYLIB_VERSION_PATCH 1)
set(MYLIB_VERSION_STRING
${MYLIB_VERSION_MAJOR}.${MYLIB_VERSION_MINOR}.${MYLIB_VERSION_PATCH})
set_target_properties(MyLib PROPERTIES VERSION ${MYLIB_VERSION_STRING}
SOVERSION ${MYLIB_VERSION_MAJOR})
>
> 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
--
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] unknown cmake command "configure_boost"
Am Mittwoch, 5. September 2012 um 12:55:50 schrieb geek121: > ^^ error is unknown cmake command "configure_boost" Why do you think "configure_boost" is a valid CMake command? I was not able to find it in the documentation. > > > > -- > View this message in context: > http://cmake.3232098.n2.nabble.com/unknown-cmake-command-configure-boost-t > p7581513p7581514.html Sent from the CMake mailing list archive at > Nabble.com. > -- > > 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 -- 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 2.8.9, OS X 10.8 and OpenGL
Hello,
for me, the following file works
--- BEGIN CMakeLists.txt
cmake_minimum_required (VERSION 2.8.9)
project(Test)
SET(CMAKE_CXX_FLAGS "-std=c++11 -stdlib=libc++")
find_package(OpenGL REQUIRED)
include_directories(${OPENGL_INCLUDE_DIR})
find_package(GLUT REQUIRED)
include_directories(${GLUT_INCLUDE_DIR})
add_executable(Test main.cpp)
target_link_libraries(Test ${OPENGL_LIBRARIES} ${GLUT_LIBRARIES})
--- END CMakeLists.txt
when changing the includes to
#include
#include
#include
#include
#include
On OS X, these might be correct the way you specified them.
Kind regards
Benjamin
Am Mittwoch, 15. August 2012 um 23:29:16 schrieb Jason T. Slack-Moehrle:
> Hello All,
>
> I am new to CMAKE and attempting to build an OpenGL app on OS X 10.8.
> (I will be using other platforms as well)
>
> My CMakeLists.txt:
>
> cmake_minimum_required (VERSION 2.8.9)
>
> SET(CMAKE_C_COMPILER "clang")
> SET(CMAKE_CXX_COMPILER "clang++")
> SET(CMAKE_CXX_FLAGS "-std=c++11 -stdlib=libc++")
>
> IF(APPLE)
>INCLUDE_DIRECTORIES ( /System/Library/Frameworks )
>FIND_LIBRARY(COCOA_LIBRARY Cocoa)
>FIND_LIBRARY(GLUT_LIBRARY GLUT )
>FIND_LIBRARY(OpenGL_LIBRARY OpenGL )
>MARK_AS_ADVANCED (COCOA_LIBRARY
> GLUT_LIBRARY
> OpenGL_LIBRARY)
>SET(EXTRA_LIBS ${COCOA_LIBRARY} ${GLUT_LIBRARY} ${OpenGL_LIBRARY})
> ENDIF (APPLE)
> #target_link_libraries(Test ${EXTRA_LIBS})
>
> project(Test)
> add_executable(Test main.cpp)
>
> My sample code:
>
> #include
> #include
>
> #include
>
> #include
> #include
> #include
> #include
>
> void display(void)
> {
> glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
>
> glutSwapBuffers();
> }
>
> void reshape(int width, int height)
> {
> glViewport(0, 0, width, height);
> }
>
> void idle(void)
> {
> glutPostRedisplay();
> }
>
> int main(int argc, char** argv)
> {
> glutInit(&argc, argv);
>
> glutInitDisplayMode(GLUT_RGBA | GLUT_DOUBLE | GLUT_DEPTH);
> glutInitWindowSize(640, 480);
>
> glutCreateWindow("GLUT Program");
>
> glutDisplayFunc(display);
> glutReshapeFunc(reshape);
> glutIdleFunc(idle);
>
> glutMainLoop();
> return EXIT_SUCCESS;
> }
>
> and I am getting the following:
>
> $ cmake .
> CMake Error: Error required internal CMake variable not set, cmake may
> be not be built correctly.
> Missing variable is:
> CMAKE_FIND_LIBRARY_PREFIXES
> CMake Error: Error required internal CMake variable not set, cmake may
> be not be built correctly.
> Missing variable is:
> CMAKE_FIND_LIBRARY_SUFFIXES
> CMake Error: Error required internal CMake variable not set, cmake may
> be not be built correctly.
> Missing variable is:
> CMAKE_FIND_LIBRARY_PREFIXES
> CMake Error: Error required internal CMake variable not set, cmake may
> be not be built correctly.
> Missing variable is:
> CMAKE_FIND_LIBRARY_SUFFIXES
> CMake Error: Error required internal CMake variable not set, cmake may
> be not be built correctly.
> Missing variable is:
> CMAKE_FIND_LIBRARY_PREFIXES
> CMake Error: Error required internal CMake variable not set, cmake may
> be not be built correctly.
> Missing variable is:
> CMAKE_FIND_LIBRARY_SUFFIXES
> -- Configuring incomplete, errors occurred!
>
> Can anyone help me see my error?
> --
>
> 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
--
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 2.8.9, OS X 10.8 and OpenGL
Am Mittwoch, 15. August 2012 um 23:52:09 schrieb Jason T. Slack-Moehrle:
> Hi Benjamin,
>
> I modified my CMakeLists.txt file a bit:
>
> PROJECT(Test)
>
> SET(TEST_VERSION 0.1+devel)
> SET(PROJECT_NAME test)
> CMAKE_MINIMUM_REQUIRED(VERSION 2.8.9)
> SET(CMAKE_INCLUDE_CURRENT_DIR TRUE)
>
> SET(CMAKE_C_COMPILER "clang")
> SET(CMAKE_CXX_COMPILER "clang++")
>
> SET(CMAKE_CXX_FLAGS "-std=c++11 -stdlib=libc++")
>
> IF(APPLE)
>find_package(OpenGL REQUIRED)
>include_directories(${OPENGL_INCLUDE_DIR})
>
>INCLUDE_DIRECTORIES ( /System/Library/Frameworks )
>FIND_LIBRARY(COCOA_LIBRARY Cocoa)
>FIND_LIBRARY(GLUT_LIBRARY GLUT )
>FIND_LIBRARY(OpenGL_LIBRARY OpenGL )
You do not need this find_library call. Use the Variable ${OPENGL_LIBRARIES} as
in my example.
>MARK_AS_ADVANCED (COCOA_LIBRARY
> GLUT_LIBRARY
> OpenGL_LIBRARY)
>SET(EXTRA_LIBS ${COCOA_LIBRARY} ${GLUT_LIBRARY} ${OpenGL_LIBRARY})
> ENDIF (APPLE)
> #target_link_libraries(Test ${EXTRA_LIBS})
>
> add_executable(Test main.cpp)
>
> > for OpenGL, better use the shipped find module (see "cmake --help-module
> > FindOpenGL"):
> >
> > find_package(OpenGL REQUIRED)
> > include_directories(${OPENGL_INCLUDE_DIR})
> > [...]
> > target_link_libraries(Test ${OPENGL_LIBRARIES})
>
> I get errors:
>
> $ make
> Scanning dependencies of target Test
> [100%] Building CXX object CMakeFiles/Test.dir/main.cpp.o
> Linking CXX executable Test
> Undefined symbols for architecture x86_64:
> "_glClear", referenced from:
> display() in main.cpp.o
> "_glViewport", referenced from:
> reshape(int, int) in main.cpp.o
> "_glutCreateWindow", referenced from:
> _main in main.cpp.o
> "_glutDisplayFunc", referenced from:
> _main in main.cpp.o
> "_glutIdleFunc", referenced from:
> _main in main.cpp.o
> "_glutInit", referenced from:
> _main in main.cpp.o
> "_glutInitDisplayMode", referenced from:
> _main in main.cpp.o
> "_glutInitWindowSize", referenced from:
> _main in main.cpp.o
> "_glutMainLoop", referenced from:
> _main in main.cpp.o
> "_glutPostRedisplay", referenced from:
> idle() in main.cpp.o
> "_glutReshapeFunc", referenced from:
> _main in main.cpp.o
> "_glutSwapBuffers", referenced from:
> display() in main.cpp.o
> ld: symbol(s) not found for architecture x86_64
> clang: error: linker command failed with exit code 1 (use -v to see
> invocation) make[2]: *** [Test] Error 1
> make[1]: *** [CMakeFiles/Test.dir/all] Error 2
> make: *** [all] Error 2
>
> > Furthermore, I suggest using an out-of-source build. I cannot answer your
> > other question. On my Linux system I do not get these error messages.
>
> Can you tell me what you mean by 'out-of-source build"?
>
> -Jason
> --
>
> 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
--
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 2.8.9, OS X 10.8 and OpenGL
Hello again,
for GLUT there is also a find module:
cmake --help-module FindGLUT
Kind regards
Benjamin
Am Mittwoch, 15. August 2012 um 23:29:16 schrieb Jason T. Slack-Moehrle:
> Hello All,
>
> I am new to CMAKE and attempting to build an OpenGL app on OS X 10.8.
> (I will be using other platforms as well)
>
> My CMakeLists.txt:
>
> cmake_minimum_required (VERSION 2.8.9)
>
> SET(CMAKE_C_COMPILER "clang")
> SET(CMAKE_CXX_COMPILER "clang++")
> SET(CMAKE_CXX_FLAGS "-std=c++11 -stdlib=libc++")
>
> IF(APPLE)
>INCLUDE_DIRECTORIES ( /System/Library/Frameworks )
>FIND_LIBRARY(COCOA_LIBRARY Cocoa)
>FIND_LIBRARY(GLUT_LIBRARY GLUT )
>FIND_LIBRARY(OpenGL_LIBRARY OpenGL )
>MARK_AS_ADVANCED (COCOA_LIBRARY
> GLUT_LIBRARY
> OpenGL_LIBRARY)
>SET(EXTRA_LIBS ${COCOA_LIBRARY} ${GLUT_LIBRARY} ${OpenGL_LIBRARY})
> ENDIF (APPLE)
> #target_link_libraries(Test ${EXTRA_LIBS})
>
> project(Test)
> add_executable(Test main.cpp)
>
> My sample code:
>
> #include
> #include
>
> #include
>
> #include
> #include
> #include
> #include
>
> void display(void)
> {
> glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
>
> glutSwapBuffers();
> }
>
> void reshape(int width, int height)
> {
> glViewport(0, 0, width, height);
> }
>
> void idle(void)
> {
> glutPostRedisplay();
> }
>
> int main(int argc, char** argv)
> {
> glutInit(&argc, argv);
>
> glutInitDisplayMode(GLUT_RGBA | GLUT_DOUBLE | GLUT_DEPTH);
> glutInitWindowSize(640, 480);
>
> glutCreateWindow("GLUT Program");
>
> glutDisplayFunc(display);
> glutReshapeFunc(reshape);
> glutIdleFunc(idle);
>
> glutMainLoop();
> return EXIT_SUCCESS;
> }
>
> and I am getting the following:
>
> $ cmake .
> CMake Error: Error required internal CMake variable not set, cmake may
> be not be built correctly.
> Missing variable is:
> CMAKE_FIND_LIBRARY_PREFIXES
> CMake Error: Error required internal CMake variable not set, cmake may
> be not be built correctly.
> Missing variable is:
> CMAKE_FIND_LIBRARY_SUFFIXES
> CMake Error: Error required internal CMake variable not set, cmake may
> be not be built correctly.
> Missing variable is:
> CMAKE_FIND_LIBRARY_PREFIXES
> CMake Error: Error required internal CMake variable not set, cmake may
> be not be built correctly.
> Missing variable is:
> CMAKE_FIND_LIBRARY_SUFFIXES
> CMake Error: Error required internal CMake variable not set, cmake may
> be not be built correctly.
> Missing variable is:
> CMAKE_FIND_LIBRARY_PREFIXES
> CMake Error: Error required internal CMake variable not set, cmake may
> be not be built correctly.
> Missing variable is:
> CMAKE_FIND_LIBRARY_SUFFIXES
> -- Configuring incomplete, errors occurred!
>
> Can anyone help me see my error?
> --
>
> 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
--
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 2.8.9, OS X 10.8 and OpenGL
Hello Jason,
Am Mittwoch, 15. August 2012 um 23:29:16 schrieb Jason T. Slack-Moehrle:
> Hello All,
>
> I am new to CMAKE and attempting to build an OpenGL app on OS X 10.8.
> (I will be using other platforms as well)
>
> My CMakeLists.txt:
>
> cmake_minimum_required (VERSION 2.8.9)
>
> SET(CMAKE_C_COMPILER "clang")
> SET(CMAKE_CXX_COMPILER "clang++")
> SET(CMAKE_CXX_FLAGS "-std=c++11 -stdlib=libc++")
>
> IF(APPLE)
>INCLUDE_DIRECTORIES ( /System/Library/Frameworks )
>FIND_LIBRARY(COCOA_LIBRARY Cocoa)
>FIND_LIBRARY(GLUT_LIBRARY GLUT )
>FIND_LIBRARY(OpenGL_LIBRARY OpenGL )
>MARK_AS_ADVANCED (COCOA_LIBRARY
> GLUT_LIBRARY
> OpenGL_LIBRARY)
>SET(EXTRA_LIBS ${COCOA_LIBRARY} ${GLUT_LIBRARY} ${OpenGL_LIBRARY})
> ENDIF (APPLE)
> #target_link_libraries(Test ${EXTRA_LIBS})
for OpenGL, better use the shipped find module (see "cmake --help-module
FindOpenGL"):
find_package(OpenGL REQUIRED)
include_directories(${OPENGL_INCLUDE_DIR})
[...]
target_link_libraries(Test ${OPENGL_LIBRARIES})
Furthermore, I suggest using an out-of-source build. I cannot answer your
other question. On my Linux system I do not get these error messages.
Kind regards
Benjamin
>
> project(Test)
> add_executable(Test main.cpp)
>
> My sample code:
>
> #include
> #include
>
> #include
>
> #include
> #include
> #include
> #include
>
> void display(void)
> {
> glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
>
> glutSwapBuffers();
> }
>
> void reshape(int width, int height)
> {
> glViewport(0, 0, width, height);
> }
>
> void idle(void)
> {
> glutPostRedisplay();
> }
>
> int main(int argc, char** argv)
> {
> glutInit(&argc, argv);
>
> glutInitDisplayMode(GLUT_RGBA | GLUT_DOUBLE | GLUT_DEPTH);
> glutInitWindowSize(640, 480);
>
> glutCreateWindow("GLUT Program");
>
> glutDisplayFunc(display);
> glutReshapeFunc(reshape);
> glutIdleFunc(idle);
>
> glutMainLoop();
> return EXIT_SUCCESS;
> }
>
> and I am getting the following:
>
> $ cmake .
> CMake Error: Error required internal CMake variable not set, cmake may
> be not be built correctly.
> Missing variable is:
> CMAKE_FIND_LIBRARY_PREFIXES
> CMake Error: Error required internal CMake variable not set, cmake may
> be not be built correctly.
> Missing variable is:
> CMAKE_FIND_LIBRARY_SUFFIXES
> CMake Error: Error required internal CMake variable not set, cmake may
> be not be built correctly.
> Missing variable is:
> CMAKE_FIND_LIBRARY_PREFIXES
> CMake Error: Error required internal CMake variable not set, cmake may
> be not be built correctly.
> Missing variable is:
> CMAKE_FIND_LIBRARY_SUFFIXES
> CMake Error: Error required internal CMake variable not set, cmake may
> be not be built correctly.
> Missing variable is:
> CMAKE_FIND_LIBRARY_PREFIXES
> CMake Error: Error required internal CMake variable not set, cmake may
> be not be built correctly.
> Missing variable is:
> CMAKE_FIND_LIBRARY_SUFFIXES
> -- Configuring incomplete, errors occurred!
>
> Can anyone help me see my error?
> --
>
> 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
--
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] An updated cross-platform FindGlew.cmake module
Hello Carlo,
Am Donnerstag, 12. Juli 2012, 09:18:10 schrieb Carlo Nicolini:
> Hi you all, I'm trying to find an updated, simple to use and effective
> FindGlew.cmake module, because I've to include and link Glew (
> http://glew.sourceforge.net/index.html ) in my project, which needs to be
> compiled on win32, linux and osx.
>
> Can somebody help me?
I have a find module attached. It was written by me some time ago by using some
information from the CMake wiki. I do not know if it complies with any CMake
standards, but it works for me. It is used on GNU/Linux, Windows and OS X in
our project.
Kind regards
Benjamin
# Try to find GLEW. Once done, this will define:
#
# GLEW_FOUND - variable which returns the result of the search
# GLEW_INCLUDE_DIRS - list of include directories
# GLEW_LIBRARIES - options for the linker
find_package(PkgConfig)
pkg_check_modules(PC_GLEW QUIET glew)
find_path(GLEW_INCLUDE_DIR
GL/glew.h
HINTS ${PC_GLEW_INCLUDEDIR} ${PC_GLEW_INCLUDE_DIRS}
)
find_library(GLEW_LIBRARY
GLEW
HINTS ${PC_GLEW_LIBDIR} ${PC_GLEW_LIBRARY_DIRS}
)
set(GLEW_INCLUDE_DIRS ${GLEW_INCLUDE_DIR})
set(GLEW_LIBRARIES ${GLEW_LIBRARY})
include(FindPackageHandleStandardArgs)
find_package_handle_standard_args(GLEW DEFAULT_MSG
GLEW_INCLUDE_DIR
GLEW_LIBRARY
)
mark_as_advanced(
GLEW_INCLUDE_DIR
GLEW_LIBRARY
)
--
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] SHARED library containing OBJECT library: Missing -fPIC
Hello Leif, Am Freitag, 22. Juni 2012 um 15:55:55 schrieb Leif Walsh: > I tried this in my project. I added -fPIC to the COMPILE_FLAGS property of > the object library and it worked, but then you also get PIC static > libraries (which isn't that big of a deal). But time your compiles. > Usually the compilation of individual c files is well dominated by the > linking time, especially with optimization. So to reduce technical risk, I > opted just to build each library the old fashioned way and compile objects > twice. I saw pretty much no compile time difference. But maybe you have > other reasons. maybe I did not make things clear enough. I do not want to build the same library twice (static and dynamic). I just wanted to know if it is really required to add the compiler specific compile flag "-fPIC" manually when using object libraries for building a shared library. I know that there will be a compiler independent target property in CMake 2.8.9. But nevertheless, being forced to add this flags seems somehow cumbersome to me. When building a normal shared library composed only of source files, I do not have to add the flag, but it is automatically added by CMake. Kind regards Benjamin > > Sent from my iPhone > > On Jun 22, 2012, at 5:46, Andreas Naumann wrote: > > I think the latter is the case. It should not be allowed to compose a > > shared library from OBJECT libraries. What does the cmake developer > > think about this problem? > > > > Regards, > > Andreas > > > > Am 22.06.2012 11:14, schrieb Benjamin Eikel: > >> Hello Andreas, > >> > >> Am Freitag, 22. Juni 2012, 11:09:36 schrieb Andreas Naumann: > >>> Hello Benjamin, > >>> > >>> if you wants to use an object file for a shared library, this object > >>> file has to be compiled with -fPIC. I don't think, that it is possible > >>> to create a shared library from such object files. > >> > >> I know that this is the case. My question is not directed to -fPIC in > >> general, but to CMake's handling of these files. I want to use CMake's > >> new OBJECT library feature to structure the build of a library. The > >> library is built statically as well as dynamically. When building > >> statically, there is no problem in using the OBJECT libraries of CMake. > >> But when building dynamically, the problem described in my original > >> e-mail arises. CMake's documentation does not say that it is not > >> allowed to use OBJECT libraries to compose shared libraries. > >> > >> Kind regards > >> Benjamin > >> > >>> Regards, > >>> Andreas > >>> > >>> Am 22.06.2012 09:50, schrieb Benjamin Eikel: > >>>> Hello, > >>>> > >>>> I have a problem using an OBJECT library that I want to compile into a > >>>> SHARED library using CMake version 2.8.8. > >>>> > >>>> Here is a small example that demonstrates my problem: > >>>> > >>>> # --- CMakeLists.txt --- > >>>> cmake_minimum_required(VERSION 2.8.8) > >>>> project(CMakeTest CXX) > >>>> add_library(MyLibSub OBJECT > >>>> > >>>> ClassA.cpp > >>>> > >>>> ) > >>>> add_library(MyLib SHARED > >>>> > >>>> $ > >>>> ClassB.cpp > >>>> > >>>> ) > >>>> > >>>> The content of the other four files is more or less irrelevant. To > >>>> make the example complete, I added them at the end of this e-mail. > >>>> > >>>> When I want to build this example, I get the following error: > >>>> > >>>> $ mkdir build&& cd build&& cmake ..&& make > >>>> -- The CXX compiler identification is GNU 4.7.0 > >>>> -- 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 > >>>> -- Configuring done > >>>> -- Generating done > >>>> -- Build files have been written to: /home/benjamin/Desktop/CMake > >>>> test/build Scanning dependencies of target MyLibSub > >>>> [ 50%] Building CXX object CMakeFiles/MyLibSub.dir/ClassA.cpp.o > >>>> [ 50%] Built target MyLibSub > >>
Re: [CMake] SHARED library containing OBJECT library: Missing -fPIC
Hello Andreas,
Am Freitag, 22. Juni 2012, 11:09:36 schrieb Andreas Naumann:
> Hello Benjamin,
>
> if you wants to use an object file for a shared library, this object
> file has to be compiled with -fPIC. I don't think, that it is possible
> to create a shared library from such object files.
I know that this is the case. My question is not directed to -fPIC in general,
but to CMake's handling of these files. I want to use CMake's new OBJECT
library feature to structure the build of a library. The library is built
statically as well as dynamically. When building statically, there is no
problem in using the OBJECT libraries of CMake. But when building dynamically,
the problem described in my original e-mail arises. CMake's documentation does
not say that it is not allowed to use OBJECT libraries to compose shared
libraries.
Kind regards
Benjamin
>
> Regards,
> Andreas
>
> Am 22.06.2012 09:50, schrieb Benjamin Eikel:
> > Hello,
> >
> > I have a problem using an OBJECT library that I want to compile into a
> > SHARED library using CMake version 2.8.8.
> >
> > Here is a small example that demonstrates my problem:
> >
> > # --- CMakeLists.txt ---
> > cmake_minimum_required(VERSION 2.8.8)
> > project(CMakeTest CXX)
> > add_library(MyLibSub OBJECT
> >
> > ClassA.cpp
> >
> > )
> > add_library(MyLib SHARED
> >
> > $
> > ClassB.cpp
> >
> > )
> >
> > The content of the other four files is more or less irrelevant. To make
> > the example complete, I added them at the end of this e-mail.
> >
> > When I want to build this example, I get the following error:
> >
> > $ mkdir build&& cd build&& cmake ..&& make
> > -- The CXX compiler identification is GNU 4.7.0
> > -- 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
> > -- Configuring done
> > -- Generating done
> > -- Build files have been written to: /home/benjamin/Desktop/CMake
> > test/build Scanning dependencies of target MyLibSub
> > [ 50%] Building CXX object CMakeFiles/MyLibSub.dir/ClassA.cpp.o
> > [ 50%] Built target MyLibSub
> > Scanning dependencies of target MyLib
> > [100%] Building CXX object CMakeFiles/MyLib.dir/ClassB.cpp.o
> > Linking CXX shared library libMyLib.so
> > /usr/bin/ld: CMakeFiles/MyLibSub.dir/ClassA.cpp.o: relocation R_X86_64_32
> > against `.rodata' can not be used when making a shared object; recompile
> > with -fPIC
> > CMakeFiles/MyLibSub.dir/ClassA.cpp.o: could not read symbols: Bad value
> > collect2: error: ld returned 1 exit status
> > make[2]: *** [libMyLib.so] Error 1
> > make[1]: *** [CMakeFiles/MyLib.dir/all] Error 2
> > make: *** [all] Error 2
> >
> > When I add the line
> > set_target_properties(MyLibSub PROPERTIES COMPILE_FLAGS "-fPIC")
> > to the CMakeLists.txt, everything works fine. Am I doing something wrong?
> > Should CMake add "-fPIC" automatically in this case? Your feedback is
> > greatly appreciated.
> >
> > Kind regards
> > Benjamin
> >
> >
> >
> > // --- ClassA.cpp ---
> > #include "ClassA.h"
> > #include
> >
> > void ClassA::printName() {
> >
> > std::cout<< "ClassA"<< std::endl;
> >
> > }
> > // --- ClassA.h ---
> > #ifndef CLASSA_H
> > #define CLASSA_H
> >
> > struct ClassA {
> >
> > void printName();
> >
> > };
> >
> > #endif /* CLASSA_H */
> > // --- ClassB.cpp ---
> > #include "ClassB.h"
> > #include
> >
> > void ClassB::printName() {
> >
> > std::cout<< "ClassB"<< std::endl;
> > a.printName();
> >
> > }
> > // --- ClassB.h ---
> > #ifndef CLASSB_H
> > #define CLASSB_H
> >
> > #include "ClassA.h"
> >
> > struct ClassB {
> >
> > void printName();
> > ClassA a;
> >
> > };
> >
> > #endif /* CLASSB_H */
> >
> > --
> >
> > 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
>
> --
>
> 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
--
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] SHARED library containing OBJECT library: Missing -fPIC
Hello,
I have a problem using an OBJECT library that I want to compile into a SHARED
library using CMake version 2.8.8.
Here is a small example that demonstrates my problem:
# --- CMakeLists.txt ---
cmake_minimum_required(VERSION 2.8.8)
project(CMakeTest CXX)
add_library(MyLibSub OBJECT
ClassA.cpp
)
add_library(MyLib SHARED
$
ClassB.cpp
)
The content of the other four files is more or less irrelevant. To make the
example complete, I added them at the end of this e-mail.
When I want to build this example, I get the following error:
$ mkdir build && cd build && cmake .. && make
-- The CXX compiler identification is GNU 4.7.0
-- 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
-- Configuring done
-- Generating done
-- Build files have been written to: /home/benjamin/Desktop/CMake test/build
Scanning dependencies of target MyLibSub
[ 50%] Building CXX object CMakeFiles/MyLibSub.dir/ClassA.cpp.o
[ 50%] Built target MyLibSub
Scanning dependencies of target MyLib
[100%] Building CXX object CMakeFiles/MyLib.dir/ClassB.cpp.o
Linking CXX shared library libMyLib.so
/usr/bin/ld: CMakeFiles/MyLibSub.dir/ClassA.cpp.o: relocation R_X86_64_32
against `.rodata' can not be used when making a shared object; recompile with
-fPIC
CMakeFiles/MyLibSub.dir/ClassA.cpp.o: could not read symbols: Bad value
collect2: error: ld returned 1 exit status
make[2]: *** [libMyLib.so] Error 1
make[1]: *** [CMakeFiles/MyLib.dir/all] Error 2
make: *** [all] Error 2
When I add the line
set_target_properties(MyLibSub PROPERTIES COMPILE_FLAGS "-fPIC")
to the CMakeLists.txt, everything works fine. Am I doing something wrong?
Should CMake add "-fPIC" automatically in this case? Your feedback is greatly
appreciated.
Kind regards
Benjamin
// --- ClassA.cpp ---
#include "ClassA.h"
#include
void ClassA::printName() {
std::cout << "ClassA" << std::endl;
}
// --- ClassA.h ---
#ifndef CLASSA_H
#define CLASSA_H
struct ClassA {
void printName();
};
#endif /* CLASSA_H */
// --- ClassB.cpp ---
#include "ClassB.h"
#include
void ClassB::printName() {
std::cout << "ClassB" << std::endl;
a.printName();
}
// --- ClassB.h ---
#ifndef CLASSB_H
#define CLASSB_H
#include "ClassA.h"
struct ClassB {
void printName();
ClassA a;
};
#endif /* CLASSB_H */
--
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] Impossible to link SDLmain and LibXml2
Hello Julien, Am Dienstag, 6. März 2012 um 20:58:43 schrieb julien.plu@redaction- developpez.com: > Why ? I do something wrong in my CMakeList.txt ? You should use LIBXML2_LIBRARIES [1]. Kind regards Benjamin [1]http://cmake.org/cmake/help/cmake-2-8-docs.html#module:FindLibXml2 -- 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 do I use the ExternalProject module to compile only once
Hello, Am Donnerstag, 22. Dezember 2011, 14:58:15 schrieb Delcypher: > Apologies. There was a silly mistake in the version posted on > pastebin. Here is a corrected version http://pastebin.com/P95WNUP5 > > The problems I see with what I have written are: > > * The line "FIND_PACKAGE(ITK)" when FETCH_ITK is enabled is making > things go wrong because the ITK library hasn't been downloaded yet. > * Even if the above point wasn't a problem. When I run "cmake ../src/" > again this isn't going to create a makefile that does what I want. The > ITK library will downloaded all over again and then built. > > Any thoughts? maybe have a look at the KDE SuperBuild [1]. It uses a file called "ThisIsASourcePackage.valid" to determine if the build is done from a source package, or if the source has to be downloaded. Kind regards Benjamin [1] https://projects.kde.org/projects/kde/superbuild/repository/revisions/master/entry/SuperBuild.cmake > > Thanks, > Dan. > > On 22 December 2011 13:40, Delcypher wrote: > > Hi, > > > > I'm starting work on a project that depends on the ITK library and I'm > > using Arch Linux as my build platform. What I'd like to be able to do > > is the following. > > > > * When the following is run > > $ pwd > > /home/dan/project/build-dir > > $ cmake ../src/ > > > > for there to be a variable to be set it the cache (call it FETCH_ITK) > > that allows the user to pick between building the ITK library or try > > to use the system ITK library. Once the makefile is generated > > I would like this to happen when make is executed. > > > > - If the user picked to build the ITK library and it HAS NOT been built > > then the ExternalProject module is used to fetch and build ITK and then > > the rest of the project is built. > > > > -If the user picked to build ITK and it HAS already been built then my > > project is built WITHOUT attempting to rebuild the ITK library. With > > ITK_DIR set appropriately so that FIND_PACKAGE(ITK) works. > > > > -If the user picked to not build ITK then my project is built. With > > ITK_DIR not set to anything so that FIND_PACKAGE(ITK) works. > > > > I'm afraid I'm very new to cmake and I'm not quite sure how to do > > this. I made a start which can be seen here > > http://pastebin.com/xwiFPrY5 > > > > However it doesn't work. The ExternalProject() code seemed to work > > okay in isolation but when I added everything else it didn't work. > > > > Any suggestions? > > > > Thanks, > > Dan. > > -- > > 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 -- 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] hear hear
Hello Alexander, Am Montag, 19. Dezember 2011 um 21:19:04 schrieb Alexander Neundorf: > On Monday 19 December 2011, Benjamin Eikel wrote: > > Hello Alexander, > > > > Am Montag, 12. Dezember 2011, 21:51:54 schrieb Alexander Neundorf: > > > Here is an example which shows just that: > > > https://projects.kde.org/projects/kde/kdeexamples/repository/revisions/ > > > ma st er/show/buildsystem/HowToInstallALibrary > > > > > > It's not "final" yet, i.e. I'll work on improving it in the next weeks. > > > > thank you very much for this example project. It helped me a lot to > > understand especially the EXPORT usage. > > > > I know that you wrote that the project is not finished yet, but allow me > > to ask a question: > > > > In the "example/CMakeLists.txt": Is line 5, which calls > > "include(FindPackageHandleStandardArgs)", really needed? I think if > > BAR_FOUND would be checked, it should be called. > > Line 6 is commented out because it relies on a feature in cmake 2.8.3, but > when I committed the example I made it depend only on 2.6.4. > > Does that answer your question ? Yes, it's clear now. > > > I would greatly appreciate it if you could extend the example, or provide > > a second example, that uses an external library. So for example a > > library Foo depending on LibXml2. Some functionality of Foo depends on > > whether LibXml2 was found or not. Therefore it creates "Foo_Config.h" > > with > > "configure_file" defining something like LIB_XML2. I would like to see > > how this could be correctly installed and found by an application using > > Foo. Would it be simply adding the config header file to the set of > > exported header files? > > I'd put that information into the installed FooConfig.cmake, something > like: set(FOO_HAS_LIBXML2_FEATURES TRUE) Okay. Then it would be possible to set compile definitions depending on this variable. But it would only work for projects using CMake, too. The header file could be used by projects using any build system. Thank you! Kind regards Benjamin -- 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] hear hear
Hello Alexander, Am Montag, 12. Dezember 2011, 21:51:54 schrieb Alexander Neundorf: > Here is an example which shows just that: > https://projects.kde.org/projects/kde/kdeexamples/repository/revisions/mast > er/show/buildsystem/HowToInstallALibrary > > It's not "final" yet, i.e. I'll work on improving it in the next weeks. thank you very much for this example project. It helped me a lot to understand especially the EXPORT usage. I know that you wrote that the project is not finished yet, but allow me to ask a question: In the "example/CMakeLists.txt": Is line 5, which calls "include(FindPackageHandleStandardArgs)", really needed? I think if BAR_FOUND would be checked, it should be called. But in the current version only BAR_INCLUDES, BAR_LIBRARIES, and BAR_VERSION are used. These variables should be set by "BarConfig.cmake", shouldn't they? I would greatly appreciate it if you could extend the example, or provide a second example, that uses an external library. So for example a library Foo depending on LibXml2. Some functionality of Foo depends on whether LibXml2 was found or not. Therefore it creates "Foo_Config.h" with "configure_file" defining something like LIB_XML2. I would like to see how this could be correctly installed and found by an application using Foo. Would it be simply adding the config header file to the set of exported header files? Kind regards Benjamin Eikel -- 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] Dependencies and libraries..How does it work?
Hello,
Am Freitag, 17. Juni 2011, 11:40:15 schrieb David Springate:
> Hi Andreas,
>
> Thanks for another reply!
>
> My question therefore is:
> How can the cmake for MY_APP start the cmake for MY_LIB?
>
> I know how to get my app to link a library, and how to add the include
> directories for the lib - so that the app can compile - but how can it
> kick-start the build for MY_LIB so that the library is guaranteed to exist
> ready to be linked? I don't want to use an external script as I'd have to
> have one for each platform - going against the point of cmake, surely?
Let's say you have your library in the directory "mylib" below your
application. In this folder, you need a "CMakeLists.txt" file with a content
similar to this:
add_library(MyLib source1.cpp source2.cpp ...)
In the top level directory you need somthing like this in your
"CMakeLists.txt":
add_subdirectory("mylib")
add_executable(MyApp main.cpp app_source1.cpp ...)
target_link_libraries(MyApp MyLib)
I hope this works for you.
Kind regards,
Benjamin
>
> Thanks again for your help so far,
>
> David
>
> On 17 June 2011 10:22, Andreas Naumann wrote:
> > **
> > Hi,
> >
> > how should cmake find your MY_LIB-directory?
> > The simplest way, is to add the directory using
> > "add_subdirectory(MY_LIB_DIR ...)"
> >
> > If the MY_LIB-build directory is somewhere else, in a completely
> > different directory, you should think about your project structure.
> >
> > Andreas
> >
> > Am 17.06.2011 11:06, schrieb David Springate:
> >
> > Hi,
> >
> > Thanks for the reply - but I think you might have misunderstood my
> > question.
> >
> > I want to setup CMake so that when I call Cmake like so (for MY_APP):
> > mkdir build && cd build
> > cmake .. -G Xcode
> >
> > that the cmake call will be able to 'know' that it needs MY_LIB, find
> > where the MY_LIB CMakeLists.txt file is, build it, and then continue
> > with the cmake call for MY_APP.
> >
> > Any ideas?
> >
> > David
> >
> > On 17 June 2011 08:18, J.S. van Bethlehem
wrote:
> >> Hej David,
> >>
> >> >From your description I think all your build script needs to do is:
> >> mkdir build && cd build
> >> cmake ..
> >> make MY_APP
> >>
> >> Further, assuming your library also gets build with CMake, you probably
> >> have an add_directory(../MY_LIB ../MY_LIB) in your main lists-file
> >> (otherwise you should) and then the link_directories() command is not
> >> needed. I created sort of a 'standard' machinery for building a list of
> >> 'sub-packages' using CMake. It's not well documented and probably still
> >> has many issues, but I could mail it to you if you think it may help
> >> you get started and if you're interested.
> >>
> >> Greetsz,
> >> Jakob
> >>
> >> On 06/16/2011 11:54 PM, David Springate wrote:
> >>> Hi,
> >>>
> >>> I am new to CMake - and whilst I am immediately impressed with it's
> >>> relative ease of use - I have a 'noob' question, I'm sure!
> >>>
> >>> I have the following:
> >>> A library called MY_LIB that builds with a cmake command (I have
> >>> created a nice CMakeLists.txt file)
> >>> An application called MY_APP that builds a nice application - and even
> >>> links in MY_LIB using:
> >>> link_directories("../MY_LIB")
> >>> target_link_libraries(MY_APP MY_LIB)
> >>>
> >>> Now, first of all I know that I'm not supposed to use relative paths..
> >>> but we'll call a side issue.. (though I'd be happy to hear the correct
> >>> way of doing things!) - the real problem that I have is this:
> >>>
> >>> Give than MY_LIB is built using CMake and MY_APP is built using CMake..
> >>> how can I setup my build scripts so that I can call CMake once for
> >>> MY_APP, it'll realise that it needs MY_LIB, which hasn't yet been
> >>> built, invoke CMake for MY_LIB and then link itself with MY_APP?
> >>>
> >>> I ask because I use libraries heavily to organise my code (and reuse)
> >>> and would love to switch to CMake for all my building (XCode 4 has
> >>> forced my hand!) but I can't seem to figure this out.
> >>>
> >>> Please help a newcomer out - any help is greatly appreciated!
> >>>
> >>> Thanks,
> >>>
> >>> David
> >>
> >> ___
> >> 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
> >
> > --
> > David Springate
> > david.spring...@gmail.com
> >
> >
> > ___
> > 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/mail
Re: [CMake] Documentation suggestion
To answer myself: The problem could be that one has to write a parser. From [1]: 12. My favorite programming language is X. Can I still use doxygen? No, not as such; doxygen needs to understand the structure of what it reads. If you don't mind spending some time on it, there are several options: - If the grammar of X is close to C or C++, then it is probably not too hard to tweak src/scanner.l a bit so the language is supported. This is done for all other languages directly supported by doxygen (i.e. Java, IDL, C#, PHP). - If the grammar of X is somewhat different than you can write an input filter that translates X into something similar enough to C/C++ for doxygen to understand (this approach is taken for VB, Object Pascal, and Javascript, see http://www.stack.nl/~dimitri/doxygen/download.html#helpers). - If the grammar is completely different one could write a parser for X and write a backend that produces a similar syntax tree as is done by src/scanner.l (and also by src/tagreader.cpp while reading tag files). [1] http://www.stack.nl/~dimitri/doxygen/faq.html Am Montag, 2. Mai 2011, 16:41:52 schrieb Benjamin Eikel: > Hello, > > Am Montag, 2. Mai 2011, 16:37:45 schrieb David Cole: > > Good suggestion. > > > > We've also thought of that idea... > > > > Here's what we need to implement it: > > > > Do you have a good suggestion for how to represent links in the source > > code such that we can generated such linked documentation? > > what about Doxyen[1]? > > Kind regards, > Benjamin > > [1] http://www.stack.nl/~dimitri/doxygen/autolink.html > > > If it was easy, we would have done it already... > > > > If you do have a suggested technology to use, we're all ears. > > > > :-) > > > > David C. > > > > On Sun, May 1, 2011 at 4:28 PM, David Doria wrote: > > > On this page: > > > http://www.cmake.org/cmake/help/cmake-2-8-docs.html > > > > > > there are many "See XYZ" statements. E.g. > > > > > > - > > > else: Starts the else portion of an if block. > > > > > > else(expression) > > > > > > See the if command. > > > - > > > > > > It would be very helpful if these were linked to the anchor of that > > > command, e.g.: > > > > > > See the [if] command. > > > > > > David > > > ___ > > > 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 > > ___ > 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 ___ 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] Documentation suggestion
Hello, Am Montag, 2. Mai 2011, 16:37:45 schrieb David Cole: > Good suggestion. > > We've also thought of that idea... > > Here's what we need to implement it: > > Do you have a good suggestion for how to represent links in the source code > such that we can generated such linked documentation? what about Doxyen[1]? Kind regards, Benjamin [1] http://www.stack.nl/~dimitri/doxygen/autolink.html > > If it was easy, we would have done it already... > > If you do have a suggested technology to use, we're all ears. > > :-) > > David C. > > On Sun, May 1, 2011 at 4:28 PM, David Doria wrote: > > On this page: > > http://www.cmake.org/cmake/help/cmake-2-8-docs.html > > > > there are many "See XYZ" statements. E.g. > > > > - > > else: Starts the else portion of an if block. > > > > else(expression) > > > > See the if command. > > - > > > > It would be very helpful if these were linked to the anchor of that > > command, e.g.: > > > > See the [if] command. > > > > David > > ___ > > 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 ___ 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 fix requests for the *next* release of CMake...
Hello, I would like to see these bugs fixed: 0009930: Eclipse generator: enable parallel builds ? http://cmake.org/Bug/view.php?id=9930 0009968: Eclipse CDT Project File overwritten by '-G "Eclipse CDT4 - Unix Makefiles"' http://cmake.org/Bug/view.php?id=9968 Kind regards, Benjamin Am Donnerstag, 4. November 2010, 20:34:07 schrieb David Cole: > Hi all, > > Now that we have released CMake 2.8.3, *now* would be a great time to > prioritize bug fixes for the next release of CMake. > > Replies requested. Read on. *Just a short reply with bug numbers* or links > to the bugs is all we need here. Please move specific discussions into the > bugs themselves or start a new thread to talk about it... Replies on this > thread should just be a collector for bug numbers. > > We are aiming for quarterly releases from now on, scheduling them every 3 > or 4 months. That would make the next release of CMake version 2.8.4 and > scheduled to have an "rc1" release candidate in approximately mid-January, > 2011, target date: Wed. 1/12/2011. > > If you have a particular issue that you think should be fixed for inclusion > in 2.8.4, please bring it up now. Ideally, each issue will be discussed as > needed on the mailing list to come to any consensus about what should be > done to fix it, and then an entry in the bug tracker may be used to keep it > on the radar screen, and to track activity related to it. > > Patches are always welcome. Patches that include testing of any new > features, or tests that prove a bug is really fixed on the dashboards, > basically any patch with testing is preferred over a patch with no testing. > Also, if you are *adding* code, then you also probably need to add *tests* > of that code, so that the coverage percentage stays as is or rises. > > Please discuss issues here as needed, and add notes to existing issues in > the bug tracker that you are interested in seeing fixed for 2.8.4 -- we > will be looking at the mailing list and activity in the bug tracker to > help prioritize the bug fixes that will occur in the next several weeks. > > > Thanks, > David Cole > Kitware, Inc. > > > P.S. - as a nice summary of what we've accomplished in the CMake 2.8.3 > release, see here: http://public.kitware.com/Bug/changelog_page.php > -- it lists 89 issues that we resolved: nice job, everybody! > > (About 45 of those were specifically addressed because somebody brought it > up in response to my similar email from just after 2.8.2... Don't be shy!) signature.asc Description: This is a digitally signed message part. ___ 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] Quieting/speeding output
Hello, Am Sonntag, 11. Juli 2010, 17:40:58 schrieb Kevin Fitch: > I am transitioning from a make based build system to cmake, overall I am > quite happy with cmake, but currently there are two snags: > > 1) The main project I am doing this on is quite large, it produces about > 300 targets. So, when I type 'make' I get 300 or so lines of "[ 27%] Built > target blah..." even when there is nothing (or very little) to do. This is > quite annoying. I tried messing with CMAKE_RULE_MESSAGES. I just added > -DCMAKE_RULE_MESSAGES=OFF to the cmake invocation. But that didn't seem to > help. > > 2) The follow on to this is that a 'do-nothing' build still takes about 4 > seconds (or about 1.25 seconds for "make -j". The previous make based build > was effectively instantaneous for a 'do-nothing' build. The do-nothing (or > do very little) build is the common case so I hate to regress that far. > > Where should I be looking to address these issues? > > I suspect (2) is a result of cmake generating a recursive make system (as > opposed to the current make based system we have that uses recursive > includes, instead of recursive make calls). we are suffering from the same problem. When using a CMake-generated Eclipse project, a build is started every time you want to run your executable. When the build has been completed before, this 'do-nothing' build you mentioned is performed. Therefore for every launch you have to wait some seconds (depending on the project size and performance of the machine, happens for CMake and Eclipse on Linux and Windows) before the executable is really started. We would greatly appreciate a speed up of this 'do-nothing' build. Kind regards, Benjamin ___ 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] CMakeCache Files
Hello Mike, Am Mittwoch, 14. Juli 2010, 17:33:57 schrieb michael.schm...@l-3com.com: > I'm a newbie with cmake, and I wanted to clarify a couple things. From > what I understand, there's no command to clear CMakeCache files. If I the program cmake-gui has a menu option "Delete Cache". > add a new file or change the CMakeLists, then I have to delete the > CMakeCache files manually. If I change an option using ccmake, do I > have to remove the cache files before "generating"? I do not think that this is necessary. CMake should overwrite the according values. Kind regards, Benjamin ___ 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] Help getting my simple OpenGL project to use cmake
Hello Craig,
Am Donnerstag, 8. Juli 2010, 10:05:55 schrieb Craig Pemberton:
> In programs/
>
> include_directories(../library)
> #FILE(GLOB SOURCE_FILES .*.cpp)
> #FILE(GLOB INCLUDE_FILES *.h)
> #SOURCE_GROUP("Source Files" FILES ${SOURCE_FILES})
> #SOURCE_GROUP("Header Files" FILES ${HEADER_FILES})
> find_package(GLUT)
> find_package(OpenGL)
I think you are missing
include_directories(${GLUT_INCLUDE_DIR})
include_directories(${OPENGL_INCLUDE_DIR})
here.
> add_executable(lsystem lsystem.cpp ${GLUT_LIBRARY} ${OPENGL_LIBRARY})
> #set(PROGRAMS ifs lsystem raytrace subdivide)
> #set(CORELIBS ${GLUT_LIBRARY} ${OPENGL_LIBRARY} GL GLU)
> #foreach(programs ${PROGRAMS})
> # add_executable(${program} ${SOURCE_FILES} ${INCLUDE_FILES})
> #target_link_libraries(${program} ${CORELIBS})
> #endforeach(program)
>
Kind regards,
Benjamin
___
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] Project dependencies
Hello Alexander,
Am Montag, 19. April 2010 um 18:03:28 schrieb Alexander Neundorf:
> On Monday 19 April 2010, Benjamin Eikel wrote:
> > Hello Alexander,
> >
> > Am Sonntag, 18. April 2010 10:52:17 schrieb Alexander Neundorf:
> > > Hi Benjamin,
> > >
> > > On Friday 16 April 2010, Benjamin Eikel wrote:
> > > > Hello,
> > > >
> > > > maybe my first post was not clear enough.
> > > > I created a minimal example to demonstrate what I mean (see attached
> > > > files). That example contains a library called MyLib and a binary
> > > > called MyBin. The enclosed shell script can be used to build the
> > > > binary on Linux. At first the library will be configured such that
> > > > the file "MyLibConfig.cmake" will be created. After that the binary
> > > > will be configured and a build will be started. The build will fail
> > > > because the library was intentionally not build before. After that
> > > > another way of including the library is used. The second
> > > > "CMakeLists.txt" file uses add_subdirectory to reference the library.
> > >
> > > Yes, that's the normal way to do it.
> > >
> > > > When issuing a make command now,
> > > > the library will be built automatically. My question is if it is
> > > > possible to achieve this behavior when using the approach mentioned
> > > > first. This would make things easier in our projects when there are
> > > > multiple dependencies to different libraries which will be changed
> > > > often and a build of the binary should be triggered automatically.
> > >
> > > The normal and recommended way to to add all that (via
> > > add_subdirectory) into one CMake project. What is speaking against this
> > > in your case ?
> > >
> > > If you really want to have it separated, you may try how far you can
> > > get with externalproject_add(), but I would assume that the
> > > straightforward approach (add_subdirectory) will work much better.
> >
> > I think you are right.
> > But I still want to build the libraries on their own (because they are
> > used in some Hudson builds to check if the build works correctly).
> > Therefore a library libA depending on another library libB calls
> > find_package(libB) to find the needed files.
> > When using the add_subdirectory() approach I currently have the problem
> > that the find modules do not find the library libB (because it has not
> > been build yet). Is it the right way to integrate a check for the target
> > libB like the following into FindlibB.cmake?
> >
> > if(TARGET libB)
> > set(libB_LIBRARY Geometry)
> > else()
> > find_library(libB_LIBRARY
> > NAMES libB
> > HINTS ${libB_PKGCONF_LIBRARY_DIRS} [...]
> > PATH_SUFFIXES lib64 lib [...]
> > )
> > endif()
> >
> > This seems to work if I call add_subdirectory() in the correct order in
> > the top-level project.
>
> Yes, something like this can work.
I implemented it this way and it works like a charm. Thank you for your input.
Kind regards,
Benjamin
___
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] Project dependencies
Hello Alexander,
Am Sonntag, 18. April 2010 10:52:17 schrieb Alexander Neundorf:
> Hi Benjamin,
>
> On Friday 16 April 2010, Benjamin Eikel wrote:
> > Hello,
> >
> > maybe my first post was not clear enough.
> > I created a minimal example to demonstrate what I mean (see attached
> > files). That example contains a library called MyLib and a binary called
> > MyBin. The enclosed shell script can be used to build the binary on
> > Linux. At first the library will be configured such that the file
> > "MyLibConfig.cmake" will be created. After that the binary will be
> > configured and a build will be started. The build will fail because the
> > library was intentionally not build before. After that another way of
> > including the library is used. The second "CMakeLists.txt" file uses
> > add_subdirectory to reference the library.
>
> Yes, that's the normal way to do it.
>
> > When issuing a make command now,
> > the library will be built automatically. My question is if it is possible
> > to achieve this behavior when using the approach mentioned first. This
> > would make things easier in our projects when there are multiple
> > dependencies to different libraries which will be changed often and a
> > build of the binary should be triggered automatically.
>
> The normal and recommended way to to add all that (via add_subdirectory)
> into one CMake project. What is speaking against this in your case ?
>
> If you really want to have it separated, you may try how far you can get
> with externalproject_add(), but I would assume that the straightforward
> approach (add_subdirectory) will work much better.
I think you are right.
But I still want to build the libraries on their own (because they are used in
some Hudson builds to check if the build works correctly). Therefore a library
libA depending on another library libB calls find_package(libB) to find the
needed files.
When using the add_subdirectory() approach I currently have the problem that
the find modules do not find the library libB (because it has not been build
yet). Is it the right way to integrate a check for the target libB like the
following into FindlibB.cmake?
if(TARGET libB)
set(libB_LIBRARY Geometry)
else()
find_library(libB_LIBRARY
NAMES libB
HINTS ${libB_PKGCONF_LIBRARY_DIRS} [...]
PATH_SUFFIXES lib64 lib [...]
)
endif()
This seems to work if I call add_subdirectory() in the correct order in the
top-level project.
Kind regards,
Benjamin
___
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] Project dependencies
Hello, maybe my first post was not clear enough. I created a minimal example to demonstrate what I mean (see attached files). That example contains a library called MyLib and a binary called MyBin. The enclosed shell script can be used to build the binary on Linux. At first the library will be configured such that the file "MyLibConfig.cmake" will be created. After that the binary will be configured and a build will be started. The build will fail because the library was intentionally not build before. After that another way of including the library is used. The second "CMakeLists.txt" file uses add_subdirectory to reference the library. When issuing a make command now, the library will be built automatically. My question is if it is possible to achieve this behavior when using the approach mentioned first. This would make things easier in our projects when there are multiple dependencies to different libraries which will be changed often and a build of the binary should be triggered automatically. Kind regards, Benjamin Am Mittwoch, 14. April 2010 11:49:01 schrieb Benjamin Eikel: > Hello, > > we are using CMake to build different binaries which depend on some > libraries, that we develop ourselves. At the moment we export the settings > from the build directories of the libraries using export(... > lib-build.cmake ...). The CMakeLists.txt of a binary uses an own CMake > module using find_package(), in which we check for the "lib-build.cmake" > file. If it exists, it is included and the library variable is set to the > imported TARGET. Otherwise the library is searched with find_library and > used as dependency. > The build works without problems if the libraries are built first and the > binary afterwards. I am wondering if it is possible to trigger an automatic > build of the libraries when building the binary. For example the libraries > should be built if they have not been built yet or there have been changes > to the source files. > I think, if the library projects were integrated into the build using > add_subdirectory(), this will work. > Because we additionally let CMake generate Eclipse projects, it would be > nice if the library projects which are exported and imported by the binary > project, will be marked as references of the binary project (Project -> > Properties -> Project References). > For the record: We are using CMake in version 1.8.1 under GNU/Linux and > Windows. > > Kind regards, > Benjamin > ___ > 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_example.tar.gz Description: application/compressed-tar cmake_example.sh Description: application/shellscript ___ 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 dependencies
Hello, we are using CMake to build different binaries which depend on some libraries, that we develop ourselves. At the moment we export the settings from the build directories of the libraries using export(... lib-build.cmake ...). The CMakeLists.txt of a binary uses an own CMake module using find_package(), in which we check for the "lib-build.cmake" file. If it exists, it is included and the library variable is set to the imported TARGET. Otherwise the library is searched with find_library and used as dependency. The build works without problems if the libraries are built first and the binary afterwards. I am wondering if it is possible to trigger an automatic build of the libraries when building the binary. For example the libraries should be built if they have not been built yet or there have been changes to the source files. I think, if the library projects were integrated into the build using add_subdirectory(), this will work. Because we additionally let CMake generate Eclipse projects, it would be nice if the library projects which are exported and imported by the binary project, will be marked as references of the binary project (Project -> Properties -> Project References). For the record: We are using CMake in version 1.8.1 under GNU/Linux and Windows. Kind regards, Benjamin ___ 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
