I would like to know the paths of all code files that went into the compilation of a whole C/C++ project with multiple resulting binaries. I know about https://github.com/rizsotto/Bear et al which you can wrap around your "make" call and which tell you the gcc/g++ calls but they of course show me only the C/C++ files which were compiled - how can I find out which of the headers were needed for the compilation and ended up in one of the resulting binaries?
GCC has the runtime option -M. From the GCC man page:
-M Instead of outputting the result of preprocessing, output a rule
suitable for make describing the dependencies of the main source
file. The preprocessor outputs one make rule containing the object
file name for that source file, a colon, and the names of all the
included files, including those coming from -include or -imacros
command-line options.
Unless specified explicitly (with -MT or -MQ), the object file name
consists of the name of the source file with any suffix replaced
with object file suffix and with any leading directory parts
removed. If there are many included files then the rule is split
into several lines using \-newline. The rule has no commands.
This option does not suppress the preprocessor's debug output, such
as -dM. To avoid mixing such debug output with the dependency
rules you should explicitly specify the dependency output file with
-MF, or use an environment variable like DEPENDENCIES_OUTPUT.
Debug output is still sent to the regular output stream as normal.
Passing -M to the driver implies -E, and suppresses warnings with
an implicit -w.
Clang supports the very same option
GCC and Clang both support the -H option (as well as the -M option and its relatives).
-H
Print the name of each header file used, in addition to other normal activities. Each name is indented to show how deep in the ‘#include’ stack it is. Precompiled header files are also printed, even if they are found to be invalid; an invalid precompiled header file is printed with ‘...x’ and a valid one with ‘...!’ .
The -H output is reported on standard error, not standard output.
The -H option gives more and different information compared with the -M option. It reports on the nesting levels (one or more leading dots), and shows each time a header is included — even if the content is ignored because of header guard macros:
#ifndef HEADER_H_INCLUDED
#define HEADER_H_INCLUDED
…content of header…
#endif /* HEADER_H_INCLUDED */
This can be useful; having the formatted make dependency lines (as generated by -M) can also be useful.
Example output (from compiling one source file from one of my programs — make generated the compiler command line, of course):
$ gcc -H -g -O3 -std=c11 -Wall -Wextra -Werror -Wmissing-prototypes -Wstrict-prototypes -Wold-style-definition -DSYSTEM=MACOS_X -DSTR_SYSTEM='"(macOS Mojave 10.14.6 - Darwin 18.7.0)"' -I/Users/jonathanleffler/inc -DDEBUG -DHASH_STATISTICS -c main.c
. make.h
.. /Users/jonathanleffler/inc/posixver.h
.. config.h
.. /usr/include/assert.h
... /usr/include/sys/cdefs.h
.... /usr/include/sys/_symbol_aliasing.h
.... /usr/include/sys/_posix_availability.h
.. /usr/include/ctype.h
... /usr/include/_ctype.h
.... /usr/include/runetype.h
..... /usr/include/_types.h
...... /usr/include/sys/_types.h
....... /usr/include/machine/_types.h
........ /usr/include/i386/_types.h
....... /usr/include/sys/_pthread/_pthread_types.h
.. /usr/include/errno.h
... /usr/include/sys/errno.h
.. /usr/include/inttypes.h
... /usr/include/Availability.h
.... /opt/gcc/v9.2.0/lib/gcc/x86_64-apple-darwin18.7.0/9.2.0/include-fixed/AvailabilityInternal.h
... /usr/include/sys/_types/_wchar_t.h
... /opt/gcc/v9.2.0/lib/gcc/x86_64-apple-darwin18.7.0/9.2.0/include/stdint.h
.... /opt/gcc/v9.2.0/lib/gcc/x86_64-apple-darwin18.7.0/9.2.0/include-fixed/stdint.h
..... /usr/include/sys/_types/_int8_t.h
..... /usr/include/sys/_types/_int16_t.h
..... /usr/include/sys/_types/_int32_t.h
..... /usr/include/sys/_types/_int64_t.h
..... /usr/include/_types/_uint8_t.h
..... /usr/include/_types/_uint16_t.h
..... /usr/include/_types/_uint32_t.h
..... /usr/include/_types/_uint64_t.h
..... /usr/include/sys/_types/_intptr_t.h
...... /usr/include/machine/types.h
....... /usr/include/i386/types.h
........ /usr/include/sys/_types/_u_int8_t.h
........ /usr/include/sys/_types/_u_int16_t.h
........ /usr/include/sys/_types/_u_int32_t.h
........ /usr/include/sys/_types/_u_int64_t.h
........ /usr/include/sys/_types/_intptr_t.h
........ /usr/include/sys/_types/_uintptr_t.h
..... /usr/include/_types/_intmax_t.h
..... /usr/include/_types/_uintmax_t.h
.. /opt/gcc/v9.2.0/lib/gcc/x86_64-apple-darwin18.7.0/9.2.0/include-fixed/limits.h
... /opt/gcc/v9.2.0/lib/gcc/x86_64-apple-darwin18.7.0/9.2.0/include-fixed/syslimits.h
.... /opt/gcc/v9.2.0/lib/gcc/x86_64-apple-darwin18.7.0/9.2.0/include-fixed/limits.h
..... /usr/include/limits.h
...... /usr/include/machine/limits.h
....... /usr/include/i386/limits.h
........ /usr/include/i386/_limits.h
...... /usr/include/sys/syslimits.h
.. /opt/gcc/v9.2.0/lib/gcc/x86_64-apple-darwin18.7.0/9.2.0/include/stdbool.h
.. /opt/gcc/v9.2.0/lib/gcc/x86_64-apple-darwin18.7.0/9.2.0/include-fixed/stdio.h
... /opt/gcc/v9.2.0/lib/gcc/x86_64-apple-darwin18.7.0/9.2.0/include/stdarg.h
... /usr/include/_stdio.h
.... /usr/include/sys/_types/_va_list.h
.... /usr/include/sys/_types/_size_t.h
.... /usr/include/sys/_types/_null.h
.... /usr/include/sys/stdio.h
... /usr/include/sys/_types/_off_t.h
... /usr/include/sys/_types/_ssize_t.h
... /usr/include/secure/_stdio.h
.... /usr/include/secure/_common.h
.. /usr/include/stdlib.h
... /usr/include/sys/wait.h
.... /usr/include/sys/_types/_pid_t.h
.... /usr/include/sys/_types/_id_t.h
.... /usr/include/sys/signal.h
..... /usr/include/sys/appleapiopts.h
..... /usr/include/machine/signal.h
...... /usr/include/i386/signal.h
..... /usr/include/machine/_mcontext.h
...... /usr/include/i386/_mcontext.h
....... /usr/include/mach/machine/_structs.h
........ /usr/include/mach/i386/_structs.h
..... /usr/include/sys/_pthread/_pthread_attr_t.h
..... /usr/include/sys/_types/_sigaltstack.h
..... /usr/include/sys/_types/_ucontext.h
...... /usr/include/machine/_mcontext.h
..... /usr/include/sys/_types/_sigset_t.h
..... /usr/include/sys/_types/_uid_t.h
.... /usr/include/sys/resource.h
..... /usr/include/sys/_types/_timeval.h
... /usr/include/sys/_types/_wchar_t.h
... /usr/include/malloc/_malloc.h
.. /usr/include/string.h
... /usr/include/secure/_string.h
.. /usr/include/sys/stat.h
... /usr/include/sys/_types/_timespec.h
... /usr/include/sys/_types/_blkcnt_t.h
... /usr/include/sys/_types/_blksize_t.h
... /usr/include/sys/_types/_dev_t.h
... /usr/include/sys/_types/_ino_t.h
... /usr/include/sys/_types/_mode_t.h
... /usr/include/sys/_types/_nlink_t.h
... /usr/include/sys/_types/_gid_t.h
... /usr/include/sys/_types/_time_t.h
... /usr/include/sys/_types/_s_ifmt.h
.. /usr/include/unistd.h
... /usr/include/sys/unistd.h
.... /usr/include/sys/_types/_posix_vdisable.h
.... /usr/include/sys/_types/_seek_set.h
... /usr/include/sys/_types/_useconds_t.h
.. /Users/jonathanleffler/inc/debug.h
... /Users/jonathanleffler/inc/kludge.h
.. /Users/jonathanleffler/inc/emalloc.h
.. list.h
.. /Users/jonathanleffler/inc/sastrings.h
.. /Users/jonathanleffler/inc/stderr.h
... /opt/gcc/v9.2.0/lib/gcc/x86_64-apple-darwin18.7.0/9.2.0/include/stdarg.h
. /Users/jonathanleffler/inc/getopt.h
Multiple include guards may be useful for:
/opt/gcc/v9.2.0/lib/gcc/x86_64-apple-darwin18.7.0/9.2.0/include-fixed/syslimits.h
/usr/include/assert.h
/usr/include/errno.h
/usr/include/machine/limits.h
/usr/include/secure/_stdio.h
/usr/include/secure/_string.h
/usr/include/sys/_posix_availability.h
/usr/include/sys/_symbol_aliasing.h
/usr/include/sys/_types/_seek_set.h
$
That lists 110 headers; there are just five that are repeated:
2 /opt/gcc/v9.2.0/lib/gcc/x86_64-apple-darwin18.7.0/9.2.0/include-fixed/limits.h
2 /opt/gcc/v9.2.0/lib/gcc/x86_64-apple-darwin18.7.0/9.2.0/include/stdarg.h
2 /usr/include/machine/_mcontext.h
2 /usr/include/sys/_types/_intptr_t.h
2 /usr/include/sys/_types/_wchar_t.h
Other projects I work on have many more repeats. Taking one source file, more or less at random (I know it's a big file; I don't think it is the worst), there is a list of headers included 4 or more times — there are many included 2 and 3 times. The total number of header lines from -H for this file is 592. Project-specific directory and file names have been changed to protect the innocent — and the file names were massaged with realpath(2) to deal with the idiosyncratic use of ../subdir/header.h style names in the source code and in the included headers, which -H expands to names such as:
../incl/../subdir1/../subdir1/../subdir2/../subdir2/header27.h
Counts:
4 /usr/include/errno.h
4 /usr/include/time.h
4 /opt/project/incl/header1.h
4 /opt/project/incl/header2.h
4 /opt/project/subdir/header3.h
4 /opt/project/subdir/header4.h
4 /opt/project/subdir/header5.h
5 /opt/project/incl/header6.h
5 /opt/project/subdir/header7.h
6 /opt/project/subdir/header8.h
6 /opt/project/subdir/header9.h
6 /work5/gcc/v9.2.0/lib/gcc/x86_64-pc-linux-gnu/9.2.0/include-fixed/limits.h
7 /opt/project/subdir/header10.h
14 /usr/include/bits/wordsize.h
14 /opt/project/subdir/header11.h
22 /work5/gcc/v9.2.0/lib/gcc/x86_64-pc-linux-gnu/9.2.0/include/stddef.h
Related
I am not trying to write:
#include MACRO(arg)
instead, I am trying to write just:
MACRO(arg)
Many people say that we cant write such macro to #include any file, but those try fails on preprocessing stage only, below one passes preprocessor but fails later, I think.
I wrote following test code tmp1.cpp (which does not compile):
#define HASH #
#define ZX(arg) HASH include <arg>
ZX(iostream)
int main()
{
}
And below is the output of some commands:
$ g++ -E tmp1.cpp
# 1 "tmp1.cpp"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 1 "<command-line>" 2
# 1 "tmp1.cpp"
# include <iostream>
int main()
{
}
$ g++ -E tmp1.cpp > tmp2.cpp
$ g++ tmp2.cpp
$ ./a.out
$ g++ tmp1.cpp
tmp1.cpp:1:14: error: stray ‘#’ in program
#define HASH #
^
tmp1.cpp:2:17: note: in expansion of macro ‘HASH’
#define ZX(arg) HASH include <arg>
^
tmp1.cpp:4:1: note: in expansion of macro ‘ZX’
ZX(iostream)
^
tmp1.cpp:2:22: error: ‘include’ does not name a type
#define ZX(arg) HASH include <arg>
^
tmp1.cpp:4:1: note: in expansion of macro ‘ZX’
ZX(iostream)
^
$
I wonder why tmp2.cpp compiles and executes successfully but tmp1.cpp fails on compilation stage ? Isn't it that first the preprocessor is run then its output is fed to compiler ? tmp2.cpp is just preprocessed version of tmp1.cpp only.
[EDIT]
I had requirement of:
#ifdef SOMETHING
#define ZX(arg)
#else
#define HASH #
#define ZX(arg) HASH include <arg>
#endif
[cpp.rescan]/3 The resulting completely macro-replaced preprocessing token sequence is not processed as a preprocessing directive even if it resembles one...
I believe your quest is hopeless.
I want to generate a file list with gcc -M which delivers something like the following which works fine:
../active_var/timervar.h \
../active_var/universal_var.h \
../chrono_timer/chrono_timer.cpp \
/home/bla/foreign_components/gmock-1.7.0/fused-src/gmock/gmock.h \
/home/bla/foreign_components/gmock-1.7.0/fused-src/gmock-gtest-all.cc \
/home/bla/foreign_components/gmock-1.7.0/fused-src/gmock_main.cc \
/home/bla/foreign_components/gmock-1.7.0/fused-src/gtest/gtest.h \
../../mtp/index_tuple.h \
../observer/observer_with_stop_marker.h \
test_bugfixing.cpp \
test_counter.cpp \
I give this files to the
INPUT = <files as listed above >
This works as expected.
Now I simply want to ignore the files coming from /home/bla/foreign_components/
I tried:
EXCLUDE = */home/bla/foreign_components/*
or
EXCLUDE = /home/bla/foreign_components/
or
EXCLUDE = /home/bla/foreign_components/*
nothing works!
I tried the same with all above listed patterns with the EXCLUDE_PATTERNS
Also no effect.
Is this feature simply broken in doxygen or can files which are explicitly listed in files not be filtered out?
I am using doxygen version: 1.8.10
can files which are explicitly listed in files not be filtered out?
I think so.
You can generate your INPUT list by filtering gcc -M output:
gcc -M | grep -v "/home/bla/foreign_components"
Followed the directions here for OSX: http://doc.qt.io/qt-5/appicon.html
stating that all I need to do is add ICON = myapp.icns to my project file.
I used one of the ICNS files I stole from Qt itself (in other words, it should work, its not a conversion problem) and when build after running qmake I get the error
make: *** No rule to make target '1.22/MyProject.icns', needed by 'myapp.app/Contents/Resources/MyProject.icns'
I regularly use make but have little experience with Qt so I have no idea what it's trying to tell me here (I don't even know where these file paths are coming from).
The .icns file has been added to the resources .qrc and is in the base directory of the project.
Any help is much appreciated. Thanks!
EDIT:
Ok, the space in the file path was preventing the build. It now compiles and runs but still does not have a dock icon.
Here is the output of the grep command, as requested by Simon Warta:
_Qt_5_1_1_clang_64bit-Debug/Makefile | grep -C 3 icns
443
444 :
445 #$(DEL_FILE)
446 #sed -e "s,#SHORT_VERSION#,1.22,g" -e "s,#TYPEINFO#,????,g" -e "s,#ICON#,myapp.icns,g" -e "s,#EXECUTABLE#,myapp,g" -e "s,#TYPEINFO#,????,g" ../myapp1.22/myapp.plist >
447 myapp.app/Contents/Resources/myapp.icns: ../myapp1.22/myapp.icns
448 #test -d myapp.app/Contents/Resources/ || mkdir -p myapp.app/Contents/Resources/
--
448 #test -d myapp.app/Contents/Resources/ || mkdir -p myapp.app/Contents/Resources/
449 #$(DEL_FILE) myapp.app/Contents/Resources/myapp.icns
450 #$(COPY_FILE) ../myapp1.22/myapp.icns myapp.app/Contents/Resources/myapp.icns
451 dist:
452 #test -d .tmp/myapp1.22 || mkdir -p .tmp/myapp1.22
[[All my source files]]
477 compiler_rcc_clean:
478 -$(DEL_FILE) qrc_myapp.cpp
479 qrc_myapp.cpp: ../myapp1.22/myapp.qrc \
480 ../myapp1.22/myapp.icns \
481 ../myapp1.22/images/splashmyapp2.png \
482 ../myapp1.22/images/splashmyapp1.png \
483 ../myapp1.22/images/About.png \
--
--
481 ../myapp1.22/images/splashmyapp2.png \
482 ../myapp1.22/images/splashmyapp1.png \
483 ../myapp1.22/images/About.png
486 /Users/EngMac/Qt5.1.1/5.1.1/clang_64/bin/rcc -name myapp ../myapp1.22/myapp.qrc -o qrc_myapp.cpp
From myapp.pro:
ICON = myapp.icns
QMAKE_INFO_PLIST = myapp.plist
QMAKE_INFO_PLIST must be called Info.plist. It might be placed in a custom sub-directory of your choice but the filename is fixed. That is because the OS X system will look for a file with that exact filename.
Further debugging tips (orderd by importance):
Post a current error message
Update the Makefile parts cat -n [...]_Qt_5_1_1_clang_64bit-Debug/Makefile | grep -C 4 icns
Search your source code for other places of QMAKE_INFO_PLIST: Call git grep QMAKE_INFO_PLIST in the root of your repository
Post the content of your Info.plist
Post the content of your .pro file
I had to add to Project.pro:
ICON = Project.icns
QMAKE_INFO_PLIST = Info.plist
# Qt doesn't copy over the .icns file ?!
RESOURCE_FILES.files = $$ICON
RESOURCE_FILES.path = Contents/Resources
QMAKE_BUNDLE_DATA += RESOURCE_FILES
and in Info.plist:
<key>CFBundleIconFile</key>
<string>ContentCanvas</string>
It seems that Qt doesn't set the project up to copy the .icns file into the bundle (at least with Qt 5.9), so having it in the .plist file is useless. The last three lines in the .pro file copy it manually.
I can't figure out why in the following the two different versions yield different results:
$(INCLUDE_DIR)/%: TRGT_PATH = \
$(INCLUDE_DIR)/$(patsubst $(word 1,$(subst /, ,$(dir $*)))/%,%,$*)
$(INCLUDE_DIR)/%: INCLUDEDS = $(TRGT_PATH)
$(INCLUDED_FILES) : $(INCLUDE_DIR)/%: %
ifeq ($(TRGT_PATH),$(findstring $(TRGT_PATH),$(INCLUDEDS)))
#echo [INC][WARN] File $(TRGT_PATH) already exists while copying from $*
else
#echo $(findstring $(TRGT_PATH),$(INCLUDEDS))
#echo [INC] $* $(TRGT_PATH)
#cp $* $(TRGT_PATH)
endif
Output:
[INC][WARN] File include/GeometricObject.h already exists while copying from engine/GeometricObject.h
[INC][WARN] File include/util.h already exists while copying from engine/util.h
[INC][WARN] File include/util.h already exists while copying from test/util.h
If I change the line ifeq ($(TRGT_PATH),$(findstring $(TRGT_PATH),$(INCLUDEDS))) to ifneq (,$(findstring $(TRGT_PATH),$(INCLUDEDS))) the output is:
include/GeometricObject.h
[INC] engine/GeometricObject.h include/GeometricObject.h
include/util.h
[INC] engine/util.h include/util.h
include/util.h
[INC] test/util.h include/util.h
As far as I know $(findstring t,l) returns the t if t is in l and else an empty string. But the output (if VAR is equals LIST) still is:
foo
bar
Can someone explain?
PS: I tested a more simple code and that worked fine...
If you'd provided a complete example, including the values of VAR and LIST, we'd be able to help. As it is, all I can say is "it works for me", so you must not be accurately reporting your environment in your question:
$ cat Makefile
VAR = v
LIST = v
all:
ifneq (,$(findstring $(VAR),$(LIST)))
#echo foo
else
#echo bar
endif
$ make
foo
ETA:
Aha. Well, your problem has absolutely nothing to do with findstring, so it's not surprising that your original question was not answerable.
The issue is that you're trying to use target-specific variables in a non-recipe context, and the documentation clearly states that they are not available outside of recipes.
The ifeq, etc. statements are like preprocessor statements: they are evaluated as the makefile is being parsed, not later when the recipes are being invoked. So the values of TRGT_PATH and INCLUDEDS when the ifeq/ifneq is invoked are the global values of those variables (which might be the empty string if they're not set otherwise) not the target-specific values.
I'm searching an autoconf macro to use in my configure.ac that checks for Boost MPI.
It's not hard to find a couple of them on the Internet but none of the one I tried worked as expected.
What ax_boost_mpi.m4 do you use?
EDIT: I'll explain my requirement better. I need the macro to tell me if Boost MPI is available or not (defining HAVE_BOOST_MPI) to store the compiler and linker flags somewhere and to switch the compiler from the nornal c++ compiler to an available mpiCC or mpic++.
If the Boost MPI is not found I'd like to be able to choose if I want to stop the configuration process with an error or continue using g++ without HAVE_BOOST_MPI defined.
As a plus it should define an MPIRUN variable to allow running some checks.
I'm unaware of a turnkey solution here, but that doesn't mean one's unavailable.
With some work, you could probably adapt http://www.gnu.org/software/autoconf-archive/ax_mpi.html#ax_mpi and http://github.com/tsuna/boost.m4 to do what you want. The former digging up the MPI compiler and the latter checking for Boost MPI. You'd have to add a Boost MPI check to boost.m4 as it doesn't have one. You'd have to add your own MPIRUN-searching mechanism.
If you find a solution and/or roll your own, please do share.
# ===========================================================================
#
# SYNOPSIS
#
# AX_BOOST_MPI
#
# DESCRIPTION
#
# Test for MPI library from the Boost C++ libraries. The macro
# requires a preceding call to AX_BOOST_BASE, AX_BOOST_SERIALIZATION
# and AX_MPI. You also need to set CXX="$MPICXX" before calling the
# macro.
#
# This macro calls:
#
# AC_SUBST(BOOST_MPI_LIB)
#
# And sets:
#
# HAVE_BOOST_MPI
#
# LICENSE
#
# Based on Boost Serialize by:
# Copyright (c) 2008 Thomas Porschberg <thomas#randspringer.de>
#
# Copyright (c) 2010 Mirko Maischberger <mirko.maischberger#gmail.com>
#
# Copying and distribution of this file, with or without modification, are
# permitted in any medium without royalty provided the copyright notice
# and this notice are preserved. This file is offered as-is, without any
# warranty.
#serial 1
AC_DEFUN([AX_BOOST_MPI],
[
AC_ARG_WITH([boost-mpi],
AS_HELP_STRING([--with-boost-mpi#<:#=special-lib#:>#],
[use the MPI library from boost - it is possible to
specify a certain library for the linker
e.g. --with-boost-mpi=boost_mpi-gcc-mt-d-1_33_1 ]),
[
if test "$withval" = "no"; then
want_boost="no"
elif test "$withval" = "yes"; then
want_boost="yes"
ax_boost_user_mpi_lib=""
else
want_boost="yes"
ax_boost_user_mpi_lib="$withval"
fi
],
[want_boost="yes"]
)
if test "x$want_boost" = "xyes"; then
AC_REQUIRE([AC_PROG_CC])
CPPFLAGS_SAVED="$CPPFLAGS"
CPPFLAGS="$CPPFLAGS $BOOST_CPPFLAGS"
AC_MSG_WARN(BOOST_CPPFLAGS $BOOST_CPPFLAGS)
export CPPFLAGS
LDFLAGS_SAVED="$LDFLAGS"
LDFLAGS="$LDFLAGS $BOOST_LDFLAGS"
export LDFLAGS
LIBS_SAVED="$LIBS"
LIBS="$LIBS $BOOST_SERIALIZATION_LIB"
export LIBS
AC_CACHE_CHECK(whether the Boost::MPI library is available,
ax_cv_boost_mpi,
[AC_LANG_PUSH([C++])
AC_COMPILE_IFELSE(AC_LANG_PROGRAM([[#%:#include <boost/mpi.hpp>
]],
[[int argc = 0;
char **argv = 0;
boost::mpi::environment env(argc,argv);
return 0;
]]),
ax_cv_boost_mpi=yes, ax_cv_boost_mpi=no)
AC_LANG_POP([C++])
])
if test "x$ax_cv_boost_mpi" = "xyes"; then
AC_DEFINE(HAVE_BOOST_MPI,,[define if the Boost::MPI library is available])
BOOSTLIBDIR=`echo $BOOST_LDFLAGS | sed -e 's/#<:#^\/#:>#*//'`
if test "x$ax_boost_user_mpi_lib" = "x"; then
for libextension in `ls $BOOSTLIBDIR/libboost_mpi*.{so,a}* 2>/dev/null | grep -v python | sed 's,.*/,,' | sed -e 's;^lib\(boost_mpi.*\)\.so.*$;\1;' -e 's;^lib\(boost_mpi.*\)\.a*$;\1;'` ; do
ax_lib=${libextension}
AC_CHECK_LIB($ax_lib, exit,
[BOOST_MPI_LIB="-l$ax_lib"; AC_SUBST(BOOST_MPI_LIB) link_mpi="yes"; break],
[link_mpi="no"])
done
if test "x$link_mpi" != "xyes"; then
for libextension in `ls $BOOSTLIBDIR/boost_mpi*.{dll,a}* 2>/dev/null | grep -v python | sed 's,.*/,,' | sed -e 's;^\(boost_mpi.*\)\.dll.*$;\1;' -e 's;^\(boost_mpi.*\)\.a*$;\1;'` ; do
ax_lib=${libextension}
AC_CHECK_LIB($ax_lib, exit,
[BOOST_MPI_LIB="-l$ax_lib"; AC_SUBST(BOOST_MPI_LIB) link_mpi="yes"; break],
[link_mpi="no"])
done
fi
else
for ax_lib in $ax_boost_user_mpi_lib boost_mpi-$ax_boost_user_mpi_lib; do
AC_CHECK_LIB($ax_lib, exit,
[BOOST_MPI_LIB="-l$ax_lib"; AC_SUBST(BOOST_MPI_LIB) link_mpi="yes"; break],
[link_mpi="no"])
done
fi
if test "x$link_mpi" != "xyes"; then
AC_MSG_ERROR(Could not link against $ax_lib !)
fi
fi
LIBS="$LIBS_SAVED"
CPPFLAGS="$CPPFLAGS_SAVED"
LDFLAGS="$LDFLAGS_SAVED"
fi
])
This comment is a bit late, but I will add it here so that others searching for the same topic can find it. I had personally been looking for a function integrated into boost.m4 that defined similar variables as the other boost libraries (BOOST_MPI_LDFLAGS, BOOST_MPI_LIBS). I finally just added one and submitted a pull request here:
https://github.com/tsuna/boost.m4/pull/50
This uses the MPICXX variable for CXX/CXXCPP if it is already defined (by ax_mpi.m4, acx_mpi.m4, etc), otherwise it uses the existing CXX/CXXCPP.