How to build google's C++ libphonenumber library for Win32 - c++

Some developers on our team are using the Java and C# versions of libphonenumber, a normalization library for international phone numbers.
They claim it is wonderful/magical/etc.
Unfortunately, being a Win32 C++ developer, my simple mind can't quite grasp all the wonder and magic of the CMake, boost, and host of other libraries and I can't build the library at all.
Can someone provide some hints ot tips or URLs to help point me in the right direction so that we can build this project and make use of it?
The current stumbling block is when trying to run CMake (following the instructions in the very short readme) I get the following error message:
> -- Could NOT find Boost
> -- Configuring incomplete, errors occurred!
I thought I set BOOST_ROOT correctly, but apparently either I set it wrong or I am missing other env vars.
How can I build this library?
We use VS 2008, but I also have VS 2010 on my machine. I would be happy to get a build with either one.

Your CMake may be outdated wrt to the Boost version you installed. Check the file FindBoost.cmake located in the CMake Modules directory. It must contain a section like this:
set(_Boost_KNOWN_VERSIONS ${Boost_ADDITIONAL_VERSIONS}
"1.46.1" "1.47" "1.47.0"
"1.46.0" "1.46" "1.45.0" "1.45" "1.44.0" "1.44" "1.43.0" "1.43" "1.42.0" "1.42"
"1.41.0" "1.41" "1.40.0" "1.40" "1.39.0" "1.39" "1.38.0" "1.38" "1.37.0" "1.37"
"1.36.1" "1.36.0" "1.36" "1.35.1" "1.35.0" "1.35" "1.34.1" "1.34.0"
"1.34" "1.33.1" "1.33.0" "1.33")

You can try to pass BOOST_INCLUDEDIR and BOOST_LIBRARYDIR to the compiler; this way you can totally bypass the cmake module search.

Change Boost_ADDITIONAL_VERSIONS in FindBoost.cmake, step that you've already done
Change the CMakeLists.txt from \libphonenumber\cpp, change the line find_package (Boost 1.40.0 COMPONENTS thread)
into
set(Boost_USE_STATIC_LIBS ON)
set(Boost_USE_MULTITHREADED ON)
set(Boost_USE_STATIC_RUNTIME OFF) //since CMake 2.8.3
find_package (Boost 1.47.0 COMPONENTS thread)
3. Run mkdir build in \libphonenumber\cpp, cd build
4. Run cmake -G "your generator" -DBOOST_ROOT="you_path_to_boost_147_0 folder,", ex: cmake -G "Visual Studio 10" ../ -DBOOST_ROOT="E:\libphonenumber\cpp\3rdparty"

Try to compile it using cygwin, it is like a standard UNIX build environment but running on Windows. It usually is a lot easier to compile open source libraries using it than using Visual Studio.

Related

How to install a cpp library using cmake on Windows x64?

I'm using CLion with MinGW-GCC on the Windows-x64 platform - This is the background of the problem.
I was trying to install gtest before. But a lot of confusion arose in the middle.
First time I ran those commands(in googletest-release-1.12.1\) according to the instructions of googletest-release-1.12.1\googletest\README.md:
mkdir build
cd build
cmake ..
But I got error messages like:
CMake Error at CMakeLists.txt:51 (project):
Failed to run MSBuild command:
C:/Windows/Microsoft.NET/Framework/v4.0.30319/MSBuild.exe
to get the value of VCTargetsPath:
Then I changed my last command to
cmake -G "MinGW Makefiles" ..
because I use make provided by MinGW. I don't know whether it's right but, it ran properly.
then I called
make
make install
make ran smoothly. But when I ran make install, I got these messages:
Install the project...
-- Install configuration: ""
-- Installing: C:/Program Files (x86)/googletest-distribution/include
CMake Error at googlemock/cmake_install.cmake:41 (file):
file INSTALL cannot make directory "C:/Program Files
(x86)/googletest-distribution/include": No such file or directory.
Call Stack (most recent call first):
cmake_install.cmake:42 (include)
make: *** [Makefile:109: install] Error 1
I have no idea at all this time. So I changed my way. According to this answer, I copied the whole library into my project and edited CMakeLists.txt like this:
cmake_minimum_required(VERSION 3.23)
project(gtest_study)
set(CMAKE_CXX_STANDARD 20)
add_subdirectory(googletest-release-1.12.1)
include_directories(googletest-release-1.12.1/googletest/include)
include_directories(googletest-release-1.12.1/googlemock/include)
add_executable(gtest_study main.cpp)
target_link_libraries(gtest_study gtest gtest_main)
target_link_libraries(gtest_study gmock gmock_main)
So my questions are:
Is there any difference between the two which build it using make and cmake metioned firstly, and just use commands like include_directories and target_link_libraries in CMakeLists.txt? (maybe like .h and .dll file? Or just completely the same? I don't know)
When I use make install to install a library on Windows, what should I do in particular? Specify some directory (I don't know which one) or what?
Although in my system environment I use MinGW-makefile, in CLion which the libraries are eventually used, I use ninja as the generator for CMake (it just comes with CLion, not installed for the system). Do I have to specify it and how? (-G "Ninja"doesn't work in my native env)
The difference between
cmake ..
and
cmake -G "MinGW Makefiles" ..
Is the choice of generator: The former uses the default generator, the latter uses the generator you specified. (cmake --help should put a * next to the default generator.)
Based on the error message I assume this is a visual studio generator and you may not be able to run that one properly from within a MinGW terminal.
In the latter case the default install directory seems to be based on the target OS (Windows) but does not seem to incorporate the fact that you're running from a MinGW terminal where the default install path (C:/Program Files (x86)/googletest-distribution) is not valid.
You could try to fix this by providing it during cmake configuration (passing -D 'CMAKE_INSTALL_PREFIX=/c/Program Files (x86)/googletest-distribution' before the source dir) or by providing the install directory during the installation.
The following process should allow you to install the lib. I'm using my preferred way of building here, i.e. not using build system dependent commands, but using cmake to run the build/install commands. I assume the working directory to be the root directory of the gtest sources:
cmake -G "MinGW Makefiles" -S . -B build
cmake --build build
cmake --install build --prefix '/c/Program Files (x86)/googletest-distribution'
The last command needs to be run with admin privileges, the first 2 I don't recommend running as admin. You could instead install to a directory where you do have the permissions to create directories even without admin privileges.
The difference between using the process described above and using add_subdirectory is that the former results in a installation on the system which can be used via find_package and the google test libs won't be rebuilt for every project where you do this.
...
project(gtest_study)
...
# you may need to pass the install location via -D CMAKE_PREFIX_PATH=<install_location> during configuration for this to work
find_package(GTest REQUIRED)
target_link_libraries(gtest_study PRIVATE GTest::gtest_main GTest::gmock)
The latter builds the google test project as part of your own project build and for every project where you use this approach a seperate version of the google test libs is built. Note: there should be no need to specify the include dirs yourself, since this kind of information is attached to the cmake target and gets applied to the linking target automatically:
#include_directories(googletest-release-1.12.1/googletest/include)
#include_directories(googletest-release-1.12.1/googlemock/include)
add_executable(gtest_study main.cpp)
target_link_libraries(gtest_study PRIVATE gtest_main gmock)
As for 3.: The CMake generator used for building GTest should be independent of the generator of the project using it. The thing that's important is that the compilers used by the build systems are compatible. I cannot go into detail about this, since I've never used CLion and therefore have too little knowlege about the compilers used by it. (Personally I'm working with Visual Studio on Windows.)

Build uWebSockets on Windows 10 with CMake

I want to use uWebSockets(UWS) in my C++ project to transfer images over the network. The setup will be running on multiple operating systems, so the best way of creating the build files seemed like using CMake.
However, I am new to CMake and having a hard time building UWS. I don't understand how to start working with the official repository on Windows 10, so I found another repository that includes a CMakeFiles.txt file and some of the dependencies (openssl, zlib, libuv, but it doesn't include uSockets for some reason). The root CMakeFiles.txt includes:
[...]
find_package(OpenSSL REQUIRED)
find_package(ZLIB REQUIRED)
find_path(LIBUV_INCLUDE_DIR uv.h)
find_library(LIBUV_LIBRARY NAMES uv uv1)
[...]
It looks straightforward, but when I try to run mkdir build && cd build; cmake .., it cannot find OpenSSL. Here is the error message it spits out:
[...]
[cmake] Could not find a package configuration file provided by "OpenSSL" with any
[cmake] of the following names:
[cmake]
[cmake] OpenSSLConfig.cmake
[cmake] openssl-config.cmake
[...]
The above error message suggests that I need to set up a config file for each of these libraries. Yet, if I understand the find_package docs correctly, the command itself searches the library in various locations under the root folder. What kind of a folder structure does the find_package need in order to work?
More generally, am I wasting my time with this alternative repo? Is there a better way of using UWS with Windows 10? The official repo has a question about how to use it on Windows but I don't understand how that's an answer to the question. It only points to this page where it says any specific build systems will not officially be supported.
Any help would be appreciated.
Importing dependencies with add_subdirectory seems like a good way around this. When I ran cmake, I was receiving LNK2019 Error. I realized the following code snippet I found online was causing the problem, and the system works when I delete it.
if(MSVC)
set(CMAKE_EXE_LINKER_FLAGS_DEBUG "${CMAKE_EXE_LINKER_FLAGS_DEBUG} /NODEFAULTLIB:libcmt.lib /NODEFAULTLIB:msvcrt.lib")
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} /SUBSYSTEM:WINDOWS")
endif()

Using MSYS2 installed libraries in CLION

So I've been wanting to learn C++, I have a student license for CLion and am familiar with other software from the company so I'd want to use it if possible. Using MSYS2 seemed like a good way to easily manage libraries, since that tends to be hellish anytime I tried working with C++.
MSYS2 seemed intuitive enough and I managed to install the OpenCV library as a test. However, I'm now entirely at a loss on how I'd link it with CLion.
I've been reading about CMake files, and this is what I figured should be mine:
cmake_minimum_required(VERSION 3.7)
project(letsee)
set(CMAKE_CXX_STANDARD 11)
find_package (OpenCV REQUIRED)
set(SOURCE_FILES main.cpp)
add_executable(letsee ${SOURCE_FILES})
target_link_libraries( letsee ${OpenCV_LIBS} )
The last line, however, is supposed to link to be an environment variable. I understand that MSYS2 should handle that somehow, or perhaps I should create my own windows environment variable? Either way I'm not even sure to where I'd link such variable. I'm just incredibly confused by this point. How can no one have created an intuitive way to handle this in windows in a 40 year old language.
I just downloaded and setup everything to try it. Here is how it works:
Install MSYS2 and follow the tutorial on their website (pacman -Syu, pacman -Su) - you probably did that already
pacman -S mingw-w64-x86_64-toolchain (you probably did this too)
pacman -S mingw-w64-x86_64-cmake This is the important step. We will use this CMake instead of the bundled one, because this CMake works with MSYS2 pacman libraries
Configure CLion: MinGW: C:\msys64\mingw64 (or similiar), CMake: C:\msys64\mingw64\bin\cmake.exe
CLion might warn you because CMake/GDB are too new. However, I haven't experienced any problems until now
Edit: I actually also tested it with the bundled CMake right now and this worked too, out of the box. So no idea why it doesn't for you.

How to change where CMakeLists.txt looks for Boost Libraries Ubuntu

I was using Boost 1.54.0 and it was located in "/usr/include". We blew that away and installed Boost 1.57.0. It got installed in "/usr/local/include".
Now, my CLion project, which uses CMake cannot find the Boost library. Here is my CMakeLists.txt file:
And here are my errors:
I have no idea how to make CMake look in the correct place for Boost.
According to the FindBoost documentation (http://www.cmake.org/cmake/help/v3.1/module/FindBoost.html), you can set a CMake variable BOOST_ROOT to give CMake a hint about where to look.
In your CMakeLists.txt file, you can add the following before the find_package(Boost...) line:
set(BOOST_ROOT /usr/local)
Update:
I agree with the comments that putting machine specific configuration parameters directly in CMakeLists.txt is not best practice.
As an alternative to directly setting this variable, you can pass options like this to the cmake process in CLion by doing the following:
Navigate to File -> Settings... -> Build, Execution, and Deployment -> CMake. Under Generation, add -DBOOST_ROOT=/usr/local to CMake options.

How to create an installer with CMake + CPack + NSIS on Windows?

I'd like to create a cross-platform installer for a C++ based system I am building.
I use CMake to build everything, and it would be great if I could use CPack to make the installer. I already have CPack working on OSX, but I cannot get it to work on Windows. To make things easier, I tried to get the example at http://www.cmake.org/Wiki/CMake:Packaging_With_CPack to work with the NSIS installer software. I cannot find the NSIS installer anywhere after configuring (with VS 2010 Win64 generator).
Maybe I am confused, but I thought it would be possible to create the installation package with only the source, CMake, CPack, and NSIS without any need for Visual Studio. Is this possible?
A link to a full tutorial (the one at http://www.cmake.org/Wiki/CMake:Component_Install_With_CPack skips over the relevant information to get NSIS working and doesn't mention generators or compilers) would be very helpful, or a basic explanation of how I can get to this mythical generated NSIS installer would be great.
Here is CMakeLists.txt for the example above:
cmake_minimum_required(VERSION 2.6.0 FATAL_ERROR)
project(StPMS)
add_library(mylib mylib.cpp)
add_executable(mylibapp mylibapp.cpp)
target_link_libraries(mylibapp mylib)
install(TARGETS mylib
ARCHIVE
DESTINATION lib
COMPONENT libraries)
install(TARGETS mylibapp
RUNTIME
DESTINATION bin
COMPONENT applications)
install(FILES mylib.h
DESTINATION include
COMPONENT headers)
set(CPACK_GENERATOR NSIS)
set(CPACK_PACKAGE_NAME "MyLib")
set(CPACK_PACKAGE_VENDOR "CMake.org")
set(CPACK_PACKAGE_DESCRIPTION_SUMMARY "MyLib - CPack Component Installation Example")
set(CPACK_PACKAGE_VERSION "1.0.0")
set(CPACK_PACKAGE_VERSION_MAJOR "1")
set(CPACK_PACKAGE_VERSION_MINOR "0")
set(CPACK_PACKAGE_VERSION_PATCH "0")
set(CPACK_PACKAGE_INSTALL_DIRECTORY "CPack Component Example")
SET(CPACK_NSIS_MODIFY_PATH ON)
INCLUDE(CPack)
... I thought it would be possible to create the installation package with only the source, CMake, CPack, and NSIS without any need for Visual Studio. Is this possible?
Kind of. It depends on what you mean by "without any need for Visual Studio". You need a build tool to actually create the lib and exe. On Windows, you need something like Visual Studio's msbuild, especially if you specified "Visual Studio 10 Win64" as the generator.
If you mean "without running Visual Studio", then the answer is yes. You can have CMake execute your chosen build tool using the --build argument.
After running CMake, you end up with a file PACKAGE.vcxproj in your build directory. It is building this which will create the installer. You can either build the PACKAGE project from inside Visual Studio, or you can invoke msbuild directly by doing:
msbuild /P:Configuration=Release PACKAGE.vcxproj
from your build directory in a VS command prompt.
This should yield your installer named MyLib-1.0.0-win64.exe, also in your build directory.
If you want to just use CMake, then an alternative to invoking msbuild is:
cmake --build . --target PACKAGE.vcxproj --config Release
Or you can build the solution first, then invoke CPack to create the installer:
cmake --build . --config Release
cpack -C Release