Thanks Brian, I really appreciate your comments. I think you answered all the doubts that I had. Now I understand much better what I should be doing with the script. aa Brian Dessent wrote: > > 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 > > > _______________________________________________ > Autoconf mailing list > Autoconf@xxxxxxx > http://lists.gnu.org/mailman/listinfo/autoconf > > -- View this message in context: http://www.nabble.com/header-check%2C-cross-compiling-and-compiler-version--tp16214369p16223868.html Sent from the Gnu - Autoconf - General mailing list archive at Nabble.com. _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
