I'm trying to work with Qt5, SoQt (Version 1.5.0) and Coin3D (3.1.3). I used instructions found on this website to install Coin3D. I tried to install SoQt as well (Instructions found here). I had to change those export commands a little bit:
export COINDIR="/usr/local/share"
I tried four different versions of the export INCLUDE since i'm clueless about its purpose and i am not sure if this is the reason for the errors i'm getting:
export INCLUDE="/usr/local/include:/usr/include/x86_64-linux-gnu/qt5/QtCore"
export INCLUDE="/usr/local/include:/usr/include/x86_64-linux-gnu/qt5"
export INCLUDE="/usr/include/x86_64-linux-gnu/qt5/QtCore"
export INCLUDE="/usr/include/x86_64-linux-gnu/qt5"
This is where errormessages appear: (Shorter summary below)
checking for QT4...
Could not gather the configure flags for Qt through pkg-config. Please
ensure that the qt pkg-config metadata .pc files, such as QtCore.pc,
exist on your system. In case the metadata .pc files are installed
into a non-default location verify that the PKG_CONFIG_PATH environment
variable points to the correct directory.
Further details in how to set the PKG_CONFIG_PATH environment variable
can be found in the pkg-config(1) man page.
checking whether the X11 miscellaneous utilities library is available... maybe
checking for cygpath... false
checking for moc... /usr/bin/moc
configure: WARNING: header file qglobal.h not found, can not compile Qtcode
configure: WARNING: QTDIR environment variable not set -- this might be an indication of a problem
Could not find any way to build against the Qt library. If you
are sure Qt is properly installed on your system, see the file
config.log to find out what went wrong.
One common way to solve this problem is to set up the environment
variable QTDIR to the base of the Qt installation directory. Or if it
was already set up, double check to see that it is pointing at the
correct directory.
Note that it is possible to override the combinations of Qt libraries
configure tries to link against by setting up the environment variable
CONFIG_QTLIBS. This might be necessary if you have installed the Qt
library in a manner that is not compatible with any of the known
configurations, for instance by changing the name of the library or
the Qt library having more dependencies on other libraries that we are
aware of.
If you for instance know the correct set of libraries to be qt304.lib,
qtmain.lib and gdi32.lib (this would be on an MSWindows system), then
set CONFIG_QTLIBS to the string ''-lqt304 -lqtmain -lgdi32'' before
re-running configure.
If you still can't get the configure script to detect the presence of
and how to use the Qt library, please mail the config.log file to
<coin-support#coin3d.org> and ask for help.
configure: error: aborting
I might be wrong but it seems like he is looking for Qt4 and not Qt5 because of
checking for QT4...
It also reads
configure: WARNING: header file qglobal.h not found, can not compile Qtcode
That's why i tried using qt5/QtCore instead of qt5 as path because there is a qglobal.h located within QtCore but it doesn't change anything.
Did anyone else face similar problems when setting up SoQt with Qt5 and can help me out?
Thanks in advance!
Those releases are very old (2012). Please grab the latest source of Coin from the CMake brach [1], and SoQt from [2]. Build with CMake. Also see this discussion [3] regarding high DPI support.
[1] https://bitbucket.org/Coin3D/coin/branch/CMake
[2] https://bitbucket.org/Coin3D/soqt/branch/default
[3] https://groups.google.com/forum/#!topic/coin3d-discuss/ipkSH08iFNk
Related
I switched to catch2 3.0, which is now represented as static library and faced the problem of its build type (configuration). To install catch2 it should be built either with Release or Debug config, so you'll have the corresponding .lib file in your install path. But! I can link it against my project only if it (project) has the same config. So if I want to switch the config of my project, I have to reinstall catch2 with appropriate config.
Is there a way to solve this issue?
Two possible options off the top of my head:
Option 1. install catch2 to 2 seperate dirs:
Build Release and Debug of catch2
Install to two different locations (/path/to/rel & /path/to/debug)
In your project, for Release and Debug build tree, set CMAKE_PREFIX_PATH to one of those, respectively.
This method is clear and simple, and guaranteed to work.
NOTE: you do not have to hard code library path in your project, since the path is passed to cmake as command line/GUI argument.
Option 2. Use CMAKE_<CONFIG>_POSTFIX to distinguish different builds
This one I'm not quite sure of, but I just wanna point out that cmake does provide this feature. Here's the doc.
For example, if you set CMAKE_DEBUG_POSTFIX as -debug, then the Debug library file will be renamed from foo to foo-debug, while Release library will still be foo. Then they can live in the same folder.
Just so you know, I've never tried this feature myself. And I believe it kinda depends on the quality of catch2's cmake Config file (if it has one). So YMMV if you wanna try out this option.
Using Windows 10, I want to configure the source of OpenSceneGraph via CMake to make it build-ready for Visual Studio. I also need some DCMTK functionalities, hence I want to link it.
OpenSceneGraph provides an attempt to link DCMTK in its CMakeLists.txt, but it fails (and since linking it is optional, configuration is finished nevertheless).
-- Trying to find DCMTK expecting DCMTKConfig.cmake
-- Trying to find DCMTK expecting DCMTKConfig.cmake - failed
-- Trying to find DCMTK relying on FindDCMTK.cmake
-- Please set DCMTK_DIR and re-run configure (missing: DCMTK_config_INCLUDE_DIR DCMTK_dcmdata_INCLUDE_DIR DCMTK_dcmimage_INCLUDE_DIR DCMTK_dcmimgle_INCLUDE_DIR DCMTK_dcmjpeg_INCLUDE_DIR DCMTK_dcmjpls_INCLUDE_DIR DCMTK_dcmnet_INCLUDE_DIR DCMTK_dcmpstat_INCLUDE_DIR DCMTK_dcmqrdb_INCLUDE_DIR DCMTK_dcmsign_INCLUDE_DIR DCMTK_dcmsr_INCLUDE_DIR DCMTK_dcmtls_INCLUDE_DIR DCMTK_ofstd_INCLUDE_DIR DCMTK_oflog_INCLUDE_DIR)
My DCMTK package does provide a DCMTKConfig.cmake file, and I've set a system environment variable DCMTK_DIR that points to its directory.
Researching the problem, I've found the article on FindDCMTK but I can't get any viable information out of it.
The directories for OpenSceneGraph and DCMTK are next to each other in a specified location.
How do I instruct CMake to find the configuration file of DCMTK?
As suggested by Tsyvarev in the comments above, I would also advise using the CMAKE Gui on Windows - when you attempt to configure, it should display everything it either set or changed with red highlights. Then you can manually edit the DCMTK related variables to point to the correct folders and/or files - you might be able to just edit the Root folders and hit configure again to let it populate based on root. When you are satisfied with the settings and not getting errors, then you can hit Generate to let it create the Visual Studio files.
I've installed a version of CMake to /some/where/cmake, and have put /some/where/cmake/bin in the PATH.
What environment variables do I need to set, and what other actions do I need to take, in order for my custom CMake to function properly? Specifically, how do I ensure it looks in /some/where/cmake/share before /usr/share for CMake-related files?
Notes:
The OS is GNU/Linux.
I'm using CMake 3.16.6.
If I issue the CMake command message(STATUS ${CMAKE_ROOT}), I get: /some/where/cmake/share/cmake-3.16
What environment variables do I need to set, and what other actions do I need to take, in order for my custom CMake to function properly? Specifically, how do I ensure it looks in /some/where/cmake/share before /usr/share for CMake-related files?
Nothing! CMake is designed to look relative to the binary's actual location on your filesystem and otherwise ignore standard system directories for its own functioning (of course it will detect these for toolchain purposes).
I have personally installed CMake 3.1 -- 3.20 on Ubuntu Linux by just downloading and untarring the release archives here to /home/alex/bin/cmake-3.X.Y and creating corresponding symlinks cmake-3.X, ctest-3.X, and cpack-3.X in /home/alex/bin (which is in my PATH). I use these regularly to test answers I post here on StackOverflow. Took all of 5 minutes to set up.
I am trying to build and use CEGUI (Crazy Eddie's GUI) as a library for Ogre. I am using CMake, but during the configuring step for the dependencies, I got the following error:
Some or all of the gtk libraries were not found. (missing: GTK2_GTK_LIBRARY GTK2_GTK_INCLUDE_DIR GTK2_GDK_INCLUDE_DIR GTK2_GDKCONFIG_INCLUDE_DIR GTK2_GDK_LIBRARY GTK2_GLIB_INCLUDE_DIR GTK2_GLIBCONFIG_INCLUDE_DIR GTK2_GLIB_LIBRARY)
CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
Boost_INCLUDE_DIR (ADVANCED)
used as include directory in directory C:/Cegui/cegui-0.8.3/cegui/src/RendererModules/Ogre
CEGUI 0.8.3
cegui-deps-0.8.x-src.zip
Make sure that you have GTK2 installed on your machine (as far as I can tell, it is not part of the CEGUI dependency download archive).
Ensure that CMake can find the library and all it needs. From having a look at the official CMake FindGKT2 script (and I couldn't find a custom one for CEGUI, so the official one is most likely used), the following locations are checked:
/usr/local/lib64
/usr/local/lib
/usr/lib64
/usr/lib
/opt/gnome/include [and /lib]
/opt/openwin/include [and /lib]
/sw/include [and /lib]
/opt/local/include [and /lib]
/usr/pkg/lib
/usr/pkg/include/glib
$ENV{GTKMM_BASEPATH}/include [and /lib]
[HKEY_CURRENT_USER\SOFTWARE\gtkmm\2.4;Path]/include
[HKEY_CURRENT_USER\SOFTWARE\gtkmm\2.4;Path]/lib
[HKEY_LOCAL_MACHINE\SOFTWARE\gtkmm\2.4;Path]/include
[HKEY_LOCAL_MACHINE\SOFTWARE\gtkmm\2.4;Path]/lib
So if you are on windows, setting the environment variable GTKMM_BASEPATH will probably be the easiest way. Alternatively, you can also directly enter the paths to your GTK2 installation in the advanced CEGUI view.
I have a question regarding CMake: recently a lot of modules have been added to the standard installation, such as GLEW or Mercurial.
However a lot of installation base might have an older version without all the new modules available, so you are forced to ship your own version of (eg) FindGLEW.cmake
Is it possible to check whether a given FindXXX module is available and in that case use it, otherwise supply a proper alternative? Or even check cmake version at runtime (but that's not always reliable and a pain to maintain)...?
Thanks for any help.
The default search behaviour of CMake's include command w.r.t modules is:
the file with name <modulename>.cmake is searched first in CMAKE_MODULE_PATH, then in the CMake module directory.
(there's a bit more to it - see the docs or run cmake --help-command include)
What you're asking for appears to be the opposite to this; first check for an official module in the CMake module directory, and if none exists, fall back to use your own.
Assuming your modules are in ${CMAKE_SOURCE_DIR}/my_cmake_modules, you could reverse CMake's default behaviour by doing:
set(CMAKE_MODULE_PATH ${CMAKE_ROOT}/Modules ${CMAKE_SOURCE_DIR}/my_cmake_modules)
If you name your own modules exactly as per the official ones, then this should achieve your goal. If you wish to revert to the normal CMake behaviour later in your script, you can do:
set(CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR}/my_cmake_modules)
as a possible alternative to the solution above, I found this cmake policy
CMP0017
Prefer files from the CMake module directory when including from
there.
Starting with CMake 2.8.4, if a cmake-module shipped with CMake (i.e.
located in the CMake module directory) calls include() or
find_package(), the files located in the the CMake module directory
are preferred over the files in CMAKE_MODULE_PATH. This makes sure
that the modules belonging to CMake always get those files included
which they expect, and against which they were developed and tested.
In call other cases, the files found in CMAKE_MODULE_PATH still take
precedence over the ones in the CMake module directory. The OLD
behaviour is to always prefer files from CMAKE_MODULE_PATH over files
from the CMake modules directory.
This policy was introduced in CMake version 2.8.4. CMake version
2.8.9 warns when the policy is not set and uses OLD behavior. Use the
cmake_policy command to set it to OLD or NEW explicitly.
Hope this helps.