I configured wxWidgets in CMake and built it with MinGW-x64. After building binaries I used the command mingw32-make install (as used in OpenCV) and It was automatically installed with the file arrangement shown below.
C:\Program Files (x86)\wxWidgets
├───include
│ └───wx
│ ├───android
│ ├───aui
│ ├───dfb
│ ├───generic
│ ├───gtk
│ ├───gtk1
│ ├───html
│ ├───meta
│ ├───motif
│ ├───msw
│ ├───osx
| |...
└───lib
└───gcc_dll
└───mswu
└───wx
But after the installation, I provided the parameters Compiler and Linker at Code::Blocks-> Settings-> Compiler -> Search Directories , but it gave errors while compiling a sample program, indicating the non-standard procedure.
I don't know the next step to associate the libraries and include files with Code::Blocks correctly. I have already googled it and most web-results use makefile.gcc in procedure. How to use wxWidgets in CodeBlocks after that?
Be advised that CMake is not an official way to build wxWidgets. You can however build your own software using this tool. CMake incorporation is started fairy recently and will be available (fully tested) in version 3.2. (hopefully).
Now I don't know what error message(s) you received in C::B, but you have to select exactly the same options for the new project as the one you build wxWidgets with. I.e. if you supply SHARED=0 during wxWidgets compilation you absolutely have to select SHARED=0 in the C::B project. And so forth.
Without the exact error message that the best suggestion you will get.
Also, you didn't mention you version of wxWidgets. Please do so in the future, especially since you are working with the IDE that does not immediately utilize the latest version of wx.
HTH.
Because each project (you have created a project, right? C::B requires it) may need different libraries and options I prefer not to use "global" C::B settings (apart from 'Toolchain executables').
Instead go to Project-->Build options. Check that the 'Selected compiler` is the one you want.
the tab Compiler settings refers to your compiler (g++), not to wxWidgets requirements. Take a look at the flags. Other options like -mthreads may be required.
The tab Linker settings is good for all Windows .dll, such as kernel32, user32, winmm, and about a dozen more.
If you have different targets, such as "debug" and "release" then wxWidgets libs are different (the "debug" ones have a d near the end of each name). Thus you must add different wx libs for different targets. Select one target (big box at left) and again in the Linker settings tab add those libs (wxmsw31u_core, wxbase31u, etc, or just the "big monolitic" one if you built this instead of several files) Seems you only have a "release" target, select it.
To instruct the compiler & linker about where it can find these wxWidgets files (.dll or .a) and its headers use the Search directories tab. Again, different targets use different dirs.
The compiler searches for .h, in your case add the path C:\Program Files (x86)\wxWidgets\include and also C:\Program Files (x86)\wxWidgets\lib\gcc_dll\mswu
For the linker (in Linkersub-tab) add C:\Program Files (x86)\wxWidgets\lib\gcc_dll
The Resource compiler sub-tab, for your .res file (likely you use one) uses also some wxWidgets headers, so add the same C:\Program Files (x86)\wxWidgets\include
Don't forget that wxWidgets uses some definitions.
Go to tab Compiler settings sub-tab #defines and add entries: __GNUWIN32__ and __WXMSW__
For more options read yourwxdir\docs\msw\install.txt
Related
I have created a personnal C++ library and I try to use it in an other program. To create and compile my library, I use the commands
cmake -G "Visual Studio 16 2019" -A x64 ..
cmake --build . --config Release --target INSTALL
I have no problem with te compilation and the installation, but in the Target-release.cmake install look like this :
#----------------------------------------------------------------
# Generated CMake target import file for configuration "Release".
#----------------------------------------------------------------
# Commands may need to know the format version.
set(CMAKE_IMPORT_FILE_VERSION 1)
# Import target "containers" for configuration "Release"
set_property(TARGET containers APPEND PROPERTY IMPORTED_CONFIGURATIONS RELEASE)
set_target_properties(containers PROPERTIES
IMPORTED_IMPLIB_RELEASE "C:/Program Files (x86)/containers/lib/containers.lib"
IMPORTED_LOCATION_RELEASE "C:/Program Files (x86)/containers/bin/containers.dll"
)
list(APPEND _IMPORT_CHECK_TARGETS containers )
list(APPEND _IMPORT_CHECK_FILES_FOR_containers "C:/Program Files (x86)/containers/lib/containers.lib" "C:/Program Files (x86)/containers/bin/containers.dll" )
# Commands beyond this point should not need to know the version.
set(CMAKE_IMPORT_FILE_VERSION)
Nothing abnormal, as far as I can see. My problem is : I have no file C:/Program Files (x86)/containers/lib/containers.lib generated during the compilation and the installation. So every time I try to use a find package, I have an error. (It's only with visual studio generator, it works with mingw). Here is my CMakeLists.txt :
cmake_minimum_required(VERSION 3.1)
set(VERSION 1.0.0)
project (containers
VERSION ${VERSION}
DESCRIPTION "Library adding some features to containers of the stl."
LANGUAGES CXX)
option(BUILD_TESTING "Build test programs" OFF)
include(CTest)
# Set the possible values of build type for cmake-gui
set(CMAKE_BUILD_TYPE Release CACHE STRING "Choose the type of build.")
set_property(CACHE CMAKE_BUILD_TYPE PROPERTY STRINGS "Debug" "Release" "MinSizeRel" "RelWithDebInfo")
message( STATUS "Sources path : ${PROJECT_SOURCE_DIR}")
message( STATUS "Binary path : ${PROJECT_BINARY_DIR}")
message( STATUS "install path : ${CMAKE_INSTALL_PREFIX}")
message( STATUS "Version : ${PROJECT_VERSION}")
message( STATUS "Version : ${PROJECT_VERSION}")
message( STATUS "Compiler : ${CMAKE_CXX_COMPILER_ID}")
set(SOURCES ${PROJECT_SOURCE_DIR}/src/containers.cpp)
set(HEADERS ${PROJECT_SOURCE_DIR}/include/containers/containers_check.h
${PROJECT_SOURCE_DIR}/include/containers/containers.h
${PROJECT_SOURCE_DIR}/include/containers/append.h
${PROJECT_SOURCE_DIR}/include/containers/contains.h
${PROJECT_SOURCE_DIR}/include/containers/remove.h
${PROJECT_SOURCE_DIR}/include/containers/print.h
)
add_library(containers SHARED ${SOURCES} ${HEADERS})
#add_library(containers INTERFACE)
target_compile_features(containers PRIVATE cxx_std_17)
set_target_properties(containers
PROPERTIES
MSVC_RUNTIME_LIBRARY "MultiThreadedDLL"
CXX_STANDARD_REQUIRED YES
CXX_EXTENSIONS OFF)
target_include_directories(containers
PUBLIC
$<INSTALL_INTERFACE:include>
$<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/include>)
target_compile_options(containers PRIVATE
# g++
#$<$<CXX_COMPILER_ID:GNU>:$<BUILD_INTERFACE:-Wall>>
#$<$<CXX_COMPILER_ID:GNU>:$<BUILD_INTERFACE:-Wextra>>
#$<$<CXX_COMPILER_ID:GNU>:$<BUILD_INTERFACE:-pedantic>>
#$<$<CXX_COMPILER_ID:GNU>:$<BUILD_INTERFACE:-Werror>>
#$<$<CXX_COMPILER_ID:GNU>:-Wno-reorder>
## Clang
#$<$<CXX_COMPILER_ID:Clang>:$<BUILD_INTERFACE:-Wall>>
##TODO
## MSVC
#$<$<CXX_COMPILER_ID:MSVC>:$<BUILD_INTERFACE:/W4>>
#$<$<CXX_COMPILER_ID:MSVC>:$<BUILD_INTERFACE:/WX>>
)
install(TARGETS containers
EXPORT containersTarget
ARCHIVE DESTINATION ${CMAKE_INSTALL_PREFIX}/lib/ COMPONENT Development
LIBRARY DESTINATION ${CMAKE_INSTALL_PREFIX}/lib/ COMPONENT Library NAMELINK_COMPONENT Development
RUNTIME DESTINATION ${CMAKE_INSTALL_PREFIX}/bin/ COMPONENT Runtimes
)
install(FILES ${HEADERS}
DESTINATION ${CMAKE_INSTALL_PREFIX}/include/containers/
COMPONENT headers)
include(CMakePackageConfigHelpers)
# For moteur_de_calculConfig.cmake
set(INCLUDE_INSTALL_DIR ${CMAKE_INSTALL_PREFIX}/include CACHE PATH "install path for include files")
set(LIBRARY_INSTALL_DIR ${CMAKE_INSTALL_PREFIX}/lib CACHE PATH "install path for libraries")
#------------------------------------------------------------------------------
# Configure <export_config_name>ConfigVersion.cmake common to build and install tree
set(config_version_file ${PROJECT_BINARY_DIR}/containersConfigVersion.cmake)
write_basic_package_version_file(
${config_version_file}
VERSION "${CMAKE_PROJECT_VERSION}"
COMPATIBILITY ExactVersion
)
#------------------------------------------------------------------------------
# Export '<export_config_name>Target.cmake' for a build tree
export(TARGETS
containers
FILE "${CMAKE_CURRENT_BINARY_DIR}/${PROJECT_NAME}Target.cmake"
)
#------------------------------------------------------------------------------
# Configure '<export_config_name>Config.cmake' for a build tree
set(build_config ${CMAKE_BINARY_DIR}/containersConfig.cmake)
configure_package_config_file(
"containersConfig.cmake.in"
${build_config}
INSTALL_DESTINATION "${PROJECT_BINARY_DIR}"
PATH_VARS INCLUDE_INSTALL_DIR LIBRARY_INSTALL_DIR VERSION
)
#------------------------------------------------------------------------------
# Export '<export_config_name>Target.cmake' for an install tree
install(EXPORT
containersTarget
DESTINATION "${CMAKE_INSTALL_PREFIX}/lib/cmake/${PROJECT_NAME}"
)
#------------------------------------------------------------------------------
# Configure '<export_config_name>Config.cmake' for a install tree
set(install_config ${PROJECT_BINARY_DIR}/CMakeFiles/containersConfig.cmake)
configure_package_config_file(
containersConfig.cmake.in
${install_config}
INSTALL_DESTINATION "${CMAKE_INSTALL_PREFIX}/lib/cmake/${PROJECT_NAME}"
PATH_VARS INCLUDE_INSTALL_DIR LIBRARY_INSTALL_DIR VERSION
)
# Install config files
install(
FILES ${config_version_file} ${install_config}
DESTINATION "${CMAKE_INSTALL_PREFIX}/lib/cmake/${PROJECT_NAME}"
)
# test
if(BUILD_TESTING)
add_subdirectory(test)
endif()
# uninstall target
# use : make uninstall
if(NOT TARGET uninstall)
configure_file(
"${CMAKE_CURRENT_SOURCE_DIR}/cmake_uninstall.cmake.in"
"${CMAKE_CURRENT_BINARY_DIR}/cmake_uninstall.cmake"
IMMEDIATE #ONLY)
add_custom_target(uninstall
COMMAND ${CMAKE_COMMAND} -P ${CMAKE_CURRENT_BINARY_DIR}/cmake_uninstall.cmake)
endif()
My cmake version :
cmake version 3.18.0
What is missing in my CMakeLists.txt for generate the container.lib file ?
Faced the same problem, I found the solution here: for Visual Studio to export symbols in a .lib file besides the .dll library, you need to set this in your CMake (version>= 3.4) script:
set(CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS ON)
Note that the .lib file created this way is a small size file and is not a static library.
CMake manual
I'd like to add to the accepted answer here, for others who might find it: although CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS will solve the problem, it could well be a sticking plaster masking a deeper issue going on with your code.
I'm not an expert on the Microsoft compilers, but I do know that if you build a shared library with MSVC, the .lib file should still be produced. However, rather than containing all of your compiled code as it would for a static library, it basically provides the compiler with information about the exported symbols in your shared library. This means that the compiler can automatically link any other targets to your shared library, without you needing to manually load the library from your code using the Windows API functions. If you link an executable to a shared library this way, the Microsoft C runtime will basically call LoadLibrary() for you automatically when your application starts. Useful, huh?
If the compiler does not produce a .lib alongside your shared library, this basically means that there are no exported symbols in the shared library. This is why CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS solves the problem - it forces all the symbols to be exported anyway, thereby causing the compiler to generate the .lib file detailing these exports. However, as you may be able to work out, this is very much the nuclear option. There's probably a lot of stuff in your shared library that really doesn't need to be visible from the outside! So the pertinent question becomes: why is nothing being exported from my library?
In the linked answer referred to previously, underneath all the CMake technicals, the issue was that the OP was not properly marking their symbols for export. It turns out that this was my issue too, but in a more round-about way: I had decided that for my particular library, which could previously be built in shared or static configurations, I now wanted to force it only to be built in a shared configuration. Because of this, I had removed a particular preprocessor definition from my project in CMake which specified whether the build mode was shared or static; this meant that all of the export annotations on my functions compiled down to nothing (as they should do under a static configuration where they are not needed). The upshot was that I accidentally ended up building the shared library with no exported symbols whatsoever, and MSVC just said "Well I guess there's no point building a .lib then", and didn't produce one. This caused the build issues stating that the .lib could not be found on disk.
When I encountered the answer above, I was suspicious as I wondered why I'd not had to set this value before, despite having used CMake to build Windows shared library projects for years. The correct solution in my case was not to switch CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS on - it was actually to remove the C++ preprocessor condition that checked for my "this is a shared build" preprocessor definition. This re-enabled all of the export annotations on my functions, and everything built as it should.
Before you use CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS, do check that there isn't some subtle bug in your scripts that is preventing your symbols from being exported!
I have a C file containing a function my_library_function() that I have compiled into a static library using gcc and packaged into an xcframework called mylib.xcframework using xcodebuild -create-framework. I have added this framework to an Xcode project for a Mac App. However within my Mac App I am unable to call this function, and am generally unsure about how to do so. I have tried import mylib from within Swift files and tried to directly call the function my_library_function() but in both cases have gotten compiler errors No such module mylib and Use of unresolved identifier 'my_library_function'. The only workaround I have found is to create a bridging header and #include the header file from its path within the xcframework. However, since eventually I would like to work with a more complex library and cross compile and have the xcframework include static libraries for multiple targets this seems like a hacky workaround. Is there some way I can do this without the bridging headers, am I missing something in this process?
Below are exact instructions of exactly what I did.
First I compiled the C code into a static library. The source code for the library contains a single function:
#include <stdio.h>
void my_library_function(void) {
printf("called from a static library");
}
mylib.c
I also have a header for the above:
void my_library_function(void);
mylib.h
The tree for the source code is as follows:
.
├── include
│ └── mylib.h
└── mylib.c
Project source tree
I then compiled the C code into a static library using:
> gcc -c mylib.c -o mylib.o
> ar rcs mylib.a mylib.o
Then I created an xcframework with:
xcodebuild -create-xcframework -library mylib.a -headers include -output mylib.xcframework
This resulted in an xcframework as so:
.
├── Info.plist
└── macos-x86_64
├── Headers
│ └── mylib.h
└── mylib.a
mylib.xcframework source tree
I then created a new Xcode project using Xcode 11.
At the root of the project I created a new group and called it Frameworks. I then dragged and dropped the xcframework into XCode frameworks group and checked the copy items if needed checkbox and the create groups radio button.
In the Xcode projects general tab, under Frameworks, Libraries and Embedded Content I set the framework to Embed & Sign.
Under the Build Settings tab, under Signing, I set Other Code Signing Flags to --deep to prevent a codesign error. In the same Build Settings tab, under Linking, the Runpath Search Paths is set to #executable_path/../Frameworks/. Additionally in the Build Settings tab under Search Paths, I have tried to set the Framework Search Paths, Library Search Paths and Header Search Paths to this same value #executable_path/../Frameworks/ and I have also tried with these paths as empty.
Unfortunately I am not able to use the my_library_function() from anywhere in the application, nor am I able to import mylib from Swift.
The only workaround I have found is to create an objective C bridging header and make a #include explicitly point within the framework folder into the Headers/mylib.h to be able to call my function. This seems like a hacky solution though as eventually I would like to cross compile my code and will have separate header files for each separate library for different architectures and it might get quite complex to do it this way. Is there something I am missing as to how to include my function from within an XCFramework with a MacOS Swift project?
Below are some images of my Xcode configuration:
I built with clang instead of gcc and included a clang modulemap file alongside the header. It now builds and even offers Xcode autocompletion.
I'm cross compiling using Qmake and QtCreator. In the settings for the Kits (toolchain and qmake details are set there) there is a field called Sysroot:.
(Example here)
Since QtCreator and Qmake are, at the end, responsible for generating a Makefile, my question is, to what does that option translate to in the Makefile and how does it get passed to the toolchain?
Motivation for the question
I have the Sysroot: pointing to ~/path-to-sysroot. ~/path-to-sysroot contains the regular sysroot structure cross compiled for an embedded target.
~/path-to-sysroot
├── bin
├── include
├── lib
├── sbin
├── share
└── usr
When I try to cross compile some code which depends on the libraries in ~/path-to-sysroot/usr/lib, it fails with a message that the libs are missing, but the exist there. I have parsed the generated makefile and found no traces of ~/path-to-sysroot/usr/lib.
from :http://doc.qt.io/qt-5/qt-conf.html
The qt.conf file can be used to override the hard-coded paths that are compiled into the Qt library. These paths are accessible using the QLibraryInfo class. Without qt.conf, the functions in QLibraryInfo return these hard-coded paths; otherwise they return the paths as specified in qt.conf.
Without qt.conf, the Qt libraries will use the hard-coded paths to look for plugins, translations, and so on. These paths may not exist on the target system, or they may not be accessible. Because of this, you may need qt.conf to make the Qt libraries look elsewhere.
qmake -query
QT_SYSROOT:/home/mentor/work/git/mel_repos/mel_cedar/build/tmp/sysroots/x86_64-linux
QT_INSTALL_PREFIX:/home/mentor/work/git/mel_repos/mel_cedar/build/tmp/sysroots/x86_64-linux/opt/mel/next+snapshot/sysroots/i686-melsdk-linux/usr
QT_INSTALL_PREFIX/raw:/opt/mel/next+snapshot/sysroots/i686-melsdk-linux/usr
QT_INSTALL_ARCHDATA:/home/mentor/work/git/mel_repos/mel_cedar/build/tmp/sysroots/x86_64-linux/opt/mel/next+snapshot/sysroots/i686-melsdk-linux/usr/lib/qt5
QT_INSTALL_ARCHDATA/raw:/opt/mel/next+snapshot/sysroots/i686-melsdk-linux/usr/lib/qt5
QT_INSTALL_DATA:/home/mentor/work/git/mel_repos/mel_cedar/build/tmp/sysroots/x86_64-linux/opt/mel/next+snapshot/sysroots/i686-melsdk-linux/usr/share/qt5
QT_INSTALL_DATA/raw:/opt/mel/next+snapshot/sysroots/i686-melsdk-linux/usr/share/qt5
QT_INSTALL_DOCS:/home/mentor/work/git/mel_repos/mel_cedar/build/tmp/sysroots/x86_64-linux/opt/mel/next+snapshot/sysroots/i686-melsdk-linux/usr/share/doc/qt5
QT_INSTALL_DOCS/raw:/opt/mel/next+snapshot/sysroots/i686-melsdk-linux/usr/share/doc/qt5
QT_INSTALL_HEADERS:/home/mentor/work/git/mel_repos/mel_cedar/build/tmp/sysroots/x86_64-linux/opt/mel/next+snapshot/sysroots/i686-melsdk-linux/usr/include/qt5
QT_INSTALL_HEADERS/raw:/opt/mel/next+snapshot/sysroots/i686-melsdk-linux/usr/include/qt5
QT_INSTALL_LIBS:/home/mentor/work/git/mel_repos/mel_cedar/build/tmp/sysroots/x86_64-linux/opt/mel/next+snapshot/sysroots/i686-melsdk-linux/usr/lib
QT_INSTALL_LIBS/raw:/opt/mel/next+snapshot/sysroots/i686-melsdk-linux/usr/lib
QT_INSTALL_LIBEXECS:/home/mentor/work/git/mel_repos/mel_cedar/build/tmp/sysroots/x86_64-linux/opt/mel/next+snapshot/sysroots/i686-melsdk-linux/usr/lib/qt5/libexec
QT_INSTALL_LIBEXECS/raw:/opt/mel/next+snapshot/sysroots/i686-melsdk-linux/usr/lib/qt5/libexec
QT_INSTALL_BINS:/home/mentor/work/git/mel_repos/mel_cedar/build/tmp/sysroots/x86_64-linux/opt/mel/next+snapshot/sysroots/i686-melsdk-linux/usr/bin/qt5
QT_INSTALL_BINS/raw:/opt/mel/next+snapshot/sysroots/i686-melsdk-linux/usr/bin/qt5
QT_INSTALL_TESTS:/home/mentor/work/git/mel_repos/mel_cedar/build/tmp/sysroots/x86_64-linux/opt/mel/next+snapshot/sysroots/i686-melsdk-linux/usr/share/qt5/tests
QT_INSTALL_TESTS/raw:/opt/mel/next+snapshot/sysroots/i686-melsdk-linux/usr/share/qt5/tests
QT_INSTALL_PLUGINS:/home/mentor/work/git/mel_repos/mel_cedar/build/tmp/sysroots/x86_64-linux/opt/mel/next+snapshot/sysroots/i686-melsdk-linux/usr/lib/qt5/plugins
QT_INSTALL_PLUGINS/raw:/opt/mel/next+snapshot/sysroots/i686-melsdk-linux/usr/lib/qt5/plugins
QT_INSTALL_IMPORTS:/home/mentor/work/git/mel_repos/mel_cedar/build/tmp/sysroots/x86_64-linux/opt/mel/next+snapshot/sysroots/i686-melsdk-linux/usr/lib/qt5/imports
QT_INSTALL_IMPORTS/raw:/opt/mel/next+snapshot/sysroots/i686-melsdk-linux/usr/lib/qt5/imports
QT_INSTALL_QML:/home/mentor/work/git/mel_repos/mel_cedar/build/tmp/sysroots/x86_64-linux/opt/mel/next+snapshot/sysroots/i686-melsdk-linux/usr/lib/qt5/qml
QT_INSTALL_QML/raw:/opt/mel/next+snapshot/sysroots/i686-melsdk-linux/usr/lib/qt5/qml
QT_INSTALL_TRANSLATIONS:/home/mentor/work/git/mel_repos/mel_cedar/build/tmp/sysroots/x86_64-linux/opt/mel/next+snapshot/sysroots/i686-melsdk-linux/usr/share/qt5/translations
QT_INSTALL_TRANSLATIONS/raw:/opt/mel/next+snapshot/sysroots/i686-melsdk-linux/usr/share/qt5/translations
QT_INSTALL_CONFIGURATION:/home/mentor/work/git/mel_repos/mel_cedar/build/tmp/sysroots/x86_64-linux/opt/mel/next+snapshot/sysroots/i686-melsdk-linux/etc/qt5
QT_INSTALL_CONFIGURATION/raw:/opt/mel/next+snapshot/sysroots/i686-melsdk-linux/etc/qt5
QT_INSTALL_EXAMPLES:/home/mentor/work/git/mel_repos/mel_cedar/build/tmp/sysroots/x86_64-linux/opt/mel/next+snapshot/sysroots/i686-melsdk-linux/usr/examples
QT_INSTALL_EXAMPLES/raw:/opt/mel/next+snapshot/sysroots/i686-melsdk-linux/usr/examples
QT_INSTALL_DEMOS:/home/mentor/work/git/mel_repos/mel_cedar/build/tmp/sysroots/x86_64-linux/opt/mel/next+snapshot/sysroots/i686-melsdk-linux/usr/examples
QT_INSTALL_DEMOS/raw:/opt/mel/next+snapshot/sysroots/i686-melsdk-linux/usr/examples
QT_HOST_PREFIX:/opt/mel/next+snapshot/sysroots/i686-melsdk-linux/usr
QT_HOST_DATA:/opt/mel/next+snapshot/sysroots/i686-melsdk-linux/usr/lib/qt5
QT_HOST_BINS:/opt/mel/next+snapshot/sysroots/i686-melsdk-linux/usr/bin/qt5
QT_HOST_LIBS:/opt/mel/next+snapshot/sysroots/i686-melsdk-linux/usr/lib
QT_EXTERNAL_HOST_BINS:/home/mentor/work/git/mel_repos/mel_cedar/build/tmp/sysroots/x86_64-linux/usr/bin/qt5
QMAKE_SPEC:/home/mentor/work/git/mel_repos/mel_cedar/build/tmp/sysroots/x86_64-linux/usr/lib/qt5/mkspecs/linux-oe-g++
QMAKE_XSPEC:linux-oe-g++
QMAKE_VERSION:3.0
QT_VERSION:5.4.1
qmake doesnot uses a sysroot argument it has all the paths in it. You can customize qmake by overriding those paths in qt.conf but still it has no path which shows sysroot. And I don't think it has any option to specify sysroot. You have to manually set the sysroot in Compiler flags in qtcreator
I am trying to use CMake to build a library (which in turn links to other libraries built via CMake). I am having a couple of issues with this process and would love to have some guidance.
For the library, I have a CMakeLists.txt which essentially has
set(SRC srcfile1.cpp srcfile2.cpp)
set(HEADERS srcfile1.h srcfile2.h)
add_library(myLib ${SRC} ${HEADERS})
INSTALL(FILES ${HEADERS} DESTINATION “include/myLib”)
For a “Unix Makefiles” generator, with cmake command
cmake -DCMAKE_INSTALL_PREFIX=. -DCMAKE_BUILD_TYPE=debug -G “Unix Makefiles” ..
I get an appropriate debug library libMyLib.a in build/src. For a release build type, a release build of libMyLib.a is placed in build/src
However, for an Xcode generator, the library is placed in src/Debug. The issues I am facing here are
a. Doing an Archive in Xcode doesn’t seem to have any effect. I don’t see a corresponding Release library being created anywhere
b. I also have a myLibTests target (which uses googles gtest) which is defined in it’s CMakeLists.txt as
set(SRC myTest.cpp)
add_executable(myLibTests ${SRC})
add_dependencies(myLibTests myLib gtest)
set(gTestLib External/src/gTestLib)
target_link_libraries(myLibTests myLib gTestLib)
When the cmake generator is “Unix Makefiles” myLibTests build, links and runs fine. gTestLib is placed in External/src/gtest-build/. But, when it is “Xcode”, it can’t find the gTest libraries. because, the library is placed in External/src/gTestLib/Debug(or Release) as the case may be (and the above path set in CMakeLists.txt is no longer valid). I am not sure how to set it’s path appropriately in the above set statement.
Since, debug/release is controlled in Xcode (and the configure process in CMake is unaware of this), I assume there isn’t a way to separate the release/debug builds of the gTestLib and also have CMake configure Xcode to pick up the appropriate version while building myLib i.e if I do a debug build of myLib it also does a debug build of gTest and links to it (similar for release builds)? Alternatively, is it possible to configure Xcode to place both the Debug and Release builds in the same location (and then hardcode it’s path above)? What would be the best way of configuring this?
Thanks
// brief version
How can I make CMake to use my supplied zlib (which it also has to build from source) instead of the one found by the finder without breaking the finder for other libs (OpenGL)?
ZLib needs to be used by the main project and also libPNG which comes as source as well.
Primary target platform is Windows.
// longer version:
In my project I need to link against libpng, zlib and OpenGL. With libpng being dependent on zlib. But zlib is also required by the main project.
I need to supply sourcecode for all libs except OpenGL, and build those libraries along with
the main project to assert linking the correct version and simplify building on Windows.
I found ways to do all this with custom libraries where no built-in finder exists, but I can't override the finder properly for just zlib. If I change the search path for libs, then OpenGL is not found.
However I can't get cmake to use my supplied zlib instead of a rouge zlib.DLL that the package finder finds somewhere in my system. (The one from tortoise git)
I tried to set ZLIB_LIBRARY to a specific filepath, but that only works on MinGW, and I also think this is not the way to do it.
(And also I had to explicitly link to png16_static instead of just libpng, for an inexplicable reason.)
Any help on this is much appreciated. Maybe I'm taking this on the wrong way?
Target&Development Platform:
Windows7
Visual Studio 2010
and MinGW (both need to work)
My (simplified example) CMakeLists.txt:
cmake_minimum_required (VERSION 2.6)
project (MyProject)
find_package(OpenGL)
add_executable(MyProject main.cpp)
include_directories(${INCLUDE_DIRECTORIES} "${PROJECT_BINARY_DIR}")
include_directories(${INCLUDE_DIRECTORIES} "external_libs/lpng162")
include_directories(${INCLUDE_DIRECTORIES} "external_libs/zlib-1.2.8")
include_directories(${INCLUDE_DIRECTORIES} "${PROJECT_BINARY_DIR}/external_libs/zlib-1.2.8")
add_subdirectory("external_libs/zlib-1.2.8")
link_directories(${LINK_DIRECTORIES} "${PROJECT_BINARY_DIR}/external_libs/zlib-1.2.8")
# libpng will not build correctly if this not set
set (ZLIB_ROOT "${PROJECT_SOURCE_DIR}/external_libs/zlib-1.2.8")
# manually set this to prevent cmake from finding the tortiose-git zlib.dll first
# DOES NOT WORK CORRECTLY, only with mingw32
set (ZLIB_LIBRARY "${PROJECT_BINARY_DIR}/external_libs/zlib-1.2.8/libzlib.dll")
add_subdirectory("external_libs/lpng162")
TARGET_LINK_LIBRARIES(MyProject png16_static zlib ${OPENGL_LIBRARY})
Project (simplified example) structure:
./main.cpp
./CMakeLists.txt
./external_libs/zlib-1.2.8/ <- contains respective source
./external_libs/lpng162/ <- contains respective source
Third-party libraries most likely call FindZLIB.cmake to determine the location of CMake. You already had the right idea by setting the ZLIB_LIBRARY manually, but were not quite getting it right:
add_subdirectory(<path_to_zlib_src_dir>)
set(ZLIB_INCLUDE_DIR "<path_to_zlib_src_dir>" "${CMAKE_BINARY_DIR}/<path_to_zlib_build_dir>")
set(ZLIB_LIBRARY zlib)
add_subdirectory(<path_to_lpng_src_dir>)
The include directory needs to contain both src and build path as zconf.h is build by CMake
The library name is only the CMake-target name, not the complete path to the resulting file.
On Windows dlls are not automatically copied by CMake. You might want to add some additional code to make sure that the zlib and lpng dlls end up in the right place.
You can call find_package(zlib) yourself to make sure it behaves as expected
In the rare case that a third-party lib does not use the find script, you will have to dig into that project's CMakeLists to find out what is going on