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.
Related
I have recently started learning meson and I am testing switching to it (from CMake) in one of my projects. The problem is that I usually use cpack to build the project's packages/installers, and after scouring the meson docs for something similar to cpack I am unable to find anything.
Requirements/what I currently use cpack for
Single script to automatically build and package binary releases (such as deb, rpm, windows installer, etc)
Integrates with the build system - Picks up targets automatically, doesn't require redefining installation logic or structure
Supports building at least deb packages and a windows installer (don't care which)
There is the information on building release archives and then using scripts to process them with packaging tools (such as inno). However, this is not really what I am looking for as it is far more awkward and inflexible than cpack (i.e I have to change 3 different scripts if the directory structure changes).
Ultimately I can learn to use the meson system and manually write packaging scripts, no doubt it will make me a better scripter, however, I am eager to know if there is a better way of doing this which is not advertised in the docs or if there is some unofficial project which will automate the process.
Edit
By package I mean like a deb package - a package for a system package manager, not something like conan
I suggest that you use conan. Please take a look at conan configuration in the Meson.
It might be worth considering using meson rpm packaging module RPM module:
It autodetects installed files, dependencies and so on
This module as of now supports only generation of RPM spec file:
rpm = import('rpm')
rpm.generate_spec_template()
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.
JetBrains has spoiled me. I'm familiar with the standard UNIX make file and the make, make install routine normally associated with installing software with traditional make files, but I'm not as familiar with cmake since CLion does it all for me.
I want to distribute my code to others and provide simple instructions for building it via cmake so that they have a binary they can execute. The official cmake tutorial shows writing install rules in the CMakeLists.txt file but it isn't clear if this is supported by CLion (or even if it needs to be).
For a simple, single-file (main.cpp) application, what would be an example of how to build it using cmake (assuming those it is distributed to don't have CLion nor use another IDE, they just want to build and use it)?
To build code that comes with a CMakeLists.txt file, you run cmake to generate a Makefile (or other build configuration file):
cmake <path_to_CMakeLists.txt>
Then you run
make;make install
as usual. (or as described in the comment, you can type cmake --build . instead of make - useful if you're on a platform with a different build system)
You don't want to check in the Makefile into your source control, though, as it needs to be generated on the computer that will actually be doing the building.
I'm trying to create an Open Source C++ project. I want it to be as easy to build as possible, but at the same time cross platform.
I don't need gui or heavy libraries like boost or Qt, so I've settled on using GitHub, CMake, and LibSourcey.
My problem is, I can't find a way to make my project easy to build in windows, which is my development environment.
How can I "make install" a library in Windows for use in my project? Do I even have to install it in windows?
Is it possible to download, build, and link it automatically?
On windows, besides an installer, I also want to make a portable version, so don't want any hard coded library paths.
I assume, on some platforms, like Linux, libraries are built separably and packaged up by maintainers. So I shouldn't just bundle up my own copies.
So, my question is:
How can I set up a project that is cross platform and easy to build, and what are the best practices?
You can create git submodule in your git repo with path for example
contrib/LibSourcery and url to github repo of LibSourcery, because of LibSourcery uses cmake you just
need add such line into your CMakeLists.txt: add_subdirectory(contrib/LibSourcery)
So person who want to use your code, just do git clone --recursive url
to get all of your code and dependencies, after that it run cmake -G, to create project for IDE of his choice (including MSVC++ of course),
open project in IDE and press build button, that's all.
Use babun. It's a wrapper for cygwin and it works perfectly for everything I need, even compiling with cmake.
Alternatively, you could use premake, which uses lua as a config system and works fine on windows.
There is no elegant cross-platform way, since the idea of "make install" doesn't exist on Windows, therefore the use of cmake install is undefined there. For something which is supposed to help cross-platform, I feel this is a deficiency w cmake.
My solution is to write a custom _INSTALL which takes the same args as cmake install and then on Linux it just calls install, and on Windows it does an add_command which does a post-build copy to the install paths, which accomplishes the same thing. Basically, _INSTALL behaves the way you expect a cross-platform install command to behave. Can share my _INSTALL func if there is interest.
_INSTALL is placed nto a Helper.cmake, and included in all my CMakeList.txt for my projects, so all I need to do is call it and the generated lib/inc files magically appear for both win and linux.
You can use vcpkg, an open source package manager for c and c++. It allows to easily download and compile libraries and then use find_package from within CMake like you would on linux. It's very easy to use. It even provides hints as to how to alter your cmake file to use the libraries.
I started by installing packages with the command line, and then wondered why they wouldn't show up in visual studio. But I realized that it would download 32 bit libraries by default. Use .\vcpkg install <libname>:x64-windows if you need the 64 bit libraries.
After running the integrate command, you will need to delete any cmake caches to have MSVS use the new toolchain.
I'm trying to install cross-compiler using that tutorial .
I got stuck cross-compiling GCC version 4.9.1 using my native linux-GCC compiler. I occured an error during the installation and the solution is to build it in non-source directory. However, I have no idea how can I do it. I've read the documentation. However, it hasn't helped me.
I just want to install C++ and C version.
I haven't done this for ages but I think it means create a new empty directory and run configure from there, i.e. rather than
cd /usr/src/crosscompiler
./configure ...
do
mkdir /usr/src/crosscompiler-build
cd /usr/src/crosscompiler-build
/usr/src/crosscompiler/configure ...
which will then set up the build environment and make files in that new directory to use the source tree from the old directory. (If that doesn't work, you could try putting the empty directory inside the source tree, e.g. /usr/src/crosscompiler/build)
That all said, I thought a separate build directory has been the only way to build GCC for 10+ years, so I'm surprised the tutorial says anything different. You can build binutils into a separate path too, and there are ways of combining the GCC and binutils sources so that they can be built in one go too.