I have a Makefile.am file in my source folder and some makefile.in in some subdiretories. Everything works fine but I've noticed that when I do a make dist the tarball doesn't include the makefile.in in the subdirectories. Also because of this, make distcheck fails.
I believe the only way this can happen is if you fail to specify the subdirectory is a SUBDIRS clause of the appropriate higher level Makefile.am, although it seems strange that 'everything works fine' if that is the case. Unless you are actually naming the makefile.in with a lower case m, in which case you would need to add that file to EXTRA_DIST, but the better solution would probably be to use the standard name with upper-case M.
Related
I'm working with autotools for the first time, for a tool that's written in perl (SQLTeX), so only installation is required, no compilation.
The toplevel contains a simple Makefile.am:
AUTOMAKE_OPTIONS = foreign
SUBDIRS = src man doc
EXTRA_DIST = README.md
.PHONY: all-am
all-am:
#echo "Done!"
If I create Makefile.am files in the sub-directories too, nothing seems to happen there so I just stick to Makefile. A snippet from src/Makefile (EDIT: this file is now renamed to Makefile.am):
SQLTeX: SQLTeX.pl
cat $^ | sed -e 's#{PERLDIR}#$(PL)#;s#{SYSCONFDIR}#$(sysconfdir)#' > $#
#chmod +x $#
The symbol PL is set as expect (defined in the same makefile), but sysconfdir is empty, although it is defined in the top-level Makefile generated by ./configure.
What am I doing wrong?
Thanks in advance!
What am I doing wrong?
Although the Autotools support, with some caveats, recursing into directories where you provide pre-built makefiles, you cannot expect those pre-built makefiles to be able to rely on autotools-provided variables such as the standard directory variables bindir and sysconfdir. Thus, although it is allowed to rely on hand-written makefiles in subdirectories, this is probably a false trail for you.
I recommend going back to this:
If I create Makefile.am files in the sub-directories too, nothing seems to happen there
and working out what's wrong. The Autotools definitely support generating recursive build systems, and one Makefile.am per directory is part of the usual approach to that. If it didn't work for you then my first guess would be that you forgot to list the extra makefiles in your AC_CONFIG_FILES list.
As an alternative, just because you have multiple directories does not mean that you need to use recursive make. It is quite possible to build such a project with the support of a single makefile, and the Autotools can help with such a makefile.
I have a Makefile with only project-level definitions: which source files to use, what binary or library to make, etc..
It includes ../../Make.Arch for architecture-specific definitions (such as compiler command).
In turn, Make.Arch is meant to include ../etc/Makefile.Standard for all the boilerplate of actually allowing the make system to work .
But include requires a path relative to where the makefile is actually being run (or maybe where the first Makefile is), not relative to the second... What to do?
Make interprets relative paths from the working directory, the directory in which Make is being run. You haven't specified how you're running Make, so I'll assume your running it in the directory with Makefile.
If you are allowed to modify the makefiles, you can change the paths.
You could change Make.Arch from this:
include ../etc/Makefile.Standard
to this:
include ../../../etc/Makefile.Standard
but that would require that any makefile that uses Make.Arch be two directories down from it. That's clearly not a good idea. But we can use a variable:
include $(ARCH_DIR)/../etc/Makefile.Standard
which is provided by Makefile (or any other makefile that uses Make.Arch):
ARCH_DIR := ../..
include $(ARCH_DIR)/Make.Arch
If you are not allowed to modify the makefiles, then you must cheat. One way is to create a symbolic link to Makefile.Standard.
mkdir ../etc
ln -s ../../../etc/Makefile.Standard ../etc
Now Makefile will work. (It ought to be possible to make a link to etc/, but for some reason I can't get that to work right now.)
If a preqequisite in my makefile refers e.g. to %/../some.file, the recipe for %/../some.file is not run.
My makefile contains a recipe
dir/file:
recipe
%/file2: %/../file
recipe
where % matches against dir/subdir. If I make dir/subdir/file2, make complains that it knows No rule to make target dir/subdir/file2. Even if I make dir/subdir/../file, it knows No rule to make target dir/subdir/../file. However, if I make dir/file and make dir/subdir/file2, everything works fine.
Apparently, referring to parent directories works in prerequisites, but not in targets. Do you know how to work around this?
It looks as if Make does take the '..' literally as a folder name, not being aware that it refer to a parent folder. Therefore 'file' is not the same as 'subdir/../file'. Technically, this is true, since 'subdir' could be a symlink, but I could not find any reference to this.
Workaround: add a helper dependency for each folder
dir/%/../file: dir/file
It's not perfect, since '%' can match dir/x1/x2/file. But depending on the structure of the source tree, it might be sufficient.
I've noticed that the following will work:
dir/subdir/../file: dir/file
But it will work only if there are very few files that can be enumerated.
Background:
Automake provides different types of distributions. After reading the docs "What Goes in a Distribution" I know how to include extra directories in general. But I'm not sure about the best way to exclude directories in this list for a single rule.
This is the part in current configure.ac that adds to the dist directories
AC_CONFIG_MACRO_DIR([m4])
AC_CONFIG_AUX_DIR([build_aux])
And this is the part in current Makefile.am that adds to the dist directories
SUBDIRS = sources po doc tests
EXTRA_DIST = build_windows
Furthermore Makefile.am has
AUTOMAKE_OPTIONS = dist-zip
For enabling the zip distribution.
Result: both package.tar.gz and package.zip have the same content. Therefore the following directories are included:
build_aux
build_windows
doc
m4
po
sources
tests
Question:
How to exclude build_windows in package.tar.gz and m4 in package.zip?
The short version is you don't. Different types of distributions only mean different format, but the content of these is designed to be exactly the same.
Long answer:
Different types of distributions only mean different format, but the content of these is designed to be exactly the same.
Therefore the solution for the goal is:
remove build_windows from EXTRA_DIST for having only needed content in the tar.gz distribution
remove dist-zip from AUTOMAKE_OPTIONS to prevent auto-generation of package.zip
add (or in this case edit) the dist-hook rule to manually:
check if build_windows exist (it won't exist if build from package.tar.gz)
copy the dist-content to a temporary directory
remove/add files/folders there as needed
create a package_win.zip from this folder (use a different name for preventing a possible package.zip to overwrite the file)
Edit: removing anything from the manually created dist folder will break make dist (or at least make distcheck), therefore this is only a good idea if you want to remove everything that has to do with autoconf/automake/Makfiles in general
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.