In several projects I have seen the Makefile.in without Makefile.am . E.g. bash http://git.savannah.gnu.org/cgit/bash.git/tree/ and dtach http://dtach.cvs.sourceforge.net/viewvc/dtach/dtach/
I always thought that Makefile.in was generated by automake. Also with Makefile.am being a user written file I would not have thought it would be omitted from the code repository. In the bash source tree, the Makefile.in is far too big to be hand written and the Makefile.in in dtach also looks generated. How was the Makefile.in generated in projects like these two?
The libtool and automake autotools can be used independently of one another (or not at all), depending on what you need autoconf to do. Therefore, it's not required to use automake to generate Makefile.in.
The automake tool also conspicuously outputs that it has been used:
# Makefile.in generated by automake 1.11.1 from Makefile.am.
So it's likely that the Makefile.ins you have seen are edited "by hand".
A Makefile.in looks like a regular Makefile but usually it expects to be completed by the configure script (for example with the location of a library that the user has in a different directory).
Makefile.am is used by Automake to build such a Makefile.in. If the developers that made the package you're using already had a Makefile and writing a Makefile.am for it was too much effort they just converted it to a Makefile.in.
Related
I have a C project I want to integrate with Lua.
This project has to be built on multiple platforms, so I want to build Lua in-tree with the rest of the C code, instead of depending on the system's Lua installation. Previously, we were using ax_lua macro to configure the system's Lua dependency, but I want to remove it and build Lua with the rest.
Unlike the other parts of the project, Lua already has a Makefile, and I don't want to convert this to Makefile.am just to get it converted back to Makefile.in then Makefile (unless, this is the only way.) Rather, I'd want something to the effect of running make inside the Lua folder and the rest of the build to proceed with the appropriate env vars (LUA_INCLUDE, LUA_FLAGS, LUA) set. To which files (configure.ac or Makefile.am) and what lines should I add to?
project/
lua-5.3.6/
Makefile
src/
a.c
b.c
configure.ac
Makefile.am
...
Rather, I'd want something to the effect of running make inside the
Lua folder and the rest of the build to proceed with the appropriate
env vars (LUA_INCLUDE, LUA_FLAGS, LUA) set. To which files
(configure.ac or Makefile.am) and what lines should I add to?
Unless you are willing to do it manually, it doesn't fit very well to try to build Lua before configuring the project. Moreover, even if you did build Lua manually in advance, unless you also installed it to the build system, it would be pretty optimistic to suppose that the macros from ax_lua would work as intended.
If instead you are content to build Lua via a recursive make during the overall project build, however, then the thing you're looking for is Automake's SUBDIRS variable. As its documentation describes, the subdirectories to be built do not have to be Automake-based. They just have to have makefiles (after configuration). The documentation also lists which targets the top-level makefile might try to build in the subdirectory, but it's not necessarily a showstopper if the subdirectory makefile does not support all of them. You would add this to your Makefile.am:
SUBDIRS = lua-5.3.6
The environment variables are a different question, whose answer depends in part on how the project depends on them. Probably you can just set the one you need (as make variables) in your Makefile.am. Since you are taking control of the Lua build, you can determine the needed values in advance. Everything in your Makefile.am is copied into the configured Makefile, so you don't need to do more to get those variables to the ultimate make.
For example, something along these lines might suffice:
LUA_INCLUDE = -I$(srcdir)/lua-5.3.6
LUA_LIB = lua-5.3.6/liblua-5.3.6.a
You might also consider dumping the variables in favor of just hardcoding the values, which, after all, will no longer vary.
I have to create SOAP services in C using axis2C. But since axis2C is kind of not maintained properly as per this question, I have to use axis2C unofficial source code. But I could not see configure file to build the sources. How should I build this. I checked all the documentation both in here and in the github repo but no luck. All points to the axis2C official documentation. Should I copy the sources from unofficial to official code and try with the configure script in official folder ?
This project probably uses the GNU build system. In this system, ./configure is a portable shell script that is automatically generated from hand-written input files, the main file is configure.ac.
So, distribution packages of the source will contain ./configure, therefore enabling anyone on any platform with a sh-compatible shell and a make utility to build the software. But as it is a generated file, you will not find it in source-code repositories, e.g. on github.
To build a package using the GNU build system directly from source controls, you have to use the GNU autotools yourself to generate ./configure. In order to do this, install the following packages:
autoconf -- generates ./configure from ./configure.ac.
automake -- generates portable makefile templates Makefile.in from Makefile.am (those templates are then filled with values by the ./configure script to write the final Makefiles)
libtool -- tools for building dynamic shared objects on different platforms
Then, the command autoreconf -i given in the root of your source package should generate the ./configure script for you.
Note that there are packages providing a script ./autogen.sh (or similarly named). If this is there, you should call it instead of running autoreconf -i yourself, it might contain additional necessary preparation steps. ./autogen.sh will typically directly run the generated ./configure for you.
it is awkward, but until now i always copy the *.h and the *.c files to my projekts location. this is a mess and i want to change it!
i want to build my own c library and have a few questions about it.
where should i locate the *.h files?
should i copy them in the global /usr/include/ folder or should i create my own folder in $HOME (or anywhere else)?
where should i locate the *.a files and the *.o files and where the *.c files.
i am using debian and gcc. my c projects are in $HOME/dev/c/.
i would keep my lib-sources in $HOME/dev/c/lib (if this is the way you could recommend) and copy the *.o, *.a and *.h files to the location i am asking for.
how would you introduce the lib-location to the compiler? should i add it to the $PATH or should i introduce it in the makefiles of my projekt (like -L PATH/TO/LIBRARY -l LIBRARY).
do you have anny further tips and tricks for building a own library?
I would recommend putting the files somewhere in your $HOME directory. Let's say you've created a library called linluk and you want to keep that library under $HOME/dev/c/linluk. That would be your project root.
You'll want a sensible directory structure. My suggestion is to have a lib directory containing your library and an include directory with the header files.
$PROJECT_ROOT/
lib/
liblinluk.so
include/
linluk.h
src/
linluk.c
Makefile
Compiling: When you want to use this library in another project, you'd then add -I$PROJECT_ROOT/include to the compile line so that you could write #include <linluk.h> in the source files.
Linking: You would add -L$PROJECT_ROOT/lib -llinluk to the linker command line to pull in the compiled library at link time. Make sure your .so file has that lib prefix: it should be liblinluk.so, not linluk.so.
A src directory and Makefile are optional. The source code wouldn't be needed by users of the library, though it might be helpful to have it there in case someone wants to remake the .so file.
As I commented, you should try first to build and install from its source code several free software libraries, e.g. like libonion or gdbm or GNU readline etc (don't use any distribution package, but compile and install these from source code). This will teach you some good practice.
You probably want to install these libraries system-wide, not for your particular user. Then, assuming that your library is called foo (you need to give it some name!),
the header files *.h go into /usr/local/include/foo/
the shared objects (dynamic libraries) go into /usr/local/lib/libfoo.so (with perhaps some version numbering)
if relevant, static library go into /usr/local/lib/libfoo.a
You need to add once /usr/local/lib/ into /etc/ld.so.conf and run ldconfig(8)
and you usually don't want to copy any source file *.c or object file *.o
(except for homoiconic programs, bootstrapped compilers, Quine programs, generated C code, etc... See RefPerSys or Jacques Pitrat systems as an incomplete example of self generated C or C++). In some weird cases, you may want to copy such "source" or "generated C" code under /usr/src/.
Read Program Library HowTo (and later, Drepper's paper: How To Write Shared Libraries)
You could consider making your library known by pkg-config. Then install some foo.pc under /usr/local/lib/pkgconfig/
BTW, I strongly suggest you to publish your library as free software, perhaps on github or elsewhere. You'll get useful feedback and could get some help and some bug reports or enhancements.
You probably should use some builder like make and have an install target in your Makefile (hint: make it use the DESTDIR convention).
I've installed mingw and msys by using mingw-get-setup.exe. I've also installed Autotools(autoconf, automake,m4,libtool) into C:\/opt/autotools.
When I run automake, the following error always occurs:
configure.ac:11: error: required file './ltmain.sh' not found
If I copy ltmain.sh from libtool’s installed tree, execution will finish normally.
How can I configuure automake to find ltmain.sh without copying?
In an autoconf/automake/libtool project you need to run:
libtoolize: this copies/links a few support scripts, including ltmain.sh (which is the main component of libtool).
aclocal: this looks up all m4 macros that your configure script will need, and make a local copy for easier access.
autoheader: optional, if you want to use config.h/AC_CONFIG_HEADERS, otherwise all the test result macros will be inlined when you call the compiler.
autoconf: to expand all the macros used by configure.ac into the configure script.
automake: to convert all the Makefile.am into Makefile.in templates. You probably want to invoke this with --add-missing so additional support scripts can be linked/copied to your project (such as compile, missing, depcomp, test-driver, etc).
Don't worry about running each tool. Just invoke autoreconf -i and it'll run the tools that are needed. Add -v if you want to see what tools is being executed. To avoid mistakes, just put a script like this at the root of your project:
#!/bin/bash -x
mkdir -p m4
exec autoreconf --install "$#"
Users that checkout/clone the project directly from the source repository will need to run this ./bootstrap script at least once. This is not needed if the user got a tarball distribution.
Automake can take fairly good care of itself; it'll re-invoke the above tools when needed, when you run make. But if you generate a broken Makefile, you'll need to invoke ./bootstrap and ./configure again to generate new Makefiles.
As DanielKO stated, ltmain.sh is created by libtoolize.
However, what if it doesn't?
The following requirements need to be met:
configure.ac must exist and contain at least one of:
AM_PROG_LIBTOOL,AC_PROG_LIBTOOL,LT_INIT
(see function func_require_seen_libtool in /usr/bin/libtoolize)
If configure.ac does not contain a AC_CONFIG_AUX_DIR, libtoolize will look for a file called 'install-sh' or 'install.sh' in ., .. and ../.. and if found use that as "auxdir" and install ltmain.sh there (see function func_require_aux_dir inside libtoolize).
In my case, I was working on an "example project" in a subdirectory of another project, and the example project did not have a AC_CONFIG_AUX_DIR in its configure.ac; therefore libtoolize found the root of the parent project and installed ltmain.sh there instead of in the example project's root.
I'm trying to use autotools to create a build system for a C program. However, after reading info automake, I'm still very confused about the order of which tools are invoked by the developer.
Let's think about a very simple hello world application. In the root dir of the application there is simple src/hello.c and nothing else. What tools need to be called in what order to create configure and a Makefile?
I figured out by myself (partially reading doc, partially just trying) that autoscan comes first and generates a "sketch" of the configure.ac. Then autoheader appearently creates a header file (why?). Next autoconf finally creates the configure script, which will ultimately create a config.h.
However, I am still missing a Makefile which I believe is created by automake, but this requires a Makefile.am which I don't know how to generate. Is this file generated at all or hand-written by the developer?
The functionality of the autotools tends to blur at the edges. There's a decent flow chart describing the ordering here. The Makefile.am is typically hand-written. Many projects keep a simple shell script at the top-level of the source tree, i.e., autogen.sh or initgen.sh. The autogen.sh I use:
#! /bin/sh
case `uname` in Darwin*) glibtoolize --copy ;;
*) libtoolize --copy ;; esac
aclocal -I m4 --install
autoheader
autoconf
automake --foreign --add-missing --force-missing --copy
This is still one of the best practical guides I've seen. I believe it's available in book form too.
Your Makefile.am should look something like
bin_PROGRAMS = hello
AUTOMAKE_OPTIONS = foreign
hello_SOURCES = src/hello.c
Run automake and it will create a Makefile.in