I take a look inside the asio folder there are
asio.manifest
autogen.sh
boost_asio.manifest
boostify.pl
configure.ac
include/
INSTALL
src/ (there are asio_ssl.cpp and asio.cpp)
I didn't see any configure script where I can execute. How do I build this asio?
I read asio is a header only library.
So, what I can make out of those files in the asio folder?
If you got it from a tarball, you should already have a configure script ready to be executed. If you checked from the repository, you probably need to run ./autogen.sh to generate the configure script for you, using configure.ac as input.
The convention is:
./bootstrap: it invokes autoconf to process configure.ac and spit out configure. Often it also invokes automake to process all Makefile.am files and turn them into Makefile.in. Many moons ago, the name autogen.sh was used instead of bootstrap. And configure.in was used instead of configure.ac.
./configure: detects everything on the system and creates config.status, then executes it.
./config.status: processes all *.in files into versions without the .in suffix. That includes Makefile.in -> Makefile. You don't have to run this script by hand.
INSTALL: this SHOULD contain build instructions, such as "run ./autogen.sh if you checked out a copy from the repository". Shame on the ASIO developers, they just point the user to look for a non-existing "doc" directory.
You need autoconf (and friends) installed to transform configure.ac into configure. Once that is done, the build system becomes self-contained. That is, you can do a make dist-gzip to pack all the sources (and the configure script), transfer the tar.gz it to another system, and follow from the ./configure step, even if autoconf is not installed there.
So, Here are the steps I've followed just now.
I went to http://think-async.com, which is the website that hosts the non-boost asio.
Their download link led me to sourceforge, and version 1.4.8 of the software.
I then extracted the folder, and looking inside, I see the usual layout.
So the following steps include ./configure, make, and probably sudo make install.
Related
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.
Boost using this build system I'm not otherwise familiar with, based on "Jam" files. Now, I've forked and cloned a specific Boost library (program_options), and I want to build it and perhaps also run the tests. I notice a build/Jamfile.v2 - what should I do with it?
I tried apt-get install jam on my distribution, but that did not get me very far:
$ jam -fbuild/Jamfile.v2
warning: unknown rule project
warning: unknown rule boost-lib
don't know how to make all
...found 2 target(s)...
...can't find 1 target(s)...
Also, do I have to get the absolute latest development version of all of Boost to build the cloned library against, or can I use a local boost release I already have?
Notes:
I'm on a recent GNU/Linux distribution (Mint 18.3 but this shouldn't matter).
What I've done, based on #SergeyA and others' advice, is:
Clone all of Boost, recursively (see this page (this will create a boost/ folder )
cd boost
in .git/modules/my_boost_lib/config, change the origin URL to your fork
in .gitmodules, under [submodule "my_boost_lib"], change the URL to your fork
execute git submodule update --init libs/my_boost_lib/ (perhaps after deleting that library; not sure if that's actually necessary)
cd libs/my_boost_lib/build
../../../b2
The latter works because b2 looks for a Jamfile.v2 in its current working directory, and that file exists and is intended to build just the library. The build results will be located outside of libs/my_boost_lib though.
Note: To build run the library tests, build the same way but from libs/my_boost_lib/test.
Essentially the build steps is
Run bootstrap to build the build tool b2
Build boost with b2 install or similar. You may want to provide options to it.
Read more in the boost getting started document:
http://www.boost.org/doc/libs/1_66_0/more/getting_started/index.html
(hint, look at lower right to go to next page..)
If you are on windows / VS2017, the use of vcpkg to get boost is very easy.
I'm trying to install Loris package link which is a library also for Python (my language). I have installed the package through bash commands in my OSX 10.12 system following these steps:
cd to the directory containing the package's source code and type
./configure to configure the package for your system. If you're
using csh on an old version of System V, you might need to type
sh ./configure instead to prevent csh from trying to execute
configure itself.
Running `configure' takes awhile. While running, it prints some
messages telling which features it is checking for.
Type `make' to compile the package.
Optionally, type `make check' to run any self-tests that come with
the package.
Type `make install' to install the programs and any data files and
documentation.
You can remove the program binaries and object files from the
source code directory by typing make clean. To also remove the
files that configure created (so you can compile the package for
a different kind of computer), type make distclean. There is
also a make maintainer-clean target, but that is intended mainly
for the package's developers. If you use it, you may have to get
all sorts of other programs in order to regenerate files that came
with the distribution.
The problem is that when I run both python 2.7 IDLE and the Atom editor it says that the module named Loris was not found. By default, make install will install the package's files in
/usr/local/bin,/usr/local/man.
Is this the problem? How can I install properly this library?
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 got a C project to compile and run in Linux. It is a very big project with many subdirectories. Inside the parent directory there are files Makefile.am and Makefile.in.
I tried running make -f Makefile.am, and got the following error:
make: Nothing to be done for `Makefile.am'.
What does it mean? How do I accomplish my task?
These files are used with the Autotools suite. Makefile.am files are compiled to Makefiles using automake.
Have a look to see if there is a configure script in the directory. If there is, then type:
./configure
If not, then run:
autoreconf
in the directory, which should create the configure script (you will need to have the Autotools suite installed to run this).
After that, you should have a configure script that you can run.
After the configure is complete, you should have a normal Makefile in the directory, and will be able to run
make
What has been left out:
Makefile.am are transformed to Makefile.in using automake.
Makefile.in are transformed to Makefile by running configure.
Neither of these (Makefile.{am,in}) are supposed to be used with make -f.
If the tarball already ships with configure, just run that and make. If it does not, run ./autogen.sh or bootstrap(*). If that does not exist, use autoreconf instead.
(*) autogen/bootstrap: A convenience script added by developers that should just call autoreconf. Unfortunately there are some people that eschew autoreconf and unnecessarily call all the lowlevel commands themselves.
To supplement what has already been said:
Search for a script called configure in the project directory. If it is there, building the project will be:
./configure
make
and optionally, to install:
sudo make install
or su -c "make install"
Even if there is no configure script. there might be one autogen.sh. Run this script to generate the configure script and do as above.
Makefile.am is probably to be used with automake.
try:
automake
you might also just want to try
make -f Makefile.in
Since this is the product of running automake