Detect preprocessor macro in another library with Autoconf - gnu

I have an installed library we'll call it "custom_lib" which I am linking against.
I want to check if that library was installed with a specific option.
The options.h header file in that library has a list of pre-processor macros like so:
#undef THIS
#define THIS
#undef THAT
#define THAT
#undef WE_WANT_THIS_ONE
#define WE_WANT_THIS_ONE
In another project I have in my configure.ac file this test:
OPTION_FOUND="no"
AC_CHECK_HEADERS(custom_lib/options.h)
AC_MSG_CHECKING([is libary configured with --enable-we_want_this_one])
#AC_EGREP_HEADER([ string to match ],
# [ header file ],
# [ action if found ],
# [ action if not found ])
AC_EGREP_HEADER([[WE_WANT_THIS_ONE]],
[custom_lib/options.h],
[OPTION_FOUND="yes"],
[OPTION_FOUND="no"])
if test "$OPTION_FOUND" = "yes"
then
# If we have WE_WANT_THIS_ONE check to see which compiler is being used
if test "$GCC" = "yes"
then
if test "$CC" != "icc"
then
#if compiler is not icc then add these flags
CFLAGS="$CFLAGS -maes -msse4"
fi
fi
AC_MSG_RESULT([yes])
else
AC_MSG_RESULT([no])
fi
I then autreconf and run ./configure which always returns this message:
checking custom_lib/options.h usability... yes
checking custom_lib/options.h presence... yes
checking for custom_lib/options.h... yes
checking is library configured with --enable-we_want_this_one... no
Am I doing something wrong. What needs altered in the test I have in configure.ac so that autoconf can detect the pre-processor macro in options.h?

AC_EGREP_HEADER macro doesn't perform grep on the text of the tested header but the on the output of the preprocessor running on that file.
From autoconf manual:
— Macro: AC_EGREP_HEADER (pattern, header-file, action-if-found, [action-if-not-found])
If the output of running the preprocessor on the system header file
header-file matches the extended regular expression pattern, execute
shell commands action-if-found, otherwise execute action-if-not-found.
You could use AC_COMPILE_IFELSE macro instead. For example (not tested):
AC_COMPILE_IFELSE([AC_LANG_SOURCE([[
#include "custom_lib/options.h"
#ifndef WE_WANT_THIS_ONE
# error macro not defined
#endif
]])], [OPTION_FOUND="yes"], [OPTION_FOUND="no"])

Related

Create custom ./configure command line arguments

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

Sublime text linux gcc build for simple C programs

I want to build programs in the inbuilt build command of sublime text 2
I've made a gcc.sublime-build file with
{
"cmd" : ["gcc", "$file_name", "-o", "${file_base_name}"],
"selector" : "source.c",
"shell":true,
"working_dir" : "$file_path"
}
but all i get is an error saying
gcc: fatal error: no input files
compilation terminated.
[Finished in 0.0s with exit code 4]
any ideas
Sublime Text is executing gcc without parameters because "shell": true means that the value of "cmd" is passed to a shell, and it should be one string. In your file it appears that you want to pass parameters directly to GCC, so you should set "shell" to false.
I would do this with a Makefile:
CC=gcc
all: source
Then, type make.

Autoconf and ./configure variables

I have a little problem with autoconf, I know that you can use configure.ac to add some defines to configure.h, but is there a way to do something like this:
in one of my headers I have
#ifndef SIZE
#define SIZE 4
#endif
now I want to have an option that if I invoke
./configure
it creates makefile and the size is 4, but when someone does
./configure --block-size=num
the SIZE will be set to num, preferably I want to do this without config.h, I just want him to add something to makefile, so the compilation will be invoked with
-DSIZE=num
# configure.ac
AC_ARG_WITH([blocksize],
AS_HELP_STRING([The desired blocksize [[default: 4]]]),
[blocksize="$withval"], [blocksize=4])
my_CPPFLAGS="-DSIZE=$blocksize"
AC_SUBST([my_CPPFLAGS])
Quite simple.
# Makefile.am
AM_CPPFLAGS = ${my_CPPFLAGS}

Autoconf check for program and fail if not found

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

Where are include files stored - Ubuntu Linux, GCC

So, when we do the following:
#include <stdio.h>
versus
#include "myFile.h"
the compiler, GCC in my case, knows where that stdio.h (and even the object file) are located on my hard drive. It just utilizes the files with no interaction from me.
I think that on my Ubuntu Linux machine the files are stored at /usr/include/. How does the compiler know where to look for these files? Is this configurable or is this just the expected default? Where would I look for this configuration?
Since I'm asking a question on these include files, what are the source of the files? I know this might be fuzzy in the Linux community but who manages these? Who would provide and manage the same files for a Windows compiler.
I was always under the impression that they come with the compiler but that was an assumption...
See here: Search Path
Summary:
#include <stdio.h>
When the include file is in brackets the preprocessor first searches in paths specified via the -I flag. Then it searches the standard include paths (see the above link, and use the -v flag to test on your system).
#include "myFile.h"
When the include file is in quotes the preprocessor first searches in the current directory, then paths specified by -iquote, then -I paths, then the standard paths.
-nostdinc can be used to prevent the preprocessor from searching the standard paths at all.
Environment variables can also be used to add search paths.
When compiling if you use the -v flag you can see the search paths used.
gcc is a rich and complex "orchestrating" program that calls many other programs to perform its duties. For the specific purpose of seeing where #include "goo" and #include <zap> will search on your system, I recommend:
$ touch a.c
$ gcc -v -E a.c
...
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/usr/lib/gcc/i686-apple-darwin9/4.0.1/include
/usr/include
/System/Library/Frameworks (framework directory)
/Library/Frameworks (framework directory)
End of search list.
# 1 "a.c"
This is one way to see the search lists for included files, including (if any) directories into which #include "..." will look but #include <...> won't. This specific list I'm showing is actually on Mac OS X (aka Darwin) but the commands I recommend will show you the search lists (as well as interesting configuration details that I've replaced with ... here;-) on any system on which gcc runs properly.
Karl answered your search-path question, but as far as the "source of the files" goes, one thing to be aware of is that if you install the libfoo package and want to do some development with it (i.e., use its headers), you will also need to install libfoo-dev. The standard library header files are already in /usr/include, as you saw.
Note that some libraries with a lot of headers will install them to a subdirectory, e.g., /usr/include/openssl. To include one of those, just provide the path without the /usr/include part, for example:
#include <openssl/aes.h>
The \#include files of gcc are stored in /usr/include .
The standard include files of g++ are stored in /usr/include/c++.

Resources