Re: header check, cross compiling and compiler version?

[Brian Dessent]

aaragon wrote:

> I used to write c++ code in Ubuntu Linux, and then I started working on Mac
> OS so I had to transfer all my c++ code to the new system. My first task was
> to get a newer compiler than the one that is shipped by default with Leopard
> so using macports I compiled GCC v4.3. Now, for my surprise, most of my code
> didn't compile because it seems that the hash_set and hash_map (previously
> found under the ext/ directory) now became unordered_set and unordered_map,
> so I guess they are standard.

You might want to read <http://gcc.gnu.org/gcc-4.3/porting_to.html>. 
Note that the old deprecated SGI headers are still available with a
warning as <backward/hash_map> if you don't want to use the TR1 headers.

> So, I had not only the header problem, but also the compiler version and the
> OS is different as well. I was using autotools before, but I didn't have all
> these checks. Honestly, I don't know how to solve these problems. I still

Checking headers is a bog-standard autoconf action.

AC_INIT([foo],[1.0])
AC_PROG_CC
AC_PROG_CXX
AC_LANG_CPLUSPLUS
AC_CHECK_HEADERS([tr1/unordered_set])
AC_CHECK_HEADERS([tr1/unordered_map])
AC_CHECK_HEADERS([ext/hash_set])
AC_CHECK_HEADERS([ext/hash_map])
AC_CONFIG_HEADERS([config.h])
AC_OUTPUT

Then in your source files:

#include "config.h"
#if defined(HAVE_TR1_UNORDERED_MAP)
#include <tr1/unordered_map>
#elseif defined(HAVE_EXT_HASH_MAP)
#include <ext/hash_map>
#endif
#if defined(HAVE_TR1_UNORDERED_SET)
#include <tr1/unordered_set>
#elseif defined(HAVE_EXT_HASH_SET)
#include <ext/hash_set>
#endif
...

> variable for the  different headers. It would be nice if one could detect
> the system type, and then add directories to the search for headers. I

No, that would not be nice.  What if you later install gcc 4.3 on your
linux system?  Now all your configure tests are wrong.  The autoconf
philosophy is centered around functional or feature tests, not
system-type tests.  You should test whether something exists and is
usable, not what kind of system the test is being run on or what version
of compiler is being used.

> couldn't find anything that accomplishes this so I was wondering if it is
> possible. For example, if I am in a Darwin OS, I could add directories
> /opt/local/include (macports) or /sw/include (fink) to the search. Is there
> a way to do this using autoconf?

Sure, but it's not by hardcoding those values into the configure
script.  Another part of the autotools design is that all things can be
overridden by the user when invoking configure.  If you have some some
location '/foo' that you want searched for headers and libs you do it as
e.g.

./configure CPPFLAGS=-I/foo/include LDFLAGS=-L/foo/lib

You don't hardcode that into the configure script, because what if you
gave it to someone else?  It would be wrong for their system.  What if
you moved the files to another system?  It would be wrong there.  These
settings are normally coupled with an AC_CHECK_LIB or AC_SEARCH_LIB of
some form.  Say for example that the lib that was installed under /foo
was libbar, then you'd have

AC_CHECK_LIB([bar],[barfunc])

This does a check that -lbar works and contains barfunc(), which coupled
with your settings of CPPFLAGS and LDFLAGS should succeed, which causes
-lbar to be added to LIBS which you can refer to by @LIBS@ on the link
command in your Makefile.

In other words, the stuff that is specific to your package ("this
package needs libbar, so check that it can be found") goes in your
configure.ac, whereas the stuff that is specific to your site ("libbar
on this machine is installed under /foo, so use -I/foo/include when
compiling and -L/foo/lib when linking") stays out of configure.ac.

If the issue is not wanting to type a bunch of "CC=... CXX=...
CPPFLAGS=... LDFLAGS=... CFLAGS=... CXXFLAGS=... --prefix=..." every
time you run configure, then you can create a config.site file that
contains this info -- that is where machine-specific things live.  See
section 14.7 of the manual for details.

> What is the best approach to take in these cases? Do you define parameters
> in config.h for later use for each OS, compiler version? Please help, I'm
> really lost,

No, that is pretty much the opposite of how autoconf is supposed to
work.

Brian