These are simplified examples of my question.
I have:
Makefile in top/sub/sub/dir:
THINGSTODO := dothis
dothis:
#echo Do cool stuff
Main makefile in top dir:
all: $(THINGSTODO)
#echo do important stuff
Makefile in the sub dirs get included automatically.
If I run this (make all) I get:
No rule to make target 'dothis', needed by 'all'.
My conclusion is that the variable THINGSTODO gets a value but for some reason the rule "dothis" is not visible.
If I place the "dothis" rule in the main makefile it works like a charm.
But I don't want to change the main makefile, I just want to add a rule, in the sub/sub/dir makefile, that is executed before the "all" rule is executed.
I must be missing a vital bit of knowledge to solve this. Any suggestions?
Thanks.
system: Linux 4.18.13-100.fc27.x86_64
make: GNU Make 4.2.1 (Built for x86_64-redhat-linux-gnu)
Assume a trivial configure.ac:
AC_INIT([foobar], 1.0)
m4_define([foobar_m4], [foobar.m4])
m4_include(foobar_m4)
with a trivial foobar.m4:
AS_ECHO(["foobar.m4 was included"])
Running autoreconf produces:
aclocal: error: configure.ac:10: file 'foobar_m4' does not exist
autoreconf-2.69: aclocal failed with exit status: 1
How to include m4-expanded filenames in a configure.ac?
The culprit is the aclocal utility, not m4. The m4 expansion works just fine, but before m4 is invoked, aclocal scans configure.ac for dependencies, and it blindly handles the m4_include macro as if it were always called with a literal file argument.
There are two workarounds:
Use the built-in macro include:
m4_builtin([include], foobar_m4)
This will completely circumvent the autoconf-provided m4_include macro, which protects against repeated inclusions of the same file.
Define your own macro that invokes m4_include:
m4_define([my_include], [m4_include][([$1])])dnl
my_include(foobar_m4)
Why the weird quoting? We have to quote m4_include in the above definition so that it is not expanded during the definition of my_include, but quoting the whole m4_include([$1]) invocation would still trip aclocal in the same way as in the question.
As far as I know, there is no built-in way to prevent aclocal from specially treating the m4_include macro. This behavior of aclocal is essential for dependency tracking, so including files in this way is likely to fail due to undefined macros used in included files (this is also explained here).
I'm updating a project to use autotools, and to maintain backwards compatibility with previous versions, I would like the user to be able to run ./configure --foo=bar to set a build option.
Based on reading the docs, it looks like I could set up ./configure --enable-foo, ./configure --with-foo, or ./configure foo=bar without any problem, but I'm not seeing anything allowing the desired behavior (specifically having a double dash -- before the option).
Any suggestions?
There's no way I know of doing this in configure.ac. You'll have to patch configure. This can be done by running the patching script in a bootstrap.sh after running autoreconf. You'll have to add your option to the ac_option processing loop. The case for --x looks like a promising one to copy or replace to inject your new option, something like:
--foo=*)
my_foo=$ac_optarg ;;
There's also some code that strips out commandline args when configure sometimes needs to be re-invoked. It'll be up to you to determine whether --foo should be stripped or not. I think this is probably why they don't allow this in the first place.
If it were me, I'd try and lobby for AC_ARG_WITH (e.g. --with-foo=bar). It seems like a lot less work.
in order to do that you have to add to your configure.ac something like this:
# Enable debugging mode
AC_ARG_ENABLE(debug,
AC_HELP_STRING([--enable-debug],[Show a lot of extra information when running]),
AM_CPPFLAGS="$AM_CPPFLAGS -DDEBUG"
debug_messages=yes,
debug_messages=no)
AC_SUBST(AM_CPPFLAGS)
AC_SUBST(AM_CXXFLAGS)
echo -e "\n--------- build environment -----------
Debug Mode : $debug_messages"
That is just a simple example to add for example a --enable-debug, it will set the DEBUG constant on the config.h file.
then your have to code something like this:
#include "config.h"
#ifdef DEBUG
// do debug
#else
// no debug
#endif
This question already has answers here:
How does "make" app know default target to build if no target is specified?
(4 answers)
Closed 10 years ago.
In the case of building multiple targets in makefile, when I say 'make' it by default makes all the target. Is it possible to change the default of all to something else ?
all : target1 target2
Now , when I give the command 'make' , i only want target1 to build.
Like Carl mentions, you can just remove target2 from the line.
However if you still want all to make target1 and target2 there are some options...
You did not say which make you were using, which on these fine details it depends on the version, but I'm going to detail how it works for GNU make.
In GNU make, the first goal becomes the default. So if you have a Makefile like:
next:
#echo "next"
all:
#echo "All"
It will print:
$ make
next
You can also change the default goal:
.DEFAULT_GOAL=other
next:
#echo "next"
all:
#echo "All"
other:
#echo "other"
It will show:
$ make
other
This is with:
$ make --version
GNU Make 3.81
Sure, just delete target2 from that line.
Just add the line:
target1:
before the rule defining all. The name all is not special: it becomes the default by virtue of being the first rule listed. By adding target1: before that line, target1 becomes the default. Note that it is not standard behavior to allow multiple definitions of the rule (this is basically a fake rule whose behavior is defined later in the Makefile), but this will work with gnu make. If it doesn't work, just move the actual definition of target1 before the definition of all.
I'm creating a project and using GNU Autoconf tools to do the configuring and making. I've set up all my library checking and header file checking but can't seem to figure out how to check if an executable exists on the system and fail if it doesn't exist.
I've tried:
AC_CHECK_PROG(TEST,testprogram,testprogram,AC_MSG_ERROR(Cannot find testprogram.))
When I configure it runs and outputs:
Checking for testprogram... find: `testprogram. 15426 5 ': No such file or directory
but does not fail.
I found this to be the shortest approach.
AC_CHECK_PROG(FFMPEG_CHECK,ffmpeg,yes)
AS_IF([test x"$FFMPEG_CHECK" != x"yes"], [AC_MSG_ERROR([Please install ffmpeg before configuring.])])
Try this which is what I just lifted from a project of mine, it looks for something called quantlib-config in the path:
# borrowed from a check for gnome in GNU gretl: def. a check for quantlib-config
AC_DEFUN(AC_PROG_QUANTLIB, [AC_CHECK_PROG(QUANTLIB,quantlib-config,yes)])
AC_PROG_QUANTLIB
if test x"${QUANTLIB}" == x"yes" ; then
# use quantlib-config for QL settings
[.... more stuff omitted here ...]
else
AC_MSG_ERROR([Please install QuantLib before trying to build RQuantLib.])
fi
Similar to the above, but has the advantage of also being able to interact with automake by exporting the condition variable
AC_CHECK_PROG([ffmpeg],[ffmpeg],[yes],[no])
AM_CONDITIONAL([FOUND_FFMPEG], [test "x$ffmpeg" = xyes])
AM_COND_IF([FOUND_FFMPEG],,[AC_MSG_ERROR([required program 'ffmpeg' not found.])])
When using AC_CHECK_PROG, this is the most concise version that I've run across is:
AC_CHECK_PROG(BOGUS,[bogus],[bogus],[no])
test "$BOGUS" == "no" && AC_MSG_ERROR([Required program 'bogus' not found.])
When the program is missing, this output will be generated:
./configure
...cut...
checking for bogus... no
configure: error: Required program 'bogus' not found.
Or when coupled with the built-in autoconf program checks, use this instead:
AC_PROG_YACC
AC_PROG_LEX
test "$YACC" == ":" && AC_MSG_ERROR([Required program 'bison' not found.])
test "$LEX" == ":" && AC_MSG_ERROR([Required program 'flex' not found.])
Stumbled here while looking for this issue, I should note that if you want to have your program just looked in pathm a runtime test is enough:
if ! which programname >/dev/null ; then
AC_MSG_ERROR([Missing programname]
fi
This is not exactly a short approach, it's rather a general purporse approach (although when there are dozens of programs to check it might be also the shortest approach). It's taken from a project of mine (the prefix NA_ stands for “Not Autotools”).
A general purpose macro
dnl ***************************************************************************
dnl NA_REQ_PROGS(prog1, [descr1][, prog2, [descr2][, etc., [...]]])
dnl
dnl Checks whether one or more programs have been provided by the user or can
dnl be retrieved automatically. For each program `progx` an uppercase variable
dnl named `PROGX` containing the path where `progx` is located will be created.
dnl If a program is not reachable and the user has not provided any path for it
dnl an error will be generated. The program names given to this function will
dnl be advertised among the `influential environment variables` visible when
dnl launching `./configure --help`.
dnl ***************************************************************************
AC_DEFUN([NA_REQ_PROGS], [
m4_if([$#], [0], [], [
AC_ARG_VAR(m4_translit([$1], [a-z], [A-Z]), [$2])
AS_IF([test "x#S|#{]m4_translit([$1], [a-z], [A-Z])[}" = x], [
AC_PATH_PROG(m4_translit([$1], [a-z], [A-Z]), [$1])
AS_IF([test "x#S|#{]m4_translit([$1], [a-z], [A-Z])[}" = x], [
AC_MSG_ERROR([$1 utility not found])
])
])
m4_if(m4_eval([$# + 1 >> 1]), [1], [], [NA_REQ_PROGS(m4_shift2($*))])
])
])
Sample usage
NA_REQ_PROGS(
[find], [Unix find utility],
[xargs], [Unix xargs utility],
[customprogram], [Some custom program],
[etcetera], [Et cetera]
)
So that within Makefile.am you can do
$(XARGS)
or
$(CUSTOMPROGRAM)
and so on.
Features
It advertises the programs among the “influential environment variables” visible when the final user launches ./configure --help, so that an alternative path to the program can be provided
A bash variable named with the same name of the program, but upper case, containing the path where the program is located, is created
En error is thrown if any of the programs given have not been found and the user has not provided any alternative path for them
The macro can take infinite (couples of) arguments
When you should use it
When the programs to be tested are vital for compiling your project, so that the user must be able to provide an alternative path for them and an error must be thrown if at least one program is not available at all
When condition #1 applies to more than one single program, in which case there is no need to write a general purpose macro and you should just use your own customized code