How to use autotools for deep projects?

0
votes

I have a C project that has the following structure

Main/
  Makefile.am
  bin/
  src/
     Makefile.am
     main.c
     SomeLibrarySource/
         SomeFuncs.c
         SomeFuncs.h

The main.c contains the main function that uses functions defined in the SomeFuncs.{h/c} files.

I want to use autotools for this project. I read a couple of resources on autotools. But, I was only able to manage using autotools for a single level project where all source, object and other files reside in the same directory.

Then I got some links that talked about using autotools for deep projects like this one and then I got confused.

Right now I have two Makefile.am as follows

Makefile.am

SUBDIRS=src

src/Makefile.am

mainprgdir=../
mainprg_PROGRAMS=main
main_SOURCES=main.c

I am pretty sure that these files should not be as I have them now :P

How do I use autotools for the above project structure? (At least what should be there in those Makefile.am(s) and where should I place them.

EDIT: One more thing! At the end I would like to have the object files created in the bin directory.

Thanks

2
cautotools
Instead of autotools, write a clean, simple configuration shell script by hand. This will be less effort in the long run. Also, find and read the paper Recursive Make Considered Harmful. It's best if you have a single set of rules linked to a master Makefile at the root of the project. There can be other makefiles, but these are just included by the master one, and contribute to one big tree of dependencies. Do not call make as a command from within Makefile, in other words. - Kaz
Also, you don't have to have a Makefile.am. That is a template file for automake. You can use Autoconf without Automake. An approach that is not bad is to have a Makefile which is not generated. The configurable make variables go into a config.make (generated from config.make.in) and that config.make is include-d from Makefile. If you must use autotools, keep it simple. - Kaz
@Kaz Thanks for your comments. I will take care of these in future projects. For this one, I am doing recursive make, just for the heck of it. Just want to learn how it's done! - Ankit
Don't specify where to put your object files. People might be trying to build your program in a location where the bin/ directory is not writable. If you personally prefer them there, then cd bin && ../configure, but don't force that preference on others. - ptomato

2 Answers

2
votes

mainprogdir=../ does not make a whole lot of sense (you don't know what it is relative to on installation). Probably intended:

# Main/Makefile.am
# .━━ target for `make install`
# |
# ↓              ↓━━ target for compilation
bin_PROGRAMS = bin/main

# ↓━━ based upon compilation target name
bin_main_SOURCES = src/main.c
1
votes

There are two main approaches. If the functions in SomeLibrarySource are used only by main, then there's no need to build a separate library and you can simply specify the source files in src/Makefile.am

main_SOURCES = main.c SomeLibrarySource/SomeFuncs.c

However, if you actually want to use the functions in other code in your tree, you do not want to compile SomeFuncs.c multiple times but should use a convenience library.

# Assigning main_SOURCES is redundant
main_SOURCES = main.c
main_LDADD = SomeLibrarySource/libSomeFuncs.a
noinst_LIBRARIES = SomeLibrarySource/libSomeFuncs.a
AM_CPPFLAGS = -I$(srcdir)/SomeLibrarySource

(You'll need AC_PROG_RANLIB in configure.ac to use convenience libraries.) If the source file is named SomeFuncs.c, automake will not need Makefile.am to specify SomeLibrarySource_libSomeFuncs_a_SOURCES, but if the name of the source code file does not match the name specified in noinst_LIBRARIES, SomeLibrarySource_libSomeFuncs_a_SOURCES should be set to the list of files used to build the library. Note that you do not need to specify main_SOURCES, since main.c is the default value if left unspecified (but it's not a bad idea to be explicit.) (In all of this, I am not comfortable use CamlCase names, but the system I'm using uses a case insensitive file system (biggest mistake apple ever made) and the examples I give here are working for me. YMMV)

You could of course do a recursive make, or build the library as a separate project and install it. (I like the final option. Libraries with useful features should exist on their own.)