I am writing a Makefile.am for my autotool package. However I got some problems in generating the dependency files.
bin_PROGRAMS=main
main_SOURCES=src/main.cpp
With the above format the automake can generate the dependency files in a hidden folder src/.deps. However, if I replace src with a variable SRCDIR then the dependency files are put into a folder name "$SRCDIR/.deps".
SRCDIR=src
bin_PROGRAM=main
main_SOURCES=$(SRCDIR)/main.cpp
What's wrong with the second style? I simply replace the src to with a variable but it looks like this variable is not correctly substituted.
Related
Is there a way to create a makefile that does this?
I gave up after trying to follow the docs and lots of trial and error so I'll just post a description of what the makefile should do.
general directory structure:
src/ - contains c source files in various subdirectories (written manually by maintainer)
inc/ - contains h header files in subdirectories matching src (written manually by maintainer)
obj/ - contains o header files in subdirectories matching src (autogenerated by a make call)
bin/ - should contain binary (autogenerated by a make call)
makefile
so for example at a given point of time the project might look like
src/
main.c
sub1/
other1.c
other2.c
sub2/
sub3/
other3.c
inc/
sub1/
other1.h
other2.h
sub2/
sub3/
other3.h
obj/
main.o
sub1/
other1.o
other2.o
sub2/
sub3/
other3.o
bin/
release
makefile
(probably not relevant: Note that main doesn't have a header file but most likely every other c file will have a matching h file.)
I want to be able to call make, and have it:
use gcc to recompile only changed c files into respective o files in obj/, generating missing subdirectories if needed.
for example, from the above state, if I add a new subdirectory sub4 inside src/sub1/, and then create other4.c inside src/sub1/sub4/, I would like make to generate sub4 inside obj/sub1/ and then generate other4.o inside obj/sub1/sub4/
create a binary at bin/release by linking all object files (from all subdirectories in obj/)
I don't want to have to change the makefile each time I add directories in src
I don't want to manually have to create directories in obj, the makefile should take care of it. if this is not possible, maybe have it rename all obj o files to a flat naming pattern? i.e. obj/sub2_sub3_other3.o instead of obj/sub2/sub3/other3.o (although this can cause issues)
probably not relevant here, but the C files use include statements in this format:
#include "sub2/sub3/other3.h"
so -I./inc would be included in the gcc call. Whereas the linker would receive inputs like -s -O3. I want to make sure those options (compiler options, linker options) are listed at the top of the makefile in variables (CFLAGS, LDFLAGS, etc) and not passed incorrectly to the targets.
is this even possible? if not, what's the closest possible?
Also, can this makefile be made to work on both POSIX systems and on Windows based systems? e.g. work the same on linux/gcc and win/mingw
GNU Make 3.8.1
I am working on what is basically a plugin for a software product. The plugin is built in a subdirectory of the main product, so the directory structure looks something like:
product
product/src
product/plugin
product/plugin/myPlugin
where "myPlugin" is the name of the plugin I'm working on. What I would like to do, is be able to build myPlugin as well as another version of myPlugin, call it myPlugin-lite. This plugin would have the same sources as myPlugin, but use different flags and defines in the makefiles. The idea was to create a duplicate of the myPlugin tree structure, containing only myPlugin's makefiles, and have it build using the sources from myPlugin. So the directory structure would look like:
product
product/src
product/plugin
product/plugin/myPlugin
product/plugin/myPlugin-lite
myPlugin would build and create all its targets within its subdirectory, and myPlugin-lite would build and create all its targets within its subdirectory. I found a few solutions here: http://make.mad-scientist.net/papers/multi-architecture-builds/ and out of these options it seems like the symbolic links would be best, but it still doesn't feel like the "right" way to do this.
My question is, is this the best/simplest/most maintainable way to do this? If not what are the alternatives?
If the only thing you need from myPlugin is source files then this is exactly what VPATH and The vpath Directive are for.
4.5.1 VPATH: Search Path for All Prerequisites
The value of the make variable VPATH specifies a list of directories that make should search. Most often, the directories are expected to contain prerequisite files that are not in the current directory; however, make uses VPATH as a search list for both prerequisites and targets of rules.
Thus, if a file that is listed as a target or prerequisite does not exist in the current directory, make searches the directories listed in VPATH for a file with that name. If a file is found in one of them, that file may become the prerequisite (see below). Rules may then specify the names of files in the prerequisite list as if they all existed in the current directory. See Writing Recipes with Directory Search.
In the VPATH variable, directory names are separated by colons or blanks. The order in which directories are listed is the order followed by make in its search. (On MS-DOS and MS-Windows, semi-colons are used as separators of directory names in VPATH, since the colon can be used in the pathname itself, after the drive letter.)
For example,
VPATH = src:../headers
specifies a path containing two directories, src and ../headers, which make searches in that order.
With this value of VPATH, the following rule,
foo.o : foo.c
is interpreted as if it were written like this:
foo.o : src/foo.c
assuming the file foo.c does not exist in the current directory but is found in the directory src.
Also see How Not to Use VPATH from MadScientist for more discussion about what they aren't for. Though that's largely just a build-up for the multi-architecture-builds paper you already read.
If I have some source files in another directory and I want to make some libraries using the source files, I want to have the *.o, *.po, and *.So files in the local directory. It isn't clear how to accomplish this. The transformation rules in bsd.lib.mk always point the .o into the source directory.
How do I get the results of the ${CC} -c to be in the local directory?
The file bsd.lib.mk inclused bsd.obj.mak, so you can use the MAKEOBJDIR environment variable.
Edit: If you cannot control how make is called, then don't use bsd.lib.mk and make explicit dependencies in your Makefile;
foo.o: ../bar/foo.c
Say I have a header file which is included by many source files, maybe with a very deep hierarchy. It is very boring to list this common header file in the prerequisites of each source object, and not sure whether there is an elegant solution. Thanks!
You can generate such dependencies with gcc -M. From TFM:
-M Instead of outputting the result of preprocessing, output a rule suitable for make describing the dependencies of the main source file. The preprocessor outputs one make rule containing the object file name for that source file, a colon, and the names of all the included files, including those coming from -include or -imacros command line options.
Also see Generating Prerequisites Automatically.
I am wondering if this is possible at all. Here is the situation:
My project uses automake to build its targets. The top-directory contains the usual configure.ac and Makefile.am. Amongst others, the Makefile.am contains a SUBDIRS variable listing the subdirectories, important for my question is the doc and include directory. The include directory's makefile looks like:
nobase_include_HEADERS = <lot-of-headers>
so it basically installs the headers. The makefile in doc is supposed to generate html documentation out of those files:
doxygen-stamp: Doxyfile
$(DOXYGEN) $<
echo "timestamp for Doxyfile" > $#
all-local: doxygen-stamp
Everything works fine so far, but if I change any of the headers in include the documentation is still up-to-date - because I did not list them as dependencies. What I would like to have is to have a doxygen-stamp-target that is rebuilt once the headers change without again listing all headers as dependencies. Is that possible and if it is, how?
In this case, using a single Makefile would be hinted at — though you can split it up by using the automake include instruction (also see section 7.3 "An alternative approach to subdirectories" of the am manual). Therefore:
#can't use nobase_
include_HEADERS = include/foo.h include/bar.h
doc/doxygen-stamp: ${include_HEADERS}
I think if you make doxygen-stamp also depend on '$(top_srcdir)/include/*.h' (or .hpp or whatever) it will rebuild when doxygen-stamp is out of date relative to any .h file in the include directory.
doxygen-stamp: Doxyfile $(top_srcdir)/include/*.h