I've been trying to build CGAL with cmake_gui by following
https://doc.cgal.org/latest/Manual/windows.html#title8
and
http://acg.cs.tau.ac.il/cgal-at-tau/installing-cgal-and-related-programs-on-windows
except with CGAL5.0.2 and QT5 and boost 1.72. I did also cmake_gui the ZLIB 1.2.11 ok.
the issue is that after configuring, there is no code generated or any error message. the Generated CGAL.sln only contains housekeeping projects without the lib projects.
i did have to manually edit the boost lib location and qt location until there is no unresolved symbols from the cmake gui. the boost, gmp and fpmr libs are present and they show up in the gui groups but they do not show up in the generated solution. the console output from the cmake_gui during the configure phase is very short.. but no error. see below.
== Setting paths ==
Build CGAL from release in directory CGAL-5.0.2
Packagenames: CGAL-5.0.2
== Setting paths (DONE) ==
== Generate version files ==
CGAL_MAJOR_VERSION=5
CGAL_MINOR_VERSION=0
CGAL_BUGFIX_VERSION=2
CGAL_SONAME_VERSION=13
CGAL_SOVERSION =13.0.3
CGAL_REFERENCE_CACHE_DIR=
Building shared libraries
Visual Leak Detector (VLD) is not found.
Targetting Visual Studio 16 2019
Target build enviroment supports auto-linking
Using VC toolset 142.
Generator uses intermediate configuration directory: $(Configuration)
USING CMake version: 3.17.1
System: Windows
== Generate version files (DONE) ==
Multi-configuration CMake generator: cannot display flags
== Detect external libraries ==
== Detect external libraries (DONE) ==
== Generating build files ==
Configuring libCGAL
Boost include dirs: E:/dev
Boost libraries:
USING GMP_VERSION = '5.0.1'
USING MPFR_VERSION = '3.0.0'
USING BOOST_VERSION = '1.72.0'
libCGAL is configured
Sources for CGAL component library 'CGAL_Core' detected
Configuring libCGAL_Core
libCGAL_Core is configured
Sources for CGAL component library 'CGAL_ImageIO' detected
Configuring libCGAL_ImageIO
USING ZLIB_VERSION = '1.2.11'
libCGAL_ImageIO is configured
Sources for CGAL component library 'CGAL_Qt5' detected
Configuring libCGAL_Qt5
USING Qt5_VERSION = '5.12.4'
libCGAL_Qt5 is configured
Sources for CGAL component libraries 'CGAL_Core;CGAL_ImageIO;CGAL_Qt5' detected
== Generating build files (DONE) ==
Configuring done
Generating done
cmake_gui after config
VS19 sln view
any hint would be helpful.
thanks
Related
Our Android application consists of 40-some Android Library Modules (ALMs), each of which also builds a C++ shared library with externalNativeBuild and CMake. So far we had the dependencies between these libs set up like this:
The dependent ALM references the dependency ALM with api project(':lib')
The dependent CMake script references the dependency .so with add_library(SHARED IMPORTED lib) and set_target_properties(lib PROPERTIES IMPORTED_LOCATION ...) and a relative path.
Recently we had to upgrade to the latest Android API version. This started off a cascade because now we were getting deprecated warnings in code generated by the navigation-ktx library, but upgrading that requires upgrading Gradle and the Android Gradle plugin. After that I started getting errors like liblib.so, needed by 'project', missing and no known rule to make it.
It looks like the latest Gradle parallelizes build tasks more heavily, and this means the dependent CMake/Ninja builds are being started concurrently with their dependencies, resulting in this error because the dependency is not yet built. I figured out that what we were doing was not entirely supported, but there is a "supported" way to do that now, so I refactored our entire build to use Prefab.
Now I started getting other errors, alternating between:
1.
C++ build system [prefab] failed while executing ...
Usage: prefab [OPTIONS] PACKAGE_PATH...
Error: Invalid value for "PACKAGE_PATH": Directory ... is not readable.
ld: error: undefined symbol ...
I looked into build/intermediates and found that in the 2nd case, the cmake config script was generated incorrectly: instead of add_library(lib::lib SHARED IMPORTED ) it had add_library(lib::lib INTERFACE IMPORTED) like it it was a header only library, and there was no IMPORTED_LOCATION set in the file.
What am I doing wrong and what should I do to unbreak our build?
It looks like the toolchain support for prefab interdependencies within a project is not quite finished. Others are reporting the same kind of errors at https://issuetracker.google.com/issues/265544858:
This appears to be a race condition with generating prefab cmake files.
It says in https://issuetracker.google.com/issues/221231432 that the header-only cmake config is generated to satisfy Android Studio's IDE features (completion, etc.) before the library is actually built.
Treat as-yet-unconfigured modules as if they are Header-only libraries for Android Studio purposes. This works because Android Studio doesn't care about linker flags for the purposes of providing language services.
We have a project, where we have different applications, which come with protobuf definitions, for which we provide python bindings as a side effect. We ran into the problem, that when we want to install them along with the rest of the software, cmake complains that the binding to be created does not exist.
This is a minimal sample which behaves wrong:
// foo.proto
message Foo {
uint32 foo = 1;
}
# CMakeLists.txt
project(foobar)
cmake_minimum_required(VERSION 3.16)
find_package(Protobuf REQUIRED)
protobuf_generate_cpp(FOO_SRC FOO_HDR foo.proto)
protobuf_generate_python(FOO_PY foo.proto)
install(FILES ${FOO_PY} DESTINATION "share/proto/")
$ make install
-- Configuring done
-- Generating done
-- Build files have been written to: /tmp/foobar
Install the project...
-- Install configuration: ""
CMake Error at cmake_install.cmake:41 (file):
file INSTALL cannot find "/tmp/foobar/foo_pb2.py": No such file or
directory.
How can I convince CMake to build the bindings when I run make install?
Functions protobuf_generate_cpp and protobuf_generate_python are actually create custom commands (add_custom_command). This is noted in the documentation for these functions.
For make a custom command to work, it should be some target which consumes (or depends on) the files created by the custom command.
In case of protobuf_generate_cpp, consumption is usually performed with add_library/add_executable commands.
But it is possible to create a custom target which depends on given files:
protobuf_generate_cpp(FOO_SRC FOO_HDR foo.proto)
protobuf_generate_python(FOO_PY foo.proto)
add_custom_target(proto_target ALL DEPENDS ${FOO_SRC} ${FOO_HDR} ${FOO_PY})
Context:
I built an a.out on my local system with a modern CMake project adding a dependency to a shared library:
find_package(GDAL QUIET)
if(GDAL_FOUND)
get_property(_loc TARGET GDAL::GDAL PROPERTY LOCATION)
message(STATUS "Found GDAL: ${_loc} (version ${GDAL_VERSION})")
add_library(gdal_external INTERFACE) # dummy
Everything works fine on my system. Now I want to distribute the a.out to systems that don't have the dependency (the .so).
Problem:
I copied the binary a.out on a cluster, and when I execute it, I get the following error: error while loading shared libraries: libgdal.so.26: cannot open shared object file: No such file or directory.
Possible solution and other considerations
Installing the dependencies on the cluster, but I don't have admin rights on this server
even if I had the dependency installed by the staff, the same problem will arise later when I will ship the binary to possible users
I can't ask future users to manage dependencies and build from sources.
It seems to me that I should embed all the dependencies in the same executable, that is using a static library rather than share
Executable size or memory issues are not the priority
How do I indicate CMake to use the static version of a library ?
I'm restucturing the CMake based build of a cross platform (macOS/Windows, Linux should be added soon) C++ project that has a third party rust library as dependendcy. Until now the rust lib dependency was supplied as precompiled library but I want to make its compilation part of my CMake build.
I got it working on macOS using the CMake makefile exporter by referencing the compiled library as a static imported library target and setting up a custom target with the command to build the rust library through cargo like this
add_library (rustlib STATIC IMPORTED)
add_custom_target (rustlib_cargo
WORKING_DIRECTORY ${CMAKE_CURRENT_LIST_DIR}/Ext/rustlib/c-api
COMMAND cargo rustc --release -- --crate-type staticlib)
# Note: RUSTLIB_OUTPUT is set above refering to the absolute path of the produced platform specific library
set_target_properties (rustlib PROPERTIES IMPORTED_LOCATION ${RUSTLIB_OUTPUT})
add_dependencies (rustlib rustlib_cargo)
On macOS the cargo rustc command is invoked before the targets that link against my rustlib target are built and in case the rust library has been built previously this is detected by cargo and it just skips that compilation steph. But on Windows this fails with the built-in ninja exporter of Microsoft Visual Studio 2019 with an error like this:
ninja : error : '../../../Ext/rustlib/target/release/deps/rustlib.lib', needed by 'SomeTargetLinkingAgainstRustlib', missing and no known rule to make it
If I remove the line set_target_properties (rustlib PROPERTIES IMPORTED_LOCATION ${RUSTLIB_OUTPUT}) the build starts correctly, the rust build gets triggered, but as expected I end up with a linker error as the library to link against is not found. So is there any way to refer to a file that is not existent at configuration time but is guranteed to be created during compilation?
I am trying to build an OS X library using CMake. This libary also includes some amount of resource files (.pdfs used as icon images). In my initial attempts, I have been building the library and the resource files separately as libGeneric.a and generic-Resources.bundle - with, the bundle hosting all the relevant images that libGeneric.a uses.
set (SRC srcfile1.m srcfile2.m)
set (HEADERS srcfile1.h srcfile2.h)
set (ICONS icon1.pdf icon2.pdf)
set (SOURCE_FILE_PROPERTIES ${ICONS} PROPERTIES MACOSX_PACKAGE_LOCATION "Resources")
add_library(generic ${SRC} ${HEADERS})
add_library(generic-Resources MODULE ${ICONS})
set_target_properties(generic-Resources PROPERTIES LINKER_LANGUAGE C) # to suppress CMake error of not able to determine linker language for libary
set_target_properties(generic-Resources PROPERTIES BUNDLE TRUE)
This worked fine, except, I was not able to figure out how to directly include the .bundle in the build process of applications that was using libGeneric.a. The only way I could get CMake to load the bundle was to add it as a source file in the target application. But, since, the bundle had not yet been compiled while running CMake, it would complain that the source file did not exist. As a workaround, I resorted to manually adding the .bundle into xcode after CMake generated the App.xcodeproj file (and I actually compiled the bundle). As this was getting to be cumbersome, I figured I'd try to build a Mac OS X framework instead (to house both the library and the code)
set (SRC srcfile1.m srcfile2.m)
set (HEADERS srcfile1.h srcfile2.h)
set (ICONS icon1.pdf icon2.pdf)
set (SOURCE_FILE_PROPERTIES ${ICONS} PROPERTIES MACOSX_PACKAGE_LOCATION "Resources")
add_library(generic SHARED ${SRC} ${HEADERS} ${ICONS})
set_target_properties(generic PROPERTIES FRAMEWORK TRUE)
set_target_properties(generic PROPERTIES MACOSX_RPATH TRUE) #to suppress cmake warnings on rpath
However, this is creating a framework with just the Icons inside a Resources directory. The code library is missing. I would appreciate some assistance in getting this framework to build correctly. How, do I
get CMake to actually build a library with the indicated source file
and place it inside the framework
get CMake to copy the headers appropriately in the framework.
I am just setting rpath to true now, as I haven't really figured out what to actually do with it. What do I set this to? The objective is to build a private framework, that I would then bundle automatically with my application.
Alternatively, is there an easy way to get CMake to build the bundle file created in my earlier process, and then load that built file into my applications build process.