How to link Ceres to CGAL to use Smoothing functions? - cgal

I've built the Ceres package and its dependencies, now I'm trying to use the CGAL library to perform smoothing but I'm getting an error: "area-based smoothing requires ceres library".
How am I to incorporate the Ceres library? The CGAL smoothing example doesn't mention this and does not have any includes from the Ceres library.
I'm using CGAL in header-only mode without compilation, is it necessary to compile CGAL first?

In the cmake script of the examples using the smoothing, you can see the following line:
target_compile_definitions( mesh_smoothing_example PRIVATE CGAL_PMP_USE_CERES_SOLVER )
it is equivalent to add #define CGAL_PMP_USE_CERES_SOLVER in your code.
The rational is that if the lib is not found by cmake, the code will be disabled.
I agree that it is not correctly documented. An issue/PR has already been opened to improve the situation.

Related

Adding External Library to Zephyr

Context:
I am trying to add an external library which uses CMake to my Zephyr project. I have explored the modules documentation, but this does not seem a good fit as I am unable to modify the upstream library and would like to avoid forking.
To add the library, I am using FetchContent in my Cmake file. This is working successfully and I am able to download and build the files.
Problem:
When linking, I encounter a "Conflicting CPU architectures" error. After inspecting into compile_commands.json, I can see the libraries source code is not receiving the same CMAKE_ARGS as the other files, leading to the architecture mismatch.
I am looking for the suggested way of adding external libraries to a zephyr project, without using the module system.
FetchContent_Declare(
my-lib
GIT_REPOSITORY git#github.com:<HostRepo>/<repoName>.git
GIT_TAG v0.1.7
)
FetchContent_MakeAvailable(my-lib)
target_link_libraries(app PRIVATE my-lib)
I recommend doing the repo fetching with a toplevel west.yml manifest and including your lib with add_library() or the appropriate cmake function.

Link ceres to CGAL to use the smooth_mesh() function

