I am trying to add an option to my ./configure script. I need to add the location to mysql.h but a few methods I have tried and keep getting the error: configure: error: unrecognized option: --mysql=/usr/local/mysql/include/mysql/
How do I add the option to my configure script aswell as to add the header file which is specified.
You're probably looking for AC_ARG_WITH. Something like this:
AC_ARG_WITH([mysql],
[AS_HELP_STRING([--with-mysql=path : path to mysql headers])],
[MYSQL_INCLUDE=$withval],
[])
Then run ./configure --with-mysql=/foo .
Sounds like what you are trying to get your compiler to include a specific include path when it builds. The easiest way to do that is with the CPPFLAGS environment variable, e.g.
% setenv CPPLAGS -I/usr/local/mysql/include/mysql/
% ./configure
% make
% etc...
If you actually need to add a new option to configure you'll need to learn about autoconf and editing configure.in to generate a new configure script.
Related
A user of xnec2c was trying to build on OSX and had autoconf issues because PKG_CHECK_MODULES could not be found since MacPorts puts it in a funny spot.
The user made autoconf work like so:
ACLOCAL_PATH=/opt/local/share/aclocal ./autogen.sh
ACLOCAL_PATH=/opt/local/share/aclocal ./configure
I would like to make it build on OSX without special user path hacks for ACLOCAL_PATH. Can that be done?
I started writing a possible fix below and realized it could an xyproblem so posed the question just above. However, if this starts any gears turning, then I would be open to a bit of special-casing for OSX:
For example, would it be possible (if not advisable) to detect:
Is PKG_CHECK_MODULES missing?
If so:
is it OSX?
Is [ -d /opt/local/share/aclocal ] true?
Does the macro exist there?
While aclocal has a few ways of appending to its search path (see https://www.gnu.org/software/automake/manual/html_node/Macro-Search-Path.html), you cannot modify that macro search path using code in configure.ac:
When the shell code in configure is run, it is too late, as the available macros have already been expanded. When autoconf (is it autoconf or something else? anyway, m4 called from autoreconf) generates configure from configure.ac by having m4 expand the macros it is also too late: aclocal has already collected the m4 macros it could find.
So what you would need is a step before the autoreconf run - which is beyond what I would consider a buildsystem needs to do.
What you can do: Put static strings into the top level Makefile.am file like e.g.
ACLOCAL_AMFLAGS = -I auto-m4 -I project-m4 -I /opt/local/share/aclocal
(this example uses auto-m4/ with AC_CONFIG_MACRO_DIR([auto-m4]) for the *.m4 files automatically put there by autoreconf/autopoint/libtoolize and project-m4/ for the project specific *.m4 files).
Of course, you should already have
m4_pattern_forbid([PKG_CHECK_MODULES])dnl
before invoking PKG_CHECK_MODULES for the first time so that the problem of the missing *.m4 file will be detected at the earliest possible time, i.e. when autoconf is about to generate a configure file with PKG_CHECK_MODULES unexpanded.
You could use some m4 code to print a lengthy error message if PKG_CHECK_MODULES is not defined. Something along the lines of (untested)
m4_ifndef([PKG_CHECK_MODULES], [dnl
m4_fatal([Could not find the PKG_CHECK_MODULES macro. Check that the pkg.m4 file is available and aclocal finds it (e.g. set ACLOCAL_PATH=/opt/local/share/aclocal).
])dnl
PKG_CHECK_MODULES([FOO], [foo])
Personally, I would go with m4_pattern_forbid and make sure OSX builds with homebrew work OOTB, and then document idiosyncrasies for building on rare and buggy systems like OSX with macports or SunOS without GNU tools in the INSTALL file.
Isn't it a bug in macports/OSX that aclocal there cannot find its *.m4 files? Shouldn't there be a dirlist file pointing to /opt/local/share/aclocal? Or perhaps they macports users should have an aclocal in their PATH which actually finds the macports macro files?
In any case, I would not consider it my build systems's job to fix a buggy system. You need to draw the line somewhere.
I want to install Libav locally in a folder and for that I have to install yasm (I can disable the dependency but I don't want to just for the sake of the argument). The installation of the package is done in the terminal via "./configure" and "make" (when I run "./configure" I receive the message, that yasm is missing). How can I tell to "./configure" to take it's yasm dependencies from the path "./libs" (there is a folder with libraries in the parent folder). Should I modify the makefile (and if yes should I change only the LDflags? to what?) or add the " --extra-ldflags="-L./libs" " to the ./configure command? What would be the use of cflags here?
To have autotools' configure use dependencies from a specific directory, the following may or may not work, as the configure script can be written differently:
--extra-ldflags (there should be --extra-cflags too) is fine, if it's there;
for library dependencies, you can add CFLAGS="-I<path>" CXXFLAGS="<same>" LDFLAGS="-L<path>" to ./configure's environment or to its command line arguments;
cleaner approach: if you have pkg-config configuration generated and installed for your dependencies, you can specify a PKG_CONFIG_PATH instead. In special cases of cross-compilation, one can use PKG_CONFIG_SYSROOT_DIR.
for local host executables, append/prepend to PATH.
Related question: https://unix.stackexchange.com/questions/19663/how-to-change-the-compiler-settings-with-automake
Question about installing log4cplus.
log4cplus has two way to make & install.
./configure && make && make install
cmake xxx && make && make install
When I use the 1st one, parameters --includedir=PATH and --libdir=PATH can be specified to configure, because I want to install them into different paths.
How can I specify the two equivalent parameters to cmake?
Thanks!
Since package log4cplus uses CMake module GNUInstallDirs, you may use variables CMAKE_INSTALL_LIBDIR and CMAKE_INSTALL_INCLUDEDIR for adjust installation paths for libraries and headers correspondingly:
cmake -DCMAKE_INSTALL_LIBDIR=<libdir-path> -DCMAKE_INSTALL_INCLUDEDIR=<includedir-path>
For more info see that question.
My linux environment is based off of a high compute cluster that does not allow users to install to /usr/bin/ or use sudo. I'm trying to use ./configure (made from protocol buffers) to install to my home. When configure searches for the CXX files it is not finding the compilers that are located in the bin because they are named things like 'g++34' instead of 'g++'. I want to point the configure file at this specific compiler, but can't seem to get the command right to do so. Again the directory where the compiler is gets searched, it is just named funny (using an alias hasn't worked either).
How do you use a arguments in a configure file to point at a specific compiler?
Just use:
./configure CC=gcc34 CXX=g++34
etc. If you have a really old version of configure you might have to do it via the environment instead:
CC=gcc34 CXX=g++34 ./configure
I work with an autotools project an trying to add new features to the build system (adding new components, etc). While doing it, strangely I discovered that if I add a bla option to it (in configure.ac), but by mistake call it like:
$ ./configure --with-blabla
It silently complains that:
configure: WARNING: unrecognized options: --with-blabla
and the configuration process still continues. I would like to stop the process instead if an unrecognized --with is encountered. Is this possible somehow?
Your 'option' will have no effect. In that sense, a warning is sufficient. Matched --with-<package> options are enabled by a AC_ARG_WITH, so while blabla might be ignored now, there's no reason why --with-blabla or --enable-blabla might not be useful in the future.
More to the point: ./configure --help gives a list of valid configure options. It's not about failing with an unrecognized option - which brings us to an important point:
Some packages are built recursively, when a package has several sub-packages, an option may not be relevant to all of them, and yet you want to pass it to the package that does accept the option. In short - I see no reason to disable this behaviour.
Of course, if you really want to, you can invoke autoconf with:
autoconf --warnings=error in generating the configure script.