I'm currently going through the process of installing the Qpid broker on Windows. I've already installed CMake, boost, and python and I've added the environment variable for the root of the Boost directory. I'm now at the step where Qpid client is to be build from a source distribution (Visual Studio 12). After having changed into the directory qpid\cpp I ran the command: cmake -G "Visual Studio 12 2013". Toward the end of the log, I got the error:
CMake Error at CMakeLists.txt:73 (install):
install FILES given no DESTINATION!
So I checked the CMakeLists.txt file and saw that lines 73 - 76 have:
install (FILES ${CMAKE_CURRENT_SOURCE_DIR}/README.txt
DESTINATION ${QPID_INSTALL_EXAMPLESDIR}
COMPONENT ${QPID_COMPONENT_EXAMPLES})
I think the problem could be related to the fact that EXAMPLESDIR is being used but the INSTALL_WINDOWS text file instructs you to go into the cpp directory which is located in examples (the full path is: qpid-cpp-0.34/bindings/qmf2/examples/cpp/)
This is the first time I've had to work with qpid or messaging brokers so I have a limited understanding of what's going on here. What destination should I be providing for the install files?
The CMakeLists.txt file is below for reference:
#
# Licensed to the Apache Software Foundation (ASF) under one
# or more contributor license agreements. See the NOTICE file
# distributed with this work for additional information
# regarding copyright ownership. The ASF licenses this file
# to you under the Apache License, Version 2.0 (the
# "License"); you may not use this file except in compliance
# with the License. You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing,
# software distributed under the License is distributed on an
# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
# KIND, either express or implied. See the License for the
# specific language governing permissions and limitations
# under the License.
#
project(qmf2_examples)
cmake_minimum_required(VERSION 2.4.0 FATAL_ERROR)
if(COMMAND cmake_policy)
cmake_policy(SET CMP0003 NEW)
endif(COMMAND cmake_policy)
include_directories(${CMAKE_BINARY_DIR}/include)
include_directories(${CMAKE_SOURCE_DIR}/include)
# Shouldn't need this... but there are still client header inclusions
# of Boost. When building examples at an install site, the Boost files
# should be locatable aside from these settings.
# So set up to find the headers, find the libs at link time, but dynamically
# link them all and clear the CMake Boost library names to avoid adding them to
# the project files.
include_directories( ${Boost_INCLUDE_DIR} )
link_directories( ${Boost_LIBRARY_DIRS} )
# Visual Studio needs some Windows-specific simplifications.
if (MSVC)
add_definitions( /D "NOMINMAX" /D "WIN32_LEAN_AND_MEAN" /D "BOOST_ALL_DYN_LINK" )
# On Windows, prevent the accidental inclusion of Boost headers from
# autolinking in the Boost libs. There should be no direct references to
# Boost in the examples, and references via qpidclient/qpidcommon are
# resolved in the Qpid libs.
add_definitions( /D "BOOST_ALL_NO_LIB" )
endif (MSVC)
# There are numerous duplicate names within the examples. Since all target
# names must be unique, define a macro to prepend a prefix and manage the
# actual names.
# There can be an optional arguments at the end: libs to include
macro(add_example subdir example)
add_executable(${subdir}_${example} ${example}.cpp)
set_target_properties(${subdir}_${example} PROPERTIES OUTPUT_NAME ${example})
if (${ARGC} GREATER 2)
target_link_libraries(${subdir}_${example} ${ARGN} qpidmessaging qpidtypes
${_boost_libs_needed})
else (${ARGC} GREATER 2)
target_link_libraries(${subdir}_${example} qpidmessaging qpidtypes
${_boost_libs_needed})
endif (${ARGC} GREATER 2)
endmacro(add_example)
macro(add_installed_example subdir example)
add_example(${subdir} ${example} ${ARGN})
# For installs, don't install the built example; that would be pointless.
# Install the things a user needs to build the example on-site.
install (FILES ${CMAKE_CURRENT_SOURCE_DIR}/${example}.cpp
DESTINATION ${QPID_INSTALL_EXAMPLESDIR}/${subdir}
COMPONENT ${QPID_COMPONENT_EXAMPLES})
endmacro(add_installed_example)
install (FILES ${CMAKE_CURRENT_SOURCE_DIR}/README.txt
DESTINATION ${QPID_INSTALL_EXAMPLESDIR}
COMPONENT ${QPID_COMPONENT_EXAMPLES})
add_installed_example(qmf2 agent qmf2)
if (NOT WIN32)
# uses posix select()
add_installed_example(qmf2 event_driven_list_agents qmf2)
endif (NOT WIN32)
add_installed_example(qmf2 list_agents qmf2)
add_installed_example(qmf2 print_events qmf2)
Related
I need to find the HDF4 library for a CMake build.
I have a FindHDF4.cmake which finds HDF4 if it was installed by CMake. But usually HDF4 isn't installed with CMake. Usually it is installed with autotools, the standard GNU install pacakge.
Does anyone have a FindHDF4.cmake which works on all HDF4 installs? (Including installs of HDF4 in which cmake was not used - i.e. installs with configure/make instead of installs with cmake.)
Here is the FindHDF4 script that I have:
#
# To be used by projects that make use of CMakeified hdf-4.2.5
#
#
# Find the HDF4 includes and get all installed hdf4 library settings from
# HDF4-config.cmake file : Requires a CMake compatible hdf-4.2.6 or later
# for this feature to work. The following vars are set if hdf4 is found.
#
# HDF4_FOUND - True if found, otherwise all other vars are undefined
# HDF4_INCLUDE_DIR - The include dir for main *.h files
# HDF4_FORTRAN_INCLUDE_DIR - The include dir for fortran modules and headers
# HDF4_VERSION_STRING - full version (e.g. 4.2.5)
# HDF4_VERSION_MAJOR - major part of version (e.g. 4.2)
# HDF4_VERSION_MINOR - minor part (e.g. 5)
#
# The following boolean vars will be defined
# HDF4_ENABLE_PARALLEL - 1 if HDF4 parallel supported
# HDF4_BUILD_FORTRAN - 1 if HDF4 was compiled with fortran on
# HDF4_BUILD_CPP_LIB - 1 if HDF4 was compiled with cpp on
# HDF4_BUILD_TOOLS - 1 if HDF4 was compiled with tools on
#
# Target names that are valid (depending on enabled options)
# will be the following
#
# hdf : HDF4 C library
# hdf_f90cstub : used by Fortran to C interface
# hdf_fortran : Fortran HDF4 library
# mfhdf : HDF4 multi-file C interface library
# xdr : RPC library
# mfhdf_f90cstub : used by Fortran to C interface to multi-file library
# mfhdf_fortran : Fortran multi-file library
#
# To aid in finding HDF4 as part of a subproject set
# HDF4_ROOT_DIR_HINT to the location where hdf4-config.cmake lies
INCLUDE (SelectLibraryConfigurations)
INCLUDE (FindPackageHandleStandardArgs)
# The HINTS option should only be used for values computed from the system.
SET (_HDF4_HINTS
$ENV{HOME}/.local
$ENV{HDF4_ROOT}
$ENV{HDF4_ROOT_DIR_HINT}
)
# Hard-coded guesses should still go in PATHS. This ensures that the user
# environment can always override hard guesses.
SET (_HDF4_PATHS
$ENV{HOME}/.local
$ENV{HDF4_ROOT}
$ENV{HDF4_ROOT_DIR_HINT}
/usr/lib/hdf
/usr/share/hdf
/usr/local/hdf
/usr/local/hdf/share
)
FIND_PATH (HDF4_ROOT_DIR "hdf4-config.cmake"
HINTS ${_HDF4_HINTS}
PATHS ${_HDF4_PATHS}
PATH_SUFFIXES
lib/cmake/hdf4
share/cmake/hdf4
)
FIND_PATH (HDF4_INCLUDE_DIRS "hdf.h"
HINTS ${_HDF4_HINTS}
PATHS ${_HDF4_PATHS}
PATH_SUFFIXES
include
Include
)
# For backwards compatibility we set HDF4_INCLUDE_DIR to the value of
# HDF4_INCLUDE_DIRS
SET ( HDF4_INCLUDE_DIR "${HDF4_INCLUDE_DIRS}" )
IF (HDF4_INCLUDE_DIR)
INCLUDE (${HDF4_ROOT_DIR}/hdf4-config.cmake)
ENDIF (HDF4_INCLUDE_DIR)
# handle the QUIETLY and REQUIRED arguments and set HDF4_FOUND to TRUE if
# all listed variables are TRUE
INCLUDE(FindPackageHandleStandardArgs)
FIND_PACKAGE_HANDLE_STANDARD_ARGS(HDF4 REQUIRED_VARS HDF4_LIBRARIES HDF4_INCLUDE_DIRS)
General problem:
I get absolute paths in my INTERFACE_LINK_LIBRARIES and INTERFACE_INCLUDE_DIRECTORIES properties for a target, which is a problem because these variables get exported via the install(EXPORT), which will mean trouble if anything is relocated. I traced the origin of these absolute paths back to the find_package command, which (for some but not all packages) sets variables like Boost_LIBRARIES with absolute paths. When they are used with e.g. the target_link_libraries command, they end up in the INTERFACE_LINK_LIBRARIES.
Q: How do I best avoid the exported target properties from being poluted with absolute paths?
The trivial solution is obviously to just overwrite the respective variables with some strings that only name the libraries (hardcoded), but I guess there should be a better way.
Specific problem (Example): see https://github.com/cartographer-project/cartographer/issues/1688
EDIT:
My (modified) cartographer-config.cmake.in
(note: you can ignore the stuff associated to ceres, since that does not give me trouble, eventhough it places an abs path in the hint):
# Copyright 2016 The Cartographer Authors
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
# Usage from an external project:
# In your CMakeLists.txt, add these lines:
#
# find_package(cartographer REQUIRED)
# target_link_libraries(MY_TARGET_NAME PUBLIC cartographer)
#PACKAGE_INIT#
set_and_check(CARTOGRAPHER_CMAKE_DIR "#PACKAGE_CARTOGRAPHER_CMAKE_DIR#")
find_dependency(Boost)
find_dependency(Lua)
set(CERES_DIR_HINTS #Ceres_DIR#)
if (cartographer_FIND_QUIETLY)
find_package(Ceres QUIET HINTS ${CERES_DIR_HINTS})
elseif (cartographer_FIND_REQUIRED)
find_package(Ceres REQUIRED HINTS ${CERES_DIR_HINTS})
else ()
find_package(Ceres HINTS ${CERES_DIR_HINTS})
endif()
include("${CARTOGRAPHER_CMAKE_DIR}/CartographerTargets.cmake")
How do I best avoid the exported target properties from being poluted with absolute paths?
Hide absolute paths behind the IMPORTED target:
# Express an external library via IMPORTED target
add_library(lib_external IMPORTED)
set_target_properties(lib_external PROPERTIES
IMPORTED_LOCATION "${XXX_LIBRARY} (some absolute path)"
INTERFACE_INCLUDE_DIRECTORIES "${XXX_INCLUDE_DIRECTORIES} (some absolute path)"
)
# Use external library via the target created
target_link_libraries(my_lib lib_external)
Such way, the config file for my_lib will contain only the name of the IMPORTED library, but not its properties.
In the config file for your project you just need to create IMPORTED target with the same name and fill its properties according to the current machine (where your project is used).
find_package for most of modern packages (including Boost) already returns an IMPORTED target. In the configuration file for your project you may use find_dependency, which discovers the package on the current machine and creates an IMPORTED target again.
For old packages, which find_package just returns XXX_LIBRARIES and XXX_INCLUDE_DIRECTORIES variables, you may create the IMPORTED target manually. In the configuration file for your project you may use find_dependency too, and again create IMPORTED target manually.
When use find_dependency macro, remember to pass the same parameters which you have passed to the find_package() in the project's CMakeLists.txt. This is primary about COMPONENTS parameter and variables like Boost_USE_STATIC_LIBS, which affects on the package searching.
If you want to specify VERSION requirement, then this requirement should express binary compatibility of the library on the target machine with the library against which the project has been actually built.
HINST and PATHS options for find_package are unlikely needed to be transferred to the find_dependency: call to the find_dependency is processed on the target machine, which paths could be different from ones on the build machine.
I declare that I have never worked with the autoconf tool.
Now I'm migrating a small project from autoconf to cmake, and I ran into the AC_SYS_LARGEFILE. I have not understood much about AC_SYS_LARGEFILE except that it is a kind of check to understand if for example off_t is 4 or 8 bytes.
Out of curiosity, I would like to understand which are the typical use cases of AC_SYS_LARGEFILE.
Coming to the real question, do I still need AC_SYS_LARGEFILE for CMake?
If yes, does a mechanism already exist in CMake or should I implement it myself?
You are almost correct. The AC_SYS_LARGEFILE autoconf macro enables large-file support (8-byte file offsets) for the program. With some compilers, additional compiler definitions must also be defined to work with large files.
As far as I know, there is not currently any support for this native to CMake. However, there are some CMake projects that have created their own solutions; see these files in the WireShark and the OpenJPEG repositories. The code in each of these appears to be adapted from the Gromacs Project.
For completeness, here is the WireShark CMake file, showing how to test the need for large file support in your program:
# This code was copied from http://www.gromacs.org/
# and its toplevel COPYING file starts with:
#
# GROMACS is free software, distributed under the GNU General Public License
# (GPL) Version 2.
# - Define macro to check large file support
#
# GMX_TEST_LARGE_FILES(VARIABLE)
#
# VARIABLE will be set to true if 64-bit file support is available.
# This macro will also set defines as necessary to enable large file
# support, for instance:
# _LARGE_FILES
# _LARGEFILE_SOURCE
# _FILE_OFFSET_BITS=64
#
# However, it is YOUR job to make sure these defines are set in a cmakedefine so they
# end up in a config.h file that is included in your source if necessary!
MACRO(GMX_TEST_LARGE_FILES VARIABLE)
IF(NOT DEFINED ${VARIABLE})
if(CMAKE_C_COMPILER_ID MATCHES "MSVC")
#
# This is Visual Studio; Visual Studio has supported
# _fseeki64 and _ftelli64 since Visual Studio 2005 / MSVCR80,
# and we require newer versions, so we know we have them.
#
MESSAGE(STATUS "_fseeki64 and _ftelli64 are present")
else(CMAKE_C_COMPILER_ID MATCHES "MSVC")
#
# This is UN*X, or some other Windows compiler.
#
# For UN*X, we do the Large File Support tests, to see
# whether it's present and, if so what we need to define
# to enable it.
#
# XXX - what's the right thing to do on Windows with,
# for example, MinGW?
#
# On most platforms it is probably overkill to first test
# the flags for 64-bit off_t, and then separately fseeko.
# However, in the future we might have 128-bit seek offsets
# to support 128-bit filesystems that allow 128-bit offsets
# (ZFS), so it might be dangerous to indiscriminately set
# e.g. _FILE_OFFSET_BITS=64.
#
MESSAGE(STATUS "Checking for 64-bit off_t")
# First check without any special flags
TRY_COMPILE(FILE64_OK "${CMAKE_BINARY_DIR}"
"${CMAKE_SOURCE_DIR}/cmake/TestFileOffsetBits.c")
if(FILE64_OK)
MESSAGE(STATUS "64-bit off_t is present with no special flags")
endif(FILE64_OK)
if(NOT FILE64_OK)
# Test with _FILE_OFFSET_BITS=64
TRY_COMPILE(FILE64_OK "${CMAKE_BINARY_DIR}"
"${CMAKE_SOURCE_DIR}/cmake/TestFileOffsetBits.c"
COMPILE_DEFINITIONS "-D_FILE_OFFSET_BITS=64" )
if(FILE64_OK)
MESSAGE(STATUS "64-bit off_t is present with _FILE_OFFSET_BITS=64")
set(_FILE_OFFSET_BITS 64 CACHE INTERNAL "64-bit off_t requires _FILE_OFFSET_BITS=64")
endif(FILE64_OK)
endif(NOT FILE64_OK)
if(NOT FILE64_OK)
# Test with _LARGE_FILES
TRY_COMPILE(FILE64_OK "${CMAKE_BINARY_DIR}"
"${CMAKE_SOURCE_DIR}/cmake/TestFileOffsetBits.c"
COMPILE_DEFINITIONS "-D_LARGE_FILES" )
if(FILE64_OK)
MESSAGE(STATUS "64-bit off_t is present with _LARGE_FILES")
set(_LARGE_FILES 1 CACHE INTERNAL "64-bit off_t requires _LARGE_FILES")
endif(FILE64_OK)
endif(NOT FILE64_OK)
if(NOT FILE64_OK)
# Test with _LARGEFILE_SOURCE
TRY_COMPILE(FILE64_OK "${CMAKE_BINARY_DIR}"
"${CMAKE_SOURCE_DIR}/cmake/TestFileOffsetBits.c"
COMPILE_DEFINITIONS "-D_LARGEFILE_SOURCE" )
if(FILE64_OK)
MESSAGE(STATUS "64-bit off_t is present with _LARGEFILE_SOURCE")
set(_LARGEFILE_SOURCE 1 CACHE INTERNAL "64-bit off_t requires _LARGEFILE_SOURCE")
endif(FILE64_OK)
endif(NOT FILE64_OK)
if(NOT FILE64_OK)
MESSAGE(STATUS "64-bit file offset support not available")
else(NOT FILE64_OK)
# Set the flags we might have determined to be required above
configure_file("${CMAKE_SOURCE_DIR}/cmake/TestLargeFiles.c.cmakein"
"${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/TestLargeFiles.c")
#
# If this is Windows, assume we have _fseeki64/_ftelli64
# available. If this is UN*X, check for fseeko/ftello.
#
if(NOT WIN32)
MESSAGE(STATUS "Checking for fseeko/ftello")
# Test if ftello/fseeko are available
TRY_COMPILE(FSEEKO_COMPILE_OK "${CMAKE_BINARY_DIR}"
"${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/TestLargeFiles.c")
if(FSEEKO_COMPILE_OK)
MESSAGE(STATUS "Checking for fseeko/ftello - present")
endif(FSEEKO_COMPILE_OK)
if(NOT FSEEKO_COMPILE_OK)
# glibc 2.2 neds _LARGEFILE_SOURCE for fseeko (but not 64-bit off_t...)
TRY_COMPILE(FSEEKO_COMPILE_OK "${CMAKE_BINARY_DIR}"
"${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/TestLargeFiles.c"
COMPILE_DEFINITIONS "-D_LARGEFILE_SOURCE" )
if(FSEEKO_COMPILE_OK)
MESSAGE(STATUS "Checking for fseeko/ftello - present with _LARGEFILE_SOURCE")
set(_LARGEFILE_SOURCE 1 CACHE INTERNAL "64-bit fseeko requires _LARGEFILE_SOURCE")
endif(FSEEKO_COMPILE_OK)
endif(NOT FSEEKO_COMPILE_OK)
if(FSEEKO_COMPILE_OK)
SET(${VARIABLE} 1 CACHE INTERNAL "Result of test for large file support" FORCE)
set(HAVE_FSEEKO 1 CACHE INTERNAL "64-bit fseeko is available" FORCE)
else(FSEEKO_COMPILE_OK)
MESSAGE(STATUS "Checking for fseeko/ftello - not found")
SET(${VARIABLE} 0 CACHE INTERNAL "Result of test for large file support" FORCE)
endif(FSEEKO_COMPILE_OK)
endif(NOT WIN32)
endif(NOT FILE64_OK)
endif(CMAKE_C_COMPILER_ID MATCHES "MSVC")
ENDIF(NOT DEFINED ${VARIABLE})
ENDMACRO(GMX_TEST_LARGE_FILES VARIABLE)
I'm getting this strange error while trying to build a SDL demo project in CLion.
"C:\Program Files (x86)\JetBrains\CLion 2016.1.3\bin\cmake\bin\cmake.exe" --build C:\Users\****\.CLion2016.1\system\cmake\generated\teste-62957c9d\62957c9d\Debug --target teste -- -j 4
mingw32-make.exe[3]: *** No rule to make target 'C:/Windows/System32/SDL2.dll', needed by 'teste.exe'. Stop.
CMakeFiles\Makefile2:66: recipe for target 'CMakeFiles/teste.dir/all' failed
mingw32-make.exe[2]: *** [CMakeFiles/teste.dir/all] Error 2
mingw32-make.exe[1]: *** [CMakeFiles/teste.dir/rule] Error 2
mingw32-make.exe: *** [teste] Error 2
CMakeFiles\Makefile2:78: recipe for target 'CMakeFiles/teste.dir/rule' failed
Makefile:117: recipe for target 'teste' failed
I've tried googling but I didn't find any answer or similar errors relating SDL and mingw. What could be the problem?
I don't know if its of any help, but here is my CMakeLists file:
cmake_minimum_required(VERSION 3.5)
project(teste)
set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} "${PROJECT_SOURCE_DIR}/cmake")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")
find_package(SDL2 REQUIRED)
include_directories(${SDL2_INCLUDE_DIR})
set(SOURCE_FILES main.cpp)
add_executable(teste ${SOURCE_FILES})
target_link_libraries(teste ${SDL2_LIBRARY})
and an auxiliary .cmake file I use to find SDL2 in my system:
# Locate SDL2 library
# This module defines
# SDL2_LIBRARY, the name of the library to link against
# SDL2_FOUND, if false, do not try to link to SDL2
# SDL2_INCLUDE_DIR, where to find SDL.h
#
# 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_LIBRARY variable.
#
# Don't forget to include SDL2main.h and SDL2main.m your project for the
# OS X framework based version. (Other versions link to -lSDL2main which
# this module will try to find on your behalf.) Also for OS X, this
# module will automatically add the -framework Cocoa on your behalf.
#
#
# Additional Note: If you see an empty SDL2_LIBRARY_TEMP in your configuration
# and no SDL2_LIBRARY, it means CMake did not find your SDL2 library
# (SDL2.dll, libsdl2.so, SDL2.framework, etc).
# Set SDL2_LIBRARY_TEMP to point to your SDL2 library, and configure again.
# Similarly, if you see an empty SDL2MAIN_LIBRARY, you should set this value
# as appropriate. These values are used to generate the final SDL2_LIBRARY
# variable, but when these values are unset, SDL2_LIBRARY does not get created.
#
#
# $SDL2 is an environment variable that would
# correspond to the ./configure --prefix=$SDL2
# used in building SDL2.
# l.e.galup 9-20-02
#
# Modified by Eric Wing.
# Added code to assist with automated building by using environmental variables
# and providing a more controlled/consistent search behavior.
# Added new modifications to recognize OS X frameworks and
# additional Unix paths (FreeBSD, etc).
# Also corrected the header search path to follow "proper" SDL2 guidelines.
# Added a search for SDL2main which is needed by some platforms.
# Added a search for threads which is needed by some platforms.
# Added needed compile switches for MinGW.
#
# On OSX, this will prefer the Framework version (if found) over others.
# People will have to manually change the cache values of
# SDL2_LIBRARY to override this selection or set the CMake environment
# CMAKE_INCLUDE_PATH to modify the search paths.
#
# Note that the header path has changed from SDL2/SDL.h to just SDL.h
# This needed to change because "proper" SDL2 convention
# is #include "SDL.h", not <SDL2/SDL.h>. This is done for portability
# reasons because not all systems place things in SDL2/ (see FreeBSD).
#
# Ported by Johnny Patterson. This is a literal port for SDL2 of the FindSDL.cmake
# module with the minor edit of changing "SDL" to "SDL2" where necessary. This
# was not created for redistribution, and exists temporarily pending official
# SDL2 CMake modules.
#
# Note that on windows this will only search for the 32bit libraries, to search
# for 64bit change x86/i686-w64 to x64/x86_64-w64
#=============================================================================
# Copyright 2003-2009 Kitware, Inc.
#
# CMake - Cross Platform Makefile Generator
# Copyright 2000-2014 Kitware, Inc.
# Copyright 2000-2011 Insight Software Consortium
# All rights reserved.
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions
# are met:
#
# * Redistributions of source code must retain the above copyright
# notice, this list of conditions and the following disclaimer.
#
# * Redistributions in binary form must reproduce the above copyright
# notice, this list of conditions and the following disclaimer in the
# documentation and/or other materials provided with the distribution.
#
# * Neither the names of Kitware, Inc., the Insight Software Consortium,
# nor the names of their contributors may be used to endorse or promote
# products derived from this software without specific prior written
# permission.
#
# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
# HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
#
# 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_PATH(SDL2_INCLUDE_DIR SDL.h
HINTS
${SDL2}
$ENV{SDL2}
PATH_SUFFIXES include/SDL2 include SDL2
i686-w64-mingw32/include/SDL2
x86_64-w64-mingw32/include/SDL2
PATHS
~/Library/Frameworks
/Library/Frameworks
/usr/local/include/SDL2
/usr/include/SDL2
/sw # Fink
/opt/local # DarwinPorts
/opt/csw # Blastwave
/opt
)
# Lookup the 64 bit libs on x64
IF(CMAKE_SIZEOF_VOID_P EQUAL 8)
FIND_LIBRARY(SDL2_LIBRARY_TEMP SDL2
HINTS
${SDL2}
$ENV{SDL2}
PATH_SUFFIXES lib64 lib
lib/x64
x86_64-w64-mingw32/lib
PATHS
/sw
/opt/local
/opt/csw
/opt
)
# On 32bit build find the 32bit libs
ELSE(CMAKE_SIZEOF_VOID_P EQUAL 8)
FIND_LIBRARY(SDL2_LIBRARY_TEMP SDL2
HINTS
${SDL2}
$ENV{SDL2}
PATH_SUFFIXES lib
lib/x86
i686-w64-mingw32/lib
PATHS
/sw
/opt/local
/opt/csw
/opt
)
ENDIF(CMAKE_SIZEOF_VOID_P EQUAL 8)
IF(NOT SDL2_BUILDING_LIBRARY)
IF(NOT ${SDL2_INCLUDE_DIR} MATCHES ".framework")
# Non-OS X framework versions expect you to also dynamically link to
# SDL2main. This is mainly for Windows and OS X. Other (Unix) platforms
# seem to provide SDL2main for compatibility even though they don't
# necessarily need it.
# Lookup the 64 bit libs on x64
IF(CMAKE_SIZEOF_VOID_P EQUAL 8)
FIND_LIBRARY(SDL2MAIN_LIBRARY
NAMES SDL2main
HINTS
${SDL2}
$ENV{SDL2}
PATH_SUFFIXES lib64 lib
lib/x64
x86_64-w64-mingw32/lib
PATHS
/sw
/opt/local
/opt/csw
/opt
)
# On 32bit build find the 32bit libs
ELSE(CMAKE_SIZEOF_VOID_P EQUAL 8)
FIND_LIBRARY(SDL2MAIN_LIBRARY
NAMES SDL2main
HINTS
${SDL2}
$ENV{SDL2}
PATH_SUFFIXES lib
lib/x86
i686-w64-mingw32/lib
PATHS
/sw
/opt/local
/opt/csw
/opt
)
ENDIF(CMAKE_SIZEOF_VOID_P EQUAL 8)
ENDIF(NOT ${SDL2_INCLUDE_DIR} MATCHES ".framework")
ENDIF(NOT SDL2_BUILDING_LIBRARY)
# SDL2 may require threads on your system.
# The Apple build may not need an explicit flag because one of the
# frameworks may already provide it.
# But for non-OSX systems, I will use the CMake Threads package.
IF(NOT APPLE)
FIND_PACKAGE(Threads)
ENDIF(NOT APPLE)
# MinGW needs an additional library, mwindows
# It's total link flags should look like -lmingw32 -lSDL2main -lSDL2 -lmwindows
# (Actually on second look, I think it only needs one of the m* libraries.)
IF(MINGW)
SET(MINGW32_LIBRARY mingw32 CACHE STRING "mwindows for MinGW")
ENDIF(MINGW)
SET(SDL2_FOUND "NO")
IF(SDL2_LIBRARY_TEMP)
# For SDL2main
IF(NOT SDL2_BUILDING_LIBRARY)
IF(SDL2MAIN_LIBRARY)
SET(SDL2_LIBRARY_TEMP ${SDL2MAIN_LIBRARY} ${SDL2_LIBRARY_TEMP})
ENDIF(SDL2MAIN_LIBRARY)
ENDIF(NOT SDL2_BUILDING_LIBRARY)
# For OS X, SDL2 uses Cocoa as a backend so it must link to Cocoa.
# CMake doesn't display the -framework Cocoa string in the UI even
# though it actually is there if I modify a pre-used variable.
# I think it has something to do with the CACHE STRING.
# So I use a temporary variable until the end so I can set the
# "real" variable in one-shot.
IF(APPLE)
SET(SDL2_LIBRARY_TEMP ${SDL2_LIBRARY_TEMP} "-framework Cocoa")
ENDIF(APPLE)
# For threads, as mentioned Apple doesn't need this.
# In fact, there seems to be a problem if I used the Threads package
# and try using this line, so I'm just skipping it entirely for OS X.
IF(NOT APPLE)
SET(SDL2_LIBRARY_TEMP ${SDL2_LIBRARY_TEMP} ${CMAKE_THREAD_LIBS_INIT})
ENDIF(NOT APPLE)
# For MinGW library
IF(MINGW)
SET(SDL2_LIBRARY_TEMP ${MINGW32_LIBRARY} ${SDL2_LIBRARY_TEMP})
ENDIF(MINGW)
# Set the final string here so the GUI reflects the final state.
SET(SDL2_LIBRARY ${SDL2_LIBRARY_TEMP} CACHE STRING "Where the SDL2 Library can be found")
# Set the temp variable to INTERNAL so it is not seen in the CMake GUI
SET(SDL2_LIBRARY_TEMP "${SDL2_LIBRARY_TEMP}" CACHE INTERNAL "")
SET(SDL2_FOUND "YES")
ENDIF(SDL2_LIBRARY_TEMP)
INCLUDE(FindPackageHandleStandardArgs)
FIND_PACKAGE_HANDLE_STANDARD_ARGS(SDL2 REQUIRED_VARS SDL2_LIBRARY SDL2_INCLUDE_DIR)
Update
After a reconfiguration of the project, as #Tsyvarev pointed out, the error was gone and now I have this undefined reference to SDL_main errors:
C:/SDL2/i686-w64-mingw32/lib/libSDL2main.a(SDL_windows_main.o): In function `main_utf8':
/Users/slouken/release/SDL/SDL2-2.0.4-source/foo-x86/../src/main/windows/SDL_windows_main.c:126: undefined reference to `SDL_main'
/Users/slouken/release/SDL/SDL2-2.0.4-source/foo-x86/../src/main/windows/SDL_windows_main.c:126: undefined reference to `SDL_main'
/Users/slouken/release/SDL/SDL2-2.0.4-source/foo-x86/../src/main/windows/SDL_windows_main.c:126: undefined reference to `SDL_main'
collect2.exe: error: ld returned 1 exit status
mingw32-make.exe[3]: *** [SDLDemo.exe] Error 1
mingw32-make.exe[2]: *** [CMakeFiles/SDLDemo.dir/all] Error 2
CMakeFiles\SDLDemo.dir\build.make:98: recipe for target 'SDLDemo.exe' failed
CMakeFiles\Makefile2:66: recipe for target 'CMakeFiles/SDLDemo.dir/all' failed
mingw32-make.exe[1]: *** [CMakeFiles/SDLDemo.dir/rule] Error 2
mingw32-make.exe: *** [SDLDemo] Error 2
CMakeFiles\Makefile2:78: recipe for target 'CMakeFiles/SDLDemo.dir/rule' failed
Makefile:117: recipe for target 'SDLDemo' failed
Update 2:
A simple change from int main(){...} to int main(int argc, char *argv[]){...} in my main source code file solved the problem..
I am currently trying to generate more than one debian package from my project. My only problem with this is setting the name, description, group and so forth of the packages.
# --------------------------------------------------------------
# Required CMake version
# --------------------------------------------------------------
CMAKE_MINIMUM_REQUIRED (VERSION 2.8)
# --------------------------------------------------------------
# Project name
# --------------------------------------------------------------
PROJECT (MyProject)
# --------------------------------------------------------------
# Find all source and header files
# --------------------------------------------------------------
FILE (GLOB all_H "*.h")
FILE (GLOB all_SRC "*.cpp")
# --------------------------------------------------------------
# Set compiler flags
# --------------------------------------------------------------
SET (CMAKE_CXX_FLAGS "-Wall -Wextra -O0 -g3")
# --------------------------------------------------------------
# Add a shared library
# --------------------------------------------------------------
ADD_LIBRARY (mylib SHARED ${all_H} ${all_SRC})
# --------------------------------------------------------------
# Configure components
# --------------------------------------------------------------
SET (CPACK_DEB_COMPONENT_INSTALL 1)
# --------------------------------------------------------------
# Install
# --------------------------------------------------------------
INSTALL(TARGETS mylib DESTINATION ../lib COMPONENT main)
INSTALL(FILES ${all_H} DESTINATION ../include COMPONENT dev)
# --------------------------------------------------------------
# CPack package and package_source targets
# --------------------------------------------------------------
SET (CPACK_GENERATOR "TGZ;DEB")
SET (CPACK_SET_DESTDIR ON)
SET (CPACK_PACKAGE_NAME "mypackage")
SET (CPACK_PACKAGE_VENDOR "me")
SET (CPACK_PACKAGE_DESCRIPTION_SUMMARY "this is my package description")
SET (CPACK_DEBIAN_PACKAGE_DESCRIPTION "this is my package description
here comes detailed description text.")
INCLUDE (CPack)
The manual has some properties and commands for CPack Components but I doesn't seem to find the right ones or the right place to change at least name and description for every single package/component.
I tried using SET (CPACK_COMPONENT_MAIN_DISPLAY_NAME "main display name") and SET (CPACK_COMPONENT_main_DISPLAY_NAME "main display name") as well as cpack_add_component() before INCLUDE(CPack) (which gives me an error) and after (which seems to be ignored).
Did anybody get this to work and knows the right way to do this?
From last few days I am searching for such solution.
Let me first explain first my requirement and then how did i managed to solve problem.
I want to create 4 package from my single project
Master package: Which contains all binary,static/shared libraries,header files,configuration files and scripts.
Runtime package: Which contains only executable which are required to run my application i.e. binary ,shared library and scripts.
Configuration package: Which contains basic skeleton and place holder for configuration file.
Development packages: Which contains shared/static library and header files.
Generating Master package is easy one and straight forward. But If I use that way then I am unable to use other packages. So after struggling and scraping documents and mail archives, I came to one solution or workaround.
In my solution I am creating One extra custom target for each package I want to create. On that target I am creating other cmake project, which has list of files(Absolute location of file) to be install in that package, build that project and last create package by calling cpack.
Here is my solution.
There may be better/scale-able solution than this, If any one come across that please let me know.
I'm a bit late to the party but in CMake before version 3.5 components packaging was not supported for CPack debian packages.
From version 3.5 on quite a few per component features were added so the easiest way to solve you problem would be to bump the version of CMake and set the variables described in the documentation:
https://cmake.org/cmake/help/v3.5/module/CPackDeb.html or a newer one
https://cmake.org/cmake/help/v3.9/module/CPackDeb.html