I want to add a smoothing function to my C++ project so I'm trying to use the smooth_mesh() function in the CGAL library. This function requires ceres-solver to work (and glog and Eigen) so I included it in an include folder in my project.
My problem is that when I try to launch a CGAL::Polygon_mesh_processing::smooth_mesh(), it returns an error (even though everything compiles properly):
Area-based smoothing requires the Ceres Library, which is not available.
The full way I use the function is the following:
CGAL::Polygon_mesh_processing::smooth_mesh(mesh,
CGAL::Polygon_mesh_processing::parameters::number_of_iterations(nb_iterations)
.use_area_smoothing(true)
.use_safety_constraints(false)
.edge_is_constrained_map(eif));
There is a very similar question on stack but the given solution did not help me to solve my problem. The answer directed me to use #define CGAL_PMP_USE_CERES_SOLVER but even with that the error is still happening.
It also mentions Cmake but I haven't built my project nor the libraries with CMake because CGAL instructions use vcpkg so I'm guessing that it may be where the problem comes from considering most ceres doc I found use Cmake. But instructions to link ceres and cgal using Cmake are pretty hard to find and/or not very clear (and I'm also very new to Cmake so that's not helping...).
I have tried to add the library manually to my project settings (I'm using Visual Studio on Windows), add some #include linking to ceres in some cgal files but nothing seems to be working.
I'm hoping someone here has run into this problem and managed to solve it.
If you can help me, thank you in advance!

cmake - linking static library pytorch cannot find its internal functions during build

I'm trying to build a program using cmake. For several reasons, the program must be built using static libraries rather than dynamic libraries, and I need to use PyTorch so this is what I've done:
Downloaded and installed PyTorch static library (I've found libtorch.a in the proper path, in /home/me/pytorch/torch/lib)
Made CMakeLists.txt with the following contents:
cmake_minimum_required(VERSION 3.5.1 FATAL_ERROR)
project(example-app LANGUAGES CXX)
find_package(Torch REQUIRED)
add_executable(example-app example-app.cpp argparse/argparse.cpp)
target_link_libraries(example-app "${TORCH_LIBRARIES}" -static -fopenmp)
set_property(TARGET example-app PROPERTY CXX_STANDARD 14)
FYI, example-app.cpp is the file with the main function, and argparse/ is a directory with some source code for functions called in example-app.cpp
It works until cmake -DCMAKE_PREFIX_PATH=/home/me/pytorch/torch .., but the following build incurs some errors, saying it could not find the reference to some functions, namely functions starting with fbgemm::. fbgemm is (as long as I know) some sort of GEMM library used in implementing PyTorch.
It seems to me that while linking the static PyTorch library, its internal libraries like fbgemm stuff have not been linked properly, but I'm not an expert on cmake and honestly not entirely sure.
Am I doing something wrong, or is there a workaround for this problem? Any help or push in the right direction would be greatly appreciated.
P.S.
The exact error has not been posted because it is way too long, but it consists of mostly undefined reference to ~ errors. If looking at the error message might be helpful for some people, I'd be happy to edit the question and post it.
building and running the file works fine if I remove the parts that require the library's functions from the code without commenting out #include <torch/torch.h> from example-app.cpp.
Lately went through similar process with static linking of PyTorch and to be honest it wasn't too pretty.
I will outline the steps I have undertaken (you can find exact source code in torchlambda, here is CMakeLists.txt (it also includes AWS SDK and AWS Lambda static builds), here is a script building pytorch from source ( cloning and building via /scripts/build_mobile.sh with only CPU support)),
though it's only with CPU support (though similar steps should be fine if you need CUDA, it will get you started at least).
Pytorch static library
Pre-built static PyTorch
First of all, you need pre-built static library files (all of them need to be static, hence no .so, only those with .a extension are suitable).
Tbh I've been looking for those provided by PyTorch on installation page, yet there is only shared version.
In one GitHub issue I've found a way to download them as follows:
Instead of downloading (here via wget) shared libraries:
$ wget https://download.pytorch.org/libtorch/cu101/libtorch-shared-with-deps-1.4.0.zip
you rename shared to static (as described in this issue), so it would become:
$ wget https://download.pytorch.org/libtorch/cu101/libtorch-static-with-deps-1.4.0.zip
Yet, when you download it there is no libtorch.a under lib folder (didn't find libcaffe2.a either as indicated by this issue), so what I was left with was building explicitly from source.
If you have those files somehow (if so, please provide where you got them from please), you can skip the next step.
Building from source
For CPU version I have used /pytorch/scripts/build_mobile.sh file, you can base your version off of this if GPU support is needed (maybe you only have to pass -DUSE_CUDA=ON to this script, not sure though).
Most important is cmake's -DBUILD_SHARED_LIBS=OFF in order to build everything as static library. You can also check script from my tool which passes arguments to build_mobile.sh as well.
Running above will give you static files in /pytorch/build_mobile/install by default where there is everything you need.
CMake
Now you can copy above build files to /usr/local (better not to unless you are using Docker as torchlambda) or set path to it from within your CMakeLists.txt like this:
set(LIBTORCH "/path/to/pytorch/build_mobile/install")
# Below will append libtorch to path so CMake can see files
set(CMAKE_PREFIX_PATH "${CMAKE_PREFIX_PATH};${LIBTORCH}")
Now the rest is fine except target_link_libraries, which should be (as indicated by this issue, see related issues listed there for additional reference) used with -Wl,--whole-archive linker flag, which brought me to this:
target_link_libraries(example-app PRIVATE -lm
-Wl,--whole-archive "${TORCH_LIBRARIES}"
-Wl,--no-whole-archive
-lpthread
${CMAKE_DL_LIBS})
You may not need either of -lm, -lpthread or ${CMAKE_DL_LIBS}, though I needed it when building on Amazon Linux AMI.
Building
Now you are off to building your application. Standard libtorch way should be fine but here is another command I used:
mkdir build && \
cd build && \
cmake .. && \
cmake --build . --config Release
Above will create build folder where example-app binary should be now safely located.
Finally use ld build/example-app to verify everything from PyTorch was statically linked, see aforementioned issue point 5., your output should look similar.

What is the purpose of additional CGAL targets that are generated by cmake

I have installed CGAL and added it to myProject via cmake:
find_package(CGAL REQUIRED)
target_link_libraries(myProject PRIVATE CGAL::CGAL)
I can use CGAL in myProject without problems, however it adds the following targets in cmake (or in Visual Studio the respective projects to my solution):
Continuous, Experimental, Nightly, NightlyMemoryCheck
I wasn't able to find any documentation on what their purpose is. The "How to use CGAL with CMake" wiki page doesn't mention them either.
The names could suggest that they might be used if one wants to contribute to CGAL. Is that correct or do they have another purpose? Can these targets be disabled if I don't need them?
Those targets are created by the CTest module of CMake, that CGAL includes. Actually, it should not include it because CGAL does not really uses it. My mistake. The pull-request CGAL/cgal#3657 will fix that in the development branch of CGAL, and soon in CGAL-4.14.

Handling unresolved platform-dependent dependencies in biicode

I've tried to add biicode support to the the testing library Catch and had some problems with external dependencies related to Objective-C and Microsoft Foundation Classes (MFC).
The following is printed if running bii deps:
florianwolters/catch depends on:
system:
algorithm
assert.h
cmath
cstddef
cstdio
cstring
fstream
iomanip
iostream
iterator
limits
map
memory
ostream
set
sstream
stdbool.h
stdexcept
stdint.h
stdlib.h
streambuf
string
sys/time.h
sys/types.h
unistd.h
vector
windows.h
unresolved:
AfxWin.h
Foundation/Foundation.h
objc/runtime.h
sys/sysctl.h
The three files sys/sysctl.h, objc/runtime.h and Foundation/Foundation.h are related to iOS development in Objective-C. The file AfxWin.h is part of the C++ library Microsoft Foundation Classes (MFC) from Microsoft. The biicode block I've created is florianwolters/catch (for further information).
So the question is: How-to deal with such dependencies? It does not make sense to upload source code owned by Apple or Microsoft (it may even be illegal) to bicode, though I haven't checked the licenses yet.
Is the "proper" or recommended way to simply ignore such unresolved issues?
EDIT 2015-01-11:
I've written a blog post about the process here. Please let me know, if I did any mistakes or if you have any suggestions for improving the workflow.
Yes, at the moment it is the proper way. Biicode has pre-defined some system headers, the basic ones for Win and Nix platform, but not all of them. Typically OSX or other specific headers as MFC will not be found in biicode and then will be marked as unresolved.
This is not a problem at all. The same happens for your own libraries. If you wan to use any of your system-installed libraries, you can do very easily as usual (in CMake with Finders, or Imported targets). Biicode will mark included headers for that library as unresolved, which is the way to indicate that it is not managed by biicode. As long as those headers are present in your machine, everything will work fine.