How to compile C++ gRPC code for Android? I have seen several tutorials on how Protobuf itself can be compiled using the Android Native Development Kit, such as in the answer from Swapnil: How to integrate/install latest c++ protobuf (3.2) with Android NDK?
Or Google protobuf and Android NDK
But how to How to compile C++ gRPC code that is using Protobuf as well for Android? Taking into account that there's 20K lines of gRPC Makefile.
I do it with dockcross (which does not do anything fancy, it just sets up the toolchain in a convenient way).
Say for android-arm (but it works for android-arm64, android-x86 and android-x86_64 just the same):
$ git clone https://github.com/grpc/grpc --recursive
$ cd grpc
$ docker run --rm dockcross/android-arm > ./dockcross-android-arm
$ chmod +x dockcross-android-arm
$ ./dockcross-android-arm cmake -DgRPC_BUILD_CODEGEN=OFF -Bbuild -S.
$ ./dockcross-android-arm cmake --build build
It will build all the dependencies in the gRPC submodules. It should work in your project if you add gRPC as a submodule (well, up to some point depending on your transitive dependencies situation, I guess).
This said, I am not a big fan of using git submodules for dependencies with CMake. Instead I like to build the dependencies separately and have my project find them with find_package. I explain that in more details here, and more importantly I have an example doing exactly that for gRPC here.
I've done it here.
In brief: git submodule gRPC C++, add "CMakeLists.txt" file to your project on how to build C++ gRPC (and your code that uses it), add a externalNativeBuild/cmake it to your "build.gradle" - voila!
Related
I'm working on c++ project on a linux machine and it uses several boost libraries. I've installed them on my system using vcpkg and build it using the toolchain provided by vcpkg. My question is:
How do I define the dependencies so that they automatically install on a different system, if they were to build it?
Conan has a way of doing it by defining the dependencies in conanfile.txt. How do I do the same with vcpkg?
Edit1: I've found autovcpkg which does the job I'm looking to do but can the same be done natively inside cmakelists.txt or by vcpkg itself?
If you have vcpkg as a submodule for your project, define a manifest for the libraries you want vcpkg to build, and are using the vcpkg CMake toolchain - then you will get everything you want.
Adding vcpkg as a submodule means that your users don't need to install it themselves, the CMake toolchain will install it on your behalf. It also means that you can fix the package versions
Using a manifest file is how you programmatically tell vcpkg which packages to get and build during a CMake configuration phase
Using a CMake toolchain file is the only way to tie this into your project's build system
$ git clone .../my_project
$ cd ./my_project
$ git submodule update --init
$ mkdir ../build
$ cd ../build
$ cmake ../my_project
-- Running vcpkg install
-- Running vcpkg install - done
...
I've found autovcpkg which does the job I'm looking to do but can the same be done natively inside cmakelists.txt or by vcpkg itself?
You can write a vcpkg port for your library or executable by providing a CONTROL and portfile.cmake file. In the CONTROL file you define all the dependencies and possible features while the portfile contains the build instruction. You can use vcpkg create <myport> <url> <filename> to create the CONTROL and portfile.cmake from a template which can be customized to your needs.
Together with a port-overlay this port can also be used by others without being merged into vcpkg/master
This question already has answers here:
Confused about configure script and Makefile.in
(2 answers)
Closed 4 years ago.
I saw a common pattern when installing a c/c++ package from source on Linux (Ubuntu 16.04):
./autogen.sh
./configure
make
make install
I understand make and make install, and I guess configure creates a Makefile based on user preferences, but I don't see why autogen.sh is necessary.
Does anyone know what it is there for?
The steps:
The autogen.sh script generates the configure script (from configure.ac, using autoconf) and any files it needs (like creating Makefile.in from Makefile.am using automake). This requires autotools to be installed on your system, and it must be run when checking out the project from source control (if configure isn’t checked in). People who download source tarballs can usually skip this step, because output of this step is included in source tarballs.
Note This is usually equivalent to autoreconf --install. If there is not autogen.sh file, then just run autoreconf --install instead. If you have inherited a project with an autogen.sh, consider deleting it if you can use autoreconf --install.
The configure script generates Makefile and other files needed to build. Typically Makefile.in is used as a template to generate Makefile (and config.h.in to generate config.h). This process happens using only standard tools installed on your system, like sed and awk, and doesn't require autotools to be installed.
The make command builds the software.
The make install command installs it.
These are broken into different steps because they are often run at different times. The autogen.sh step is traditionally run by people who are developing the software, since they are expected to install autoconf on their systems and they make changes to configure.ac. End-users are not expected to have autotools installed.
These expectations have been changed a bit now that end-users are more likely to check a project out of source control instead of downloading source releases.
This applies only to programs / libraries, which are built using the autotools build chain. It generates the files, which are configured by the configure script. The configure script then populates .in files and generates Makefiles from Makefile.am templates. Which can finally be used to compile, link and install the program / library.
It's becoming slowly obsolete with the move to multi platform packages. CMake and more modern tool chains are state of the art.
I am working on an Ubuntu 16.04 system and tried to compile an application with the qm command as per the readme file in the source directory. When I try to run the command I get the repose:
$ qm
qm: command not found
This suggests that my Ubuntu PC does not have a repository with a package that supplies a qm executable setup. I guess the source code for the tool may be available somewhere and be usable for multiple GNU Linux operating systems.
How do I source and install the qm executable?
The readme file for the code I am trying to compile states that qm stands for quick-make or QMake but I cannot find any reference to these in a google search. I only find references to Qt's qmake which is not the tool I am looking for based on the errors I get back.
This qm tool uses a defs.mk file as its instruction set.
The program I am trying to install uses the RAVL Library. The README file for that library also mentions qm command.
I found a source for the qm or QMake or Quick Make tool. In the Recognition And Vision Library (RAVL) Installation Instructions the installation of QMake is mentioned.
Building the RAVL library requires the use of an ANSI C++ compiler
along with the GNU make utility (or another compatible version of
make). The RAVL build process is actually managed by the QMake
utility. QMake is a flexible compilation aid, designed to provide a
simpler interface to the GNU make program. As part of the RAVL
installation process, a copy of QMake will be configured and
installed.
The instructions go on to explain that by; obtaining a copy of the RAVL source code, configuring, making and installing it you get both the RAVL libary and the quick-make tool set. This includes the qm command.
After preforming the following steps:
git clone -b tested_nightly git://git.code.sf.net/p/ravl/ravl ravl
cd ravl
./configure
make
sudo make install
I am able to use the qm command.
I am new in Ubuntu/Linux and I've been working with java using the NetBeans IDE, so I don't have much experience with building c++ projects. But now I have to provide a proof of concept and I need to connect a C++ client with my ActiveMQ server. I downloaded The ActiveMQ-CPP API from this link, but I can't build/run it.
The download came with the files: Maklefile.am and Makefile.in. I searched it and I found that I need automake/autoconf to build it. I tried running ./configure but it says that it couldn't find such file or directory. I tried
sudo apt-get update
sudo apt-get install automake
sudo apt-get install autoconf
and a lot of other commands that I found on the Internet. None of then worked. I know that this question is really basic and it seems to be already answered somewhere else, but every attempt I've made failed. I think I'm missing something. I even tried the solution provided in the last message in this topic but it didn't work either.
Can anyone help me install autoconf/automake, or tell me how to use Makefile.am / Makefile.in to build the project I downloaded, or even suggest me some other way of building it?
Since you're open to other methods of building your project, I'm going to suggest CMake. It is a far better build system than autotools (at least from where I stand).
#CMakeLists.txt
project(MyProject CXX)
set_minimum_required(VERSION 2.8)
add_executable(foobar foo.cpp bar.cpp)
That example will build an executable called "foobar" by compiling and linking foo.cpp and bar.cpp. Put the above code in a file called CMakeLists.txt, then run the following commands:
cmake <path to project> #run in the folder you want to build in
make #this does the actual work
The really cool thing about CMake is that it generates a build system (Makefiles by default) but you can use it to generate project files for Eclipse, a Visual Studio solution, and a bunch of other things. If you want more information, I'd check out their documentation.
The "configure" script should be in your ActiveMQ-cpp source directory. From the Linux command line, you should be able to:
1) "cd" into your ActiveMQ* directory
2) "ls -l" to see the "configure" script
3) "./configure" to set things up for building the library\
4) "make" to actually build the library
This is mentioned in comments, but this particular point of confusion has been common for well over a decade and I think needs to be clarified as often as possible. You DO NOT need to have autoconf or automake installed to build a project that used those tools. The entire point of the autotools is to generate a build system that will build on a system using only the standard tools (make, a c compiler, sh, and few others.) Unfortunately, many developers release tarballs that do not build cleanly. If you unpack the tarball and it does not contain a configure script, or if the configure script is broken, that is a bug in the package. The solution is absolutely not to install autoconf/automake/libtool and try to produce a working configure script. The solution is to report the build error as a bug to the package maintainer.
The world would be a better place if Linux distributions stopped installing multiple versions of the autotools by default as less than .002% of the population needs those tools, and anyone who actually needs to have the tools should be capable of installing it themselves. Anyone incapable of acquiring and installing the tools has no business using them.
I just download poppler to Linux system,and I want to incorporate it in my app to parse pdf file.
(My goal is to convert pdf file to plain text.)
How can I do this?
Poppler's git tree includes a useless INSTALL doc that just tells you to run ./configure, but they don't include automake/autoconf auto-generated files (including configure) in git. (Probably they do include them in tarball source releases.)
I just built poppler from git source (on Ubuntu 15.04) like so:
git clone --depth 50 --no-single-branch git://git.freedesktop.org/git/poppler/poppler
cmake -G 'Unix Makefiles' # other -G options are to generate project files for various IDEs
# look at the output. If it didn't find some libraries,
# install them with your package manager and re-run cmake
make -j4
# optionally:
sudo make install
It appears that they maintain an autoconf/automake build setup, so you can use that OR cmake to create a Makefile.
If you just want to see if the latest git poppler works better than the distro package, you don't need to sudo make install, you can just run utils/pdftotext or whatever right from the source directory. It apparently tells the linker to embed the build path into the binary, as a library search path, so running /usr/local/src/poppler/utils/pdftotext works, and finds /usr/local/src/poppler/libpoppler.so.52.
If the latest poppler does work better than the distro-packaged poppler, you should install it to /usr/local/bin with sudo make install. When you upgrade to the next version of your distro, check your /usr/local. Often the new distro version will be newer than when you built it from source, so you should just remove your version from /usr/local/{bin,share,lib,man,include}. (Or make uninstall in the source dir, if supported).
Their website explains it very clearly :
Poppler is available from git. To clone the repository use the following command:
git clone git://git.freedesktop.org/git/poppler/poppler
Once you download the source code, read the INSTALL file where it says :
cd to the directory containing the package's source code and type
./configure to configure the package for your system.
Type `make' to compile the package.
Type `make install' to install the programs and any data files and
documentation.
Since some time has passed and it seems there was some uncertainty, I also took a look.
At the end of 2021, their homepage says
We run continuous integration via the gitlab CI
I checked out their .gitlab-ci.yml which has many build tasks. It would seem these days we build libpoppler like this:
git clone git://git.freedesktop.org/git/poppler/test test.repo
mkdir -p build && cd build
cmake -DTESTDATADIR=`pwd`/../test.repo -G Ninja ..
ninja