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.
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'm trying to install frama-c on my distro of manjaro 18.1.5, but no matter what I try, I always have an error.
First I tried to install via the AUR, and it seems to work, but when i try to open a file from the gui, it fails and says something like "invalid user input" even though I use files that works on a known good install.
Edit: here is the error output for this file:
[kernel] Parsing max.c (with preprocessing)
[kernel:annot-error] max.c:2: Warning:
unbound logic variable INT_MIN. Ignoring logic specification of function max
[kernel] User Error: warning annot-error treated as fatal error.
[kernel] User Error: stopping on file "max.c" that has errors. Add '-kernel-msg-key pp'
for preprocessing command.
Then I tried to install it using opam, so I first try to install dependencies with depext but it does not install anything then when I tried to install frama-c, it fails with the following error :
<><> Processing actions <><><><><><><><><><><><><><><><><><><><><><><><><><><><>
[ERROR] The compilation of frama-c failed at
"/home/benoit/.opam/opam-init/hooks/sandbox.sh build make -j7".
#=== ERROR while compiling frama-c.20.0 =======================================#
# context 2.0.5 | linux/x86_64 | ocaml-system.4.09.0 | https://opam.ocaml.org#2d21a0b6
# path ~/.opam/default/.opam-switch/build/frama-c.20.0
# command ~/.opam/opam-init/hooks/sandbox.sh build make -j7
# exit-code 2
# env-file ~/.opam/log/frama-c-4880-6d07ae.env
# output-file ~/.opam/log/frama-c-4880-6d07ae.out
### output ###
# [...]
# Ocamlopt src/plugins/value/legacy/eval_terms.cmx
# Ocamlopt src/plugins/value/domains/cvalue/cvalue_transfer.cmx
# Ocamlopt src/plugins/value/legacy/eval_annots.cmx
# Ocamlopt src/plugins/value/engine/transfer_logic.cmx
# Ocamlopt src/plugins/value/domains/cvalue/cvalue_domain.cmx
# /usr/bin/ld: cannot find -lgtksourceview-2.0
# collect2: error: ld returned 1 exit status
# Ocamlopt src/plugins/value/domains/cvalue/cvalue_specification.cmx
# File "_none_", line 1:
# Error: Error while building custom runtime system
# make: *** [Makefile:1294: bin/viewer.byte] Error 2
# make: *** Waiting for unfinished jobs....
My final attempt was to build it from source, but the make fails with the following error :
Ocamlc src/plugins/server/jbuffer.cmo
File "src/plugins/server/jbuffer.ml", line 23, characters 12-26:
23 | type json = Yojson.Basic.t
^^^^^^^^^^^^^^
Error: Unbound type constructor Yojson.Basic.t
make: *** [share/Makefile.generic:78: src/plugins/server/jbuffer.cmo] Error 2
My only remaining solution is to use a VM with debian but it's really ideal for me...
Does anyone have an idea of what i could do?
Thank you!
There are multiple issues in your question, and I believe some of them are worthy of investigation as possible bugs or issues. I'd recommend trying one of the official Frama-C support channels:
Creating an issue in the Frama-C Gitlab public repository;
Or creating an issue in the Frama-C Github snapshot repository (currently being deprecated in favor of the Gitlab repository, which is updated daily);
Or trying some interactive opam-related support in the IRC #frama-c channel on freenode.net (interactive support is often more efficient for installation issues related to opam, especially since it's hard to know in advance which information might be useful).
Dealing with "Invalid user input" errors in the GUI
As a general rule, when trying to open a file in the GUI fails, I'd recommend running the command-line version of Frama-C with the filename. Its output is much more detailed and can indicate if there are parsing issues with the file (which could be due to missing dependencies, non-C99 syntax, or configuration problems).
Otherwise, the Console tab in the GUI should contain detailed error messages, which you could then add to this SO question, in case they are relevant to understand your issue.
Issues with graphical libraries in non-major Linux distributions
The second issue I can see in your question, is the error related to -lgtksourceview-2.0. This means that one of the library dependencies for the graphical interface is missing. Maybe there's a way to fix it, but at the very least it should be possible to identify the error before compilation, and report the incompatibility earlier. The fact that depext did not work is unusual; maybe it's not currently well-supported for Manjaro, but it's worth investigating. Unfortunately, opam can sometimes be complex to handle for first-time users, so I understand it's a bit frustrating and may take more time than you'd want. But if you intend to use Frama-C or other OCaml packages for some reasonable amount of time, it is worth understanding some of the common errors in opam, since it is very useful for handling dependencies.
Handling issues with OCaml dependencies when compiling manually
Finally, the issue with Yojson is probably due to the version of the package that is installed. In particular, versions before 1.6.0 do not have the type Yojson.Basic.t. Frama-C used to support 1.4.1, but the latest version requires at least 1.6.0. Again, it's not obvious to spot in advance all possible issues with different package versions, but reporting them allows us to include checks to prevent it in the future, or at least to give a more precise error message.
Normally opam handles that part, hence why it's recommended even for manual compilation of Frama-C, since it helps manage its dependencies.
Overall, it seems that some underlying issue with the dependencies in opam depext is preventing the whole chain from working properly. Your report does contain much useful information but not all the details, so I believe the interactive route should allow to quickly converge towards a working installation.
I am trying to build a library with a different build system, but files in the library require a config.h header file that is generated after running the configure scripts generated by autoconf.
This is the sequence of steps I am following to try and generate the config.h file that is needed
autoreconf -ivf
./configure --disable-dependency-tracking
The build system guarantees that the library gflags will be linked and the headers will be available at preprocessing time. But the configure script exits with the following error
configure: error: Please install google-gflags library
Is there some way I can get the list of required libraries (such as gflags) and then pass arguments to the configure script that tells it to assume that this library exists on the system? I went through the help output for both autoreconf and ./configure and wasn't able to figure this out.
Sorry for the long explanation and problem. I am very new to autoconf, etc.
The answer to your question is: no, it is not possible to get a list of dependencies from autotools.
Why?
Well, autotools doesn't track dependencies at all.
Instead, it checks whether specific features are present on the system (e.g. a given header-file; or a given library file).
Now a specific header file can come from a variety of sources, e.g. depending on your distribution the foo.h header can be installed via
libfoo-dev (Debian and derivatives)
foo-devel (Fedora)
foo (upstream)
...
In your specific case, the maintainers of your project output a nice error message telling you to install a given package by name.
The maintainers of your project also chose to abort with a fatal error if a given dependency is not available.
The reason might well be, that the project simply won't work without that dependency, and that is impossible to compile the program without it.
Example
Your project might be written in C++ and thus require a C++-compiler.
Obviously there is little use in passing some flags to ./configure so it assumes that there is a C++-compiler available if in reality there is none.
There is hope
However, not all is bad.
Your configure script might will have the ability to disable certain features (that appear to be hard requirements by default).
Just check ./configure --help and look for flags like
--enable-FOO
--disable-FOO
--with-BAR
--without-BAR
automation?
One thing to know about autotools, is that configure really is a program (the source-code being configure.ac) written in some arcane programming language (involving bash and m4),
This means that it can practically have any behavior, and there is no single standard way to achieve "dependecy tracking".
What you're trying to do will not work as umläute already said. On the other hand, depending on the package you're trying to build, you may be able to tell ./configure that a given library is there even if it isn't.
For instance if the script uses pkg-config to check for the presence of a library, you can use FOO_CFLAGS and FOO_LIBS to override the presence checking and telling it "yes those packages are there, you just don't know how to find them", but these are very package-specific so you may have to provide more information if that's what you're looking for.
First, a little bit of background as to why I'm asking this question: Our product's daily build script (as run under Debian Linux by Jenkins), does roughly this:
Creates and enters a build environment using debootstrap and chroot
Checks out our codebase (including some 3rd party libraries) from SVN
Runs configure and make as necessary to build all of the code
Packages up the results into an install file that can be uploaded to our headless server boxes using our install tool.
This mostly works fine, but every so often (maybe one daily build out of 10), the part of the script that builds one of our third-party libraries will error out with an error like this one:
CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/bash
/root/software/3rdparty/libogg/missing autoconf
/root/software/3rdparty/libogg/missing: line 81: autoconf: command not found
WARNING: 'autoconf' is missing on your system.
You should only need it if you modified 'configure.ac',
or m4 files included by it.
The 'autoconf' program is part of the GNU Autoconf package:
<http://www.gnu.org/software/autoconf/>
It also requires GNU m4 and Perl in order to run:
<http://www.gnu.org/software/m4/>
<http://www.perl.org/>
make: *** [configure] Error 127
As far as I can tell, this happens occasionally because the timestamps of the files in the third-party library are different (e.g. off by a second or two from each other just due to the timing of when they were checked out from the SVN server during that particular build). That causes the configure script to think that it needs to auto-regenerate a file, so then it tries to call 'automake' to do so, and errors out because automake is not installed.
Of course the obvious thing to do here would be to install automake in the build environment, but the build environment is not one that I can easily modify (due to institutional reasons), so I'd like to avoid having to do that if possible. What I'd like to do instead is figure out how to get the configure scripts (which I can modify) to ignore the timestamps and just always do the basic build that they do when the timestamps are equal.
I tried to finesse the problem by manually running 'touch' on some files to force their timestamps to be the same, and that seemed to make the problem occur less often, but it still happens:
./configure --prefix="$PREFIX" --disable-shared --enable-static && \
touch config* aclocal* Makefile* && \
make clean && make install ) || Failure "libogg"
Can anyone familiar with how automake works supply some advice on how I might make the "configure" calls in our daily build work more reliably, without modifying the build environment?
You could try forcing SVN to use commit times on checkout on your Jenkins server. These commit times can also be set in SVN if they don't work out for some reason. You could use touch -d or touch -r instead of just touch to avoid race conditions there.
".MAKE" appears in gnu Makefile for a number of packages which use AutoMake, but appears to be undocumented as a "special" target in the online manual. Anyone know what it does?
This target doesn't do anything by itself. It has no special meaning to a make I know.
However, it is automatically generated when a project uses GNU Automake.
Automake creates the Makefile.in files, which ./configure will use to generate Makefiles.
It isn't listed among the targets in the documentation: only developers will need it, as its definition in a generated Makefile.in shows:
.MAKE: $(RECURSIVE_CLEAN_TARGETS) $(RECURSIVE_TARGETS) all check-am \
ctags-recursive install-am install-strip tags-recursive
The two variables are defined elsewhere in Makefile.in, and it appears that this target will attempt to do a full runthrough of everything that can be done at all: cleaning up the source tree, compiling the software, running automatic tests, installing it, uninstalling it, and a few steps that are only useful for developers. So this is basically a one-shot test run that might for instance be used during continuous build tests.
This is a clear example of why automake was created: a much-desired feature is missing from make (namely the ability to tell it to "do everything"), so automake provides it.
The chosen answer is inaccurate. The .MAKE target is not meant to be executed by anyone. It doesn't mean anything special to GNU make, however the make in, for example, FreeBSD, understands the prerequisites of .MAKE to be recursive make invocations. In particular, the recipes associated with them will be executed even when doing make -n (dry-run invocation) so that you can see what commands would be executed by the recursive makes. GNU make detects recursive make recipes by the presence of a reference to $(MAKE), or by the '+' token. So it's inserted by automake for compatibility purposes.