diff --git a/.github/workflows/auto_tools.yml b/.github/workflows/auto_tools.yml index a70535e95bd..810c797e41f 100644 --- a/.github/workflows/auto_tools.yml +++ b/.github/workflows/auto_tools.yml @@ -14,35 +14,26 @@ jobs: build: strategy: matrix: - os: [ubuntu-22.04, ubuntu-20.04] + os: [ubuntu-24.04] gnu: [9] runs-on: ${{ matrix.os }} env: - CC: /usr/bin/gcc-${{ matrix.gnu }} - CXX: /usr/bin/g++-${{ matrix.gnu }} - LD_LIBRARY_PATH: /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server:/usr/lib/x86_64-linux-gnu + LD_LIBRARY_PATH: /usr/lib/jvm/java-17-openjdk-amd64/lib/server steps: - - uses: actions/checkout@v3 - - uses: actions/setup-java@v3 + - uses: actions/checkout@v4 with: - distribution: 'temurin' - java-version: '8' + submodules: 'recursive' + token: ${{ secrets.SUBMODULE_TOKEN }} - - name: Checkout submodules - shell: bash - run: | - git submodule sync --recursive - git -c "http.extraheader=Authorization: basic ${{ secrets.SUBMODULE_TOKEN }}" -c protocol.version=2 submodule update --init --force --recursive --depth=1 - git submodule status + # NOTE: Ubuntu 24.04 ships antlr4 v4.9 but antlr4-cpp-runtime v4.10, which are API-incompatible; manually install the matching antlr4 v4.10. + - uses: StoneMoe/setup-antlr4@v4.10.1 - name: Install dependencies run: | sudo apt-get update - sudo apt-get install -y openjdk-8-jdk && \ sudo apt-get install -y \ - antlr4 \ automake \ autotools-dev \ bison \ @@ -59,6 +50,7 @@ jobs: libantlr4-runtime-dev \ libboost-all-dev \ libtool \ + openjdk-17-jdk \ python3-dev - name: Configure @@ -67,7 +59,8 @@ jobs: ./build mkdir ../rex_build cd ../rex_build - $GITHUB_WORKSPACE/configure --prefix=$GITHUB_WORKSPACE/../rex_install --with-boost=/usr --with-boost-libdir=/usr/lib/x86_64-linux-gnu --enable-languages=c,c++,fortran --disable-tests-directory --disable-tutorial-directory + CC=gcc-${{ matrix.gnu }} CXX=g++-${{ matrix.gnu }} FC=gfortran-${{ matrix.gnu }} \ + $GITHUB_WORKSPACE/configure --prefix=$GITHUB_WORKSPACE/../rex_install --with-boost=/usr --with-boost-libdir=/usr/lib/x86_64-linux-gnu --enable-languages=c,c++,fortran - name: Build run: | @@ -78,8 +71,4 @@ jobs: - name: Test run: | cd $GITHUB_WORKSPACE/../rex_build - make check-core -j2 - cd $GITHUB_WORKSPACE/../rex_build/tests/nonsmoke/functional/CompileTests/OpenMP_tests - make check -j2 - cd $GITHUB_WORKSPACE/../rex_build/tests/nonsmoke/functional/roseTests/astInterfaceTests - make check -j2 + make check-rex -j2 diff --git a/.github/workflows/cmake.yml b/.github/workflows/cmake.yml index 5059e663d1b..658626d5cf2 100644 --- a/.github/workflows/cmake.yml +++ b/.github/workflows/cmake.yml @@ -14,35 +14,26 @@ jobs: build: strategy: matrix: - os: [ubuntu-22.04, ubuntu-20.04] + os: [ubuntu-24.04] gnu: [9] runs-on: ${{ matrix.os }} env: - CC: /usr/bin/gcc-${{ matrix.gnu }} - CXX: /usr/bin/g++-${{ matrix.gnu }} - LD_LIBRARY_PATH: /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server:/usr/lib/x86_64-linux-gnu + LD_LIBRARY_PATH: /usr/lib/jvm/java-17-openjdk-amd64/lib/server steps: - - uses: actions/checkout@v3 - - uses: actions/setup-java@v3 + - uses: actions/checkout@v4 with: - distribution: 'temurin' - java-version: '8' + submodules: 'recursive' + token: ${{ secrets.SUBMODULE_TOKEN }} - - name: Checkout submodules - shell: bash - run: | - git submodule sync --recursive - git -c "http.extraheader=Authorization: basic ${{ secrets.SUBMODULE_TOKEN }}" -c protocol.version=2 submodule update --init --force --recursive --depth=1 - git submodule status + # NOTE: Ubuntu 24.04 ships antlr4 v4.9 but antlr4-cpp-runtime v4.10, which are API-incompatible; manually install the matching antlr4 v4.10. + - uses: StoneMoe/setup-antlr4@v4.10.1 - name: Install dependencies run: | sudo apt-get update - sudo apt-get install -y openjdk-8-jdk && \ sudo apt-get install -y \ - antlr4 \ automake \ autotools-dev \ bison \ @@ -59,6 +50,7 @@ jobs: libantlr4-runtime-dev \ libboost-all-dev \ libtool \ + openjdk-17-jdk \ python3-dev - name: Configure @@ -66,7 +58,8 @@ jobs: cd $GITHUB_WORKSPACE mkdir ../rex_build cd ../rex_build - cmake -Denable-c=ON -Denable-fortran=ON -DCMAKE_INSTALL_PREFIX=$GITHUB_WORKSPACE/../rex_install $GITHUB_WORKSPACE + CC=gcc-${{ matrix.gnu }} CXX=g++-${{ matrix.gnu }} FC=gfortran-${{ matrix.gnu }} \ + cmake -Denable-c=ON -Denable-fortran=ON -DCMAKE_INSTALL_PREFIX=$GITHUB_WORKSPACE/../rex_install -Ddisable-tests-directory=ON $GITHUB_WORKSPACE - name: Build run: | diff --git a/CMakeLists.txt b/CMakeLists.txt index bce626bc786..9d96fe6f248 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -24,6 +24,7 @@ # 8. If a CMakefile file needs to be conditionally enabled, do it in that CMake file rather than around the # add_subdirectory in the level above. This keeps all the logic for a directory in a single file rather than # split across two files. It is a bit unfortunate that CMake can't find the lower-level CMakeList files + # on its own, so some of the logic is still necessarily in the level above. There are exceptions to this rule, # and they're pretty obvious when they occur--as when a single if() protects a whole bunch of add_subdirectory. @@ -96,7 +97,7 @@ else() set(CMAKE_VERBOSE_MAKEFILE FALSE) endif() -set(CMAKE_CXX_STANDARD 14) +set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) option(BUILD_SHARED_LIBS "Build all libraries shared" FALSE) @@ -112,8 +113,6 @@ if(WIN32) add_definitions(-D_CRT_SECURE_NO_WARNINGS) endif() -add_definitions(-DBOOST_ALL_NO_LIB=1) - # FIXME: Why do we have to have a copy of some standard built-in modules inside rose? set(CMAKE_MODULE_PATH "${CMAKE_SOURCE_DIR}/cmake" "${CMAKE_SOURCE_DIR}/cmake/modules" ${CMAKE_MODULE_PATH}) @@ -148,93 +147,14 @@ file(READ ${ROSE_SCM_DATE_FILE} ROSE_VERSION) message(STATUS "The ROSE version integer is ${ROSE_VERSION}") message(STATUS "The ROSE version string is ${ROSE_PACKAGE_VERSION}") -######################################################################################################################## -# Boost libraries -######################################################################################################################## - -message(STATUS - "If you get a whole bunch of warnings saying 'New Boost version may have incorrect or missing dependencies and " - "imported targets' it is probably because you're using a Boost version that was released after your CMake version. " - "See [https://github.com/Kitware/CMake/commits/master/Modules/FindBoost.cmake] to see latest supported version and " - "[https://github.com/Microsoft/vcpkg/issues/2459] for a description of the problem. Note that CMake versions " - "3.11.0 through 3.13.2 and possibly later) cannot be compiled (syntax errors) with a GNU C++ compiler that's " - "configured to use a non-default language standard (e.g., C++11 with GCC-5.4 whose default is GNU++03).") - -set(Boost_USE_STATIC_LIBS FALSE) -set(Boost_DEBUG ${VERBOSE}) - -# Honor BOOST_HOME environment variable -if(DEFINED ENV{BOOST_HOME}) - set(BOOST_ROOT "$ENV{BOOST_HOME}") -endif() - -option(Boost_USE_MULTITHREADED "Should Boost multithreaded libraries be used?" OFF) - -if(WIN32) - find_package(Boost REQUIRED) - set(BOOST_LIBRARYDIR ${Boost_LIBRARY_DIRS}) - set(BOOST_INCLUDEDIR ${Boost_INCLUDE_DIRS}/) - - message("Boost information:") - message(" BOOST_ROOT: ${BOOST_ROOT}") - message(" Boost_INCLUDE_DIRS: ${Boost_INCLUDE_DIRS}") - message(" Boost_LIBRARIES: ${Boost_LIBRARIES}") - message(" Boost_LIBRARY_DIRS: ${Boost_LIBRARY_DIRS}") - message(" BOOST_LIBRARYDIR : ${BOOST_LIBRARYDIR}") - message(" BOOST_INCLUDEDIR : ${BOOST_INCLUDEDIR}") - - include_directories(${Boost_INCLUDE_DIRS}) - link_directories(${Boost_LIBRARY_DIRS}) -endif(WIN32) - -# FIXME: 1.47 is no longer supported by ROSE, but is what's installed on Jenkins' CMake test machine. This should -# be changed to the actual minimum supported version once Pei-Hung upgrades the machine. [Matzke 2019-01-21] -# -# First look for the Boost libraries that are required in order to compile ROSE, then additionally look for any optional -# libraries that are useful to ROSE but not required. From a user: "The find_package() change is required for boost -# 1.70 or above on any system when using a recent enough version of cmake. Without it, serialization support will not -# be used. Before boost 1.70, the findBoost() in cmake is used directly, and it will look for boost components that are -# not in the find_package clause. Since 1.70, cmake will load the findBoost() provided by the boost package itself. -# Unfortunately, that findBoost() will only check for components in the find_package() clause. This means that -# serialization is considered not to exist, even if it is there. My change calls find_package again without the -# REQUIRED clause after the first one has succeeded. That way the first clause checks for requires components, and the -# second can check again including optional components. If the version of cmake is high enough you can use an -# OPTIONAL_COMPONENTS clause instead, but that wasn't introduced until 3.11." -find_package(Boost 1.47.0 - COMPONENTS chrono date_time filesystem iostreams program_options random regex system wave thread - REQUIRED) -if(NOT Boost_FOUND) - message(FATAL_ERROR "Could not find Boost version 1.35.0 or newer command") -endif() -find_package(Boost 1.47.0 - COMPONENTS chrono date_time filesystem iostreams program_options random regex system wave thread serialization) -include_directories(${Boost_INCLUDE_DIRS}) - # Paths to install header, executable, and libraries set(INCLUDE_INSTALL_DIR "include/rose") set(BIN_INSTALL_DIR "bin") set(LIB_INSTALL_DIR "${ROSE_LIB_DIR_NAME}") -set(INSTALL_TARGETS_DEFAULT_ARGS - RUNTIME DESTINATION "${BIN_INSTALL_DIR}" - LIBRARY DESTINATION "${LIB_INSTALL_DIR}" - ARCHIVE DESTINATION "${LIB_INSTALL_DIR}" - COMPONENT Devel) - # A new definition to tweak code for cmake set(USE_CMAKE 1) -# ROSE configuration variables for Boost -set(HAVE_BOOST ${Boost_FOUND}) -set(HAVE_BOOST_SERIALIZATION_LIB ${Boost_SERIALIZATION_FOUND}) -set(HAVE_BOOST_DATE_TIME ${Boost_DATE_TIME_FOUND}) -set(HAVE_BOOST_FILESYSTEM ${Boost_FILESYSTEM_FOUND}) -set(HAVE_BOOST_PROGRAM_OPTIONS ${Boost_PROGRAM_OPTIONS_FOUND}) -set(HAVE_BOOST_REGEX ${Boost_REGEX_FOUND}) -set(HAVE_BOOST_SYSTEM ${Boost_SYSTEM_FOUND}) -set(HAVE_BOOST_THREAD ${Boost_THREAD_FOUND}) -set(HAVE_BOOST_WAVE ${Boost_WAVE_FOUND}) -set(USE_ROSE_BOOST_WAVE_SUPPORT ${Boost_WAVE_FOUND}) ######################################################################################################################## # ROSETTA @@ -512,7 +432,7 @@ if(enable-microsoft-extensions) endif() if(enable-fortran) - set(enable-ofp-version "20200819-JDK8" CACHE STRING "version number for OFP") + set(enable-ofp-version "20200704" CACHE STRING "version number for OFP") set($ENV{CLASSPATH} ${CMAKE_SOURCE_DIR}/src/3rdPartyLibraries/antlr-jars/antlr-3.5.2-complete.jar::${CMAKE_SOURCE_DIR}/rc/3rdPartyLibraries/fortran-parser/OpenFortranParser-${enable-ofp-version}.jar) endif() @@ -621,12 +541,12 @@ endif() # define a global variable to collect all common linked third-party libraries for rose if(NOT WIN32) if(NOT APPLE) - set(link_with_libraries ${Boost_LIBRARIES} ${M_LIB} ${RT_LIB} ${CMAKE_THREAD_LIBS_INIT}) + set(link_with_libraries ${M_LIB} ${RT_LIB} ${CMAKE_THREAD_LIBS_INIT}) else() - set(link_with_libraries ${Boost_LIBRARIES} ${M_LIB} ${CMAKE_THREAD_LIBS_INIT}) + set(link_with_libraries ${M_LIB} ${CMAKE_THREAD_LIBS_INIT}) endif() else() - set(link_with_libraries ${Boost_LIBRARIES} shlwapi.lib psapi.lib) + set(link_with_libraries shlwapi.lib psapi.lib) endif() # Check compilers and version numbers. The module is located in src/cmake/modules. diff --git a/Makefile.am b/Makefile.am index 66d280193f5..d8cfad4cc85 100644 --- a/Makefile.am +++ b/Makefile.am @@ -253,12 +253,7 @@ endif @echo '***** make install-data rule complete (terminated normally) *****' @echo '*****************************************************************' -# DQ (4/22/2005): Set this so that make distcheck will use the same -# --with-edg_source_code=true/false option as were used at configure. -# JJW (5/14/2008): Add the Boost flag the same way, using an internal -# variable from AX_BOOST_* to find the argument to --with-boost when -# this copy of ROSE was originally configured. -DISTCHECK_CONFIGURE_FLAGS = --with-boost=$(ac_boost_path) +DISTCHECK_CONFIGURE_FLAGS = # DQ (7/25/2008): If ROSE was originallly configured with Fortran (by tuning # on the java support) then make sure it is tested as part of the distcheck rule. diff --git a/config/Makefile.for.ROSE.includes.and.libs b/config/Makefile.for.ROSE.includes.and.libs index fdb844c4ba6..b85f79a012c 100644 --- a/config/Makefile.for.ROSE.includes.and.libs +++ b/config/Makefile.for.ROSE.includes.and.libs @@ -32,12 +32,8 @@ if USE_ROSE_IN_BUILD_TREE_VAR export ROSE_IN_BUILD_TREE=$(top_builddir) endif -# DQ (12/22/2008): Specification of Boost path for use with "-isystem" option (may be GNU -# specific). We use this option only if the configuration of ROSE has detected a -# previously installed version of Boost (which we do not want to use). -# Note that only one of these will be non-empty makefile variables. -ROSE_BOOST_PREINCLUDE_PATH = @ROSE_BOOST_PREINCLUDE_PATH@ -ROSE_BOOST_NORMAL_INCLUDE_PATH = @ROSE_BOOST_NORMAL_INCLUDE_PATH@ +# Force C++17 (-std=c++17) to enable modern language features across all compilers. +AM_CXXFLAGS = -std=c++17 # This is properly handled by automake even when specified in an include file EDG_LIBS = @EDG_LIBS@ @@ -129,8 +125,7 @@ ROSE_INCLUDES_WITHOUT_BOOST_ISYSTEM_PATH_ROSE_USE_INTERNAL_FRONTEND_DEVELOPMENT -I$(top_srcdir)/src/midend/programAnalysis \ -I$(top_srcdir)/src/3rdPartyLibraries/json \ -I$(top_srcdir)/src/util/graphs \ - $(ROSE_FLANG_INCLUDES) \ - $(ROSE_BOOST_NORMAL_INCLUDE_PATH) + $(ROSE_FLANG_INCLUDES) # else # ROSE_USE_INTERNAL_FRONTEND_DEVELOPMENT # ROSE_INCLUDES = # $(ROSE_BOOST_PREINCLUDE_PATH) @@ -209,9 +204,7 @@ ROSE_INCLUDES_WITHOUT_BOOST_ISYSTEM_PATH = \ -I$(top_srcdir)/src/midend/astUtil/astInterface \ -I$(top_srcdir)/libltdl \ $(VALGRIND_CFLAGS) \ - $(ROSE_BOOST_NORMAL_INCLUDE_PATH) \ - $(ROSE_PCH_INCLUDE) \ - $(BOOST_CPPFLAGS) + $(ROSE_PCH_INCLUDE) # endif # ROSE_USE_INTERNAL_FRONTEND_DEVELOPMENT # DQ (10/23/2015): These paths have been replaces with the following variables. @@ -223,12 +216,7 @@ ROSE_INCLUDES_WITHOUT_BOOST_ISYSTEM_PATH = \ # $(ROSE_CLANG_INCLUDE) SWIG_ROSE_INCLUDES = $(ROSE_INCLUDES_WITHOUT_BOOST_ISYSTEM_PATH) -ROSE_INCLUDES = -I$(top_builddir) -I$(top_builddir)/src $(ROSE_BOOST_PREINCLUDE_PATH) $(ROSE_INCLUDES_WITHOUT_BOOST_ISYSTEM_PATH) - -# DQ (12/22/2008): Move Boost directory to front and used "-isystem" option so -# that a system with a previous (older) installation of boost does not interfer -# with the use of ROSE (and the version of boost specified using "--with-boost"). -# $(BOOST_CPPFLAGS) +ROSE_INCLUDES = -I$(top_builddir) -I$(top_builddir)/src $(ROSE_INCLUDES_WITHOUT_BOOST_ISYSTEM_PATH) # DQ (10/28/2008): I think these should be included, I don't know why they # were removed (used with Microsoft Windows tests, and Yices tests). @@ -244,17 +232,7 @@ ROSE_INCLUDES = -I$(top_builddir) -I$(top_builddir)/src $(ROSE_BOOST_PREINCLUDE_ # JJW 7/25/2008: This should probably just be the same as ROSE_LIBS ROSE_LIBS_WITH_PATH = $(ROSE_LIBS) -# ROSE_LIBS = $(top_builddir)/src/librose.la -lm $(LEXLIB) $(WAVE_LDFLAGS) $(WAVE_LIBRARIES) $(WAVE_LIBS) $(JAVA_JVM_LIB) $(RT_LIBS) - -# MS 10/19/2015: added ROSE_BOOST_LIBS variable to share exact same -# boost libs list in ROSE an in the ROSTTA Makefiles. -ROSE_BOOST_LIBS=$(BOOST_LDFLAGS) $(BOOST_DATE_TIME_LIB) $(BOOST_CHRONO_LIB) \ - $(BOOST_THREAD_LIB) $(BOOST_FILESYSTEM_LIB) $(BOOST_PROGRAM_OPTIONS_LIB) \ - $(BOOST_RANDOM_LIB) $(BOOST_REGEX_LIB) $(BOOST_SYSTEM_LIB) $(BOOST_SERIALIZATION_LIB) \ - $(BOOST_WAVE_LIB) $(BOOST_IOSTREAMS_LIB) $(BOOST_ATOMIC_LIB) - ROSE_LIBS = $(abspath $(top_builddir)/src/librose.la) -lm $(JAVA_JVM_LINK) \ - $(ROSE_BOOST_LIBS) \ $(RT_LIBS) \ $(ROSE_INTEL_COMPILER_MATH_LIBS) \ $(ROSE_QUAD_FLOAT_MATH) diff --git a/config/automake_conditional_display_makefile b/config/automake_conditional_display_makefile index 6c444c033f9..d2bf6b48d8a 100644 --- a/config/automake_conditional_display_makefile +++ b/config/automake_conditional_display_makefile @@ -159,11 +159,6 @@ if ROSE_PCH else @echo "Automake conditional ROSE_PCH: NOT defined" endif -if ROSE_USE_BOOST_WAVE - @echo "Automake conditional ROSE_USE_BOOST_WAVE: DEFINED" -else - @echo "Automake conditional ROSE_USE_BOOST_WAVE: NOT defined" -endif if ROSE_USE_GCC_OMP @echo "Automake conditional ROSE_USE_GCC_OMP: DEFINED" else @@ -219,61 +214,6 @@ if ROSE_USE_WGET else @echo "Automake conditional ROSE_USE_WGET: NOT defined" endif -if ROSE_USING_BOOST_VERSION_1_35 - @echo "Automake conditional ROSE_USING_BOOST_VERSION_1_35: DEFINED" -else - @echo "Automake conditional ROSE_USING_BOOST_VERSION_1_35: NOT defined" -endif -if ROSE_USING_BOOST_VERSION_1_36 - @echo "Automake conditional ROSE_USING_BOOST_VERSION_1_36: DEFINED" -else - @echo "Automake conditional ROSE_USING_BOOST_VERSION_1_36: NOT defined" -endif -if ROSE_USING_BOOST_VERSION_1_37 - @echo "Automake conditional ROSE_USING_BOOST_VERSION_1_37: DEFINED" -else - @echo "Automake conditional ROSE_USING_BOOST_VERSION_1_37: NOT defined" -endif -if ROSE_USING_BOOST_VERSION_1_38 - @echo "Automake conditional ROSE_USING_BOOST_VERSION_1_38: DEFINED" -else - @echo "Automake conditional ROSE_USING_BOOST_VERSION_1_38: NOT defined" -endif -if ROSE_USING_BOOST_VERSION_1_39 - @echo "Automake conditional ROSE_USING_BOOST_VERSION_1_39: DEFINED" -else - @echo "Automake conditional ROSE_USING_BOOST_VERSION_1_39: NOT defined" -endif -if ROSE_USING_BOOST_VERSION_1_40 - @echo "Automake conditional ROSE_USING_BOOST_VERSION_1_40: DEFINED" -else - @echo "Automake conditional ROSE_USING_BOOST_VERSION_1_40: NOT defined" -endif -if ROSE_USING_BOOST_VERSION_1_41 - @echo "Automake conditional ROSE_USING_BOOST_VERSION_1_41: DEFINED" -else - @echo "Automake conditional ROSE_USING_BOOST_VERSION_1_41: NOT defined" -endif -if ROSE_USING_BOOST_VERSION_1_42 - @echo "Automake conditional ROSE_USING_BOOST_VERSION_1_42: DEFINED" -else - @echo "Automake conditional ROSE_USING_BOOST_VERSION_1_42: NOT defined" -endif -if ROSE_USING_BOOST_VERSION_1_43 - @echo "Automake conditional ROSE_USING_BOOST_VERSION_1_43: DEFINED" -else - @echo "Automake conditional ROSE_USING_BOOST_VERSION_1_43: NOT defined" -endif -if ROSE_USING_BOOST_VERSION_1_44 - @echo "Automake conditional ROSE_USING_BOOST_VERSION_1_44: DEFINED" -else - @echo "Automake conditional ROSE_USING_BOOST_VERSION_1_44: NOT defined" -endif -if ROSE_USING_BOOST_VERSION_1_45 - @echo "Automake conditional ROSE_USING_BOOST_VERSION_1_45: DEFINED" -else - @echo "Automake conditional ROSE_USING_BOOST_VERSION_1_45: NOT defined" -endif if ROSE_USING_GFORTRAN_VERSION_4_0 @echo "Automake conditional ROSE_USING_GFORTRAN_VERSION_4_0: DEFINED" else @@ -284,11 +224,6 @@ if ROSE_USING_GFORTRAN_VERSION_4_1 else @echo "Automake conditional ROSE_USING_GFORTRAN_VERSION_4_1: NOT defined" endif -if ROSE_USING_GRAPH_IR_NODES_FOR_BACKWARD_COMPATABILITY - @echo "Automake conditional ROSE_USING_GRAPH_IR_NODES_FOR_BACKWARD_COMPATABILITY: DEFINED" -else - @echo "Automake conditional ROSE_USING_GRAPH_IR_NODES_FOR_BACKWARD_COMPATABILITY: NOT defined" -endif if ROSE_USING_ROSE @echo "Automake conditional ROSE_USING_ROSE: DEFINED" else diff --git a/config/ax_boost_asio.m4 b/config/ax_boost_asio.m4 deleted file mode 100644 index 443fec35ca5..00000000000 --- a/config/ax_boost_asio.m4 +++ /dev/null @@ -1,103 +0,0 @@ -##### http://autoconf-archive.cryp.to/ax_boost_asio.html -# -# SYNOPSIS -# -# AX_BOOST_ASIO -# -# DESCRIPTION -# -# Test for Asio library from the Boost C++ libraries. The macro -# requires a preceding call to AX_BOOST_BASE. Further documentation -# is available at . -# -# This macro calls: -# -# AC_SUBST(BOOST_ASIO_LIB) -# -# And sets: -# -# HAVE_BOOST_ASIO -# -# COPYLEFT -# -# Copyright (c) 2007 Thomas Porschberg -# Copyright (c) 2007 Pete Greenwell -# -# 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. - -AC_DEFUN([AX_BOOST_ASIO], -[ - AC_ARG_WITH([boost-asio], - AS_HELP_STRING([--with-boost-asio@<:@=special-lib@:>@], - [use the ASIO library from boost - it is possible to specify a certain library for the linker - e.g. --with-boost-asio=boost_system-gcc41-mt-1_34 ]), - [ - if test "$withval" = "no"; then - want_boost="no" - elif test "$withval" = "yes"; then - want_boost="yes" - ax_boost_user_asio_lib="" - else - want_boost="yes" - ax_boost_user_asio_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" - export CPPFLAGS - - LDFLAGS_SAVED="$LDFLAGS" - LDFLAGS="$LDFLAGS $BOOST_LDFLAGS" - export LDFLAGS - - AC_CACHE_CHECK(whether the Boost::ASIO library is available, - ax_cv_boost_asio, - [AC_LANG_PUSH([C++]) - AC_COMPILE_IFELSE(AC_LANG_PROGRAM([[ @%:@include - ]], - [[ - - boost::asio::io_service io; - boost::system::error_code timer_result; - boost::asio::deadline_timer t(io); - t.cancel(); - io.run_one(); - return 0; - ]]), - ax_cv_boost_asio=yes, ax_cv_boost_asio=no) - AC_LANG_POP([C++]) - ]) - if test "x$ax_cv_boost_asio" = "xyes"; then - AC_DEFINE(HAVE_BOOST_ASIO,,[define if the Boost::ASIO library is available]) - BN=boost_system - if test "x$ax_boost_user_asio_lib" = "x"; then - for ax_lib in $BN $BN-$CC $BN-$CC-mt $BN-$CC-mt-s $BN-$CC-s \ - lib$BN lib$BN-$CC lib$BN-$CC-mt lib$BN-$CC-mt-s lib$BN-$CC-s \ - $BN-mgw $BN-mgw $BN-mgw-mt $BN-mgw-mt-s $BN-mgw-s ; do - AC_CHECK_LIB($ax_lib, main, [BOOST_ASIO_LIB="-l$ax_lib" AC_SUBST(BOOST_ASIO_LIB) link_thread="yes" break], - [link_thread="no"]) - done - else - for ax_lib in $ax_boost_user_asio_lib $BN-$ax_boost_user_asio_lib; do - AC_CHECK_LIB($ax_lib, main, - [BOOST_ASIO_LIB="-l$ax_lib" AC_SUBST(BOOST_ASIO_LIB) link_asio="yes" break], - [link_asio="no"]) - done - - fi - if test "x$link_asio" = "xno"; then - AC_MSG_ERROR([could not link against "$ax_lib"]) - fi - fi - - CPPFLAGS="$CPPFLAGS_SAVED" - LDFLAGS="$LDFLAGS_SAVED" - fi -]) diff --git a/config/ax_boost_atomic.m4 b/config/ax_boost_atomic.m4 deleted file mode 100644 index a71d0c3f4b7..00000000000 --- a/config/ax_boost_atomic.m4 +++ /dev/null @@ -1,106 +0,0 @@ -##### http://autoconf-archive.cryp.to/ax_boost_atomic.html -# -# SYNOPSIS -# -# AX_BOOST_ATOMIC -# -# DESCRIPTION -# -# Test for Atomic library from the Boost C++ libraries. The macro -# requires a preceding call to AX_BOOST_BASE. Further documentation -# is available at . -# -# This macro calls: -# -# AC_SUBST(BOOST_ATOMIC_LIB) -# -# And sets: -# -# HAVE_BOOST_ATOMIC -# -# COPYLEFT -# -# Copyright (c) 2007 Thomas Porschberg -# Copyright (c) 2007 Michael Tindal -# -# 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. - -AC_DEFUN([AX_BOOST_ATOMIC], -[ - AC_ARG_WITH([boost-atomic], - AS_HELP_STRING([--with-boost-atomic@<:@=special-lib@:>@], - [use the Atomic library from boost - it is possible to specify a certain library for the linker - e.g. --with-boost-atomic=boost_atomic-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_atomic_lib="" - else - want_boost="yes" - ax_boost_user_atomic_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" - export CPPFLAGS - - LDFLAGS_SAVED="$LDFLAGS" - LDFLAGS="$LDFLAGS $BOOST_LDFLAGS" - export LDFLAGS - - AC_CACHE_CHECK(whether the Boost::Atomic library is available, - ax_cv_boost_atomic, - [AC_LANG_PUSH([C++]) - AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[@%:@include ]], - [[boost::atomic r; return 0;]])], - ax_cv_boost_atomic=yes, ax_cv_boost_atomic=no) - AC_LANG_POP([C++]) - ]) - - if test "x$ax_cv_boost_atomic" = "xyes"; then - AC_DEFINE(HAVE_BOOST_ATOMIC,,[define if the Boost::Atomic library is available]) - BOOSTLIBDIR=`echo $BOOST_LDFLAGS | sed -e 's/@<:@^\/@:>@*//'` - - if test "x$ax_boost_user_atomic_lib" = "x"; then - - for libextension in `ls $BOOSTLIBDIR/libboost_atomic*.{so,dylib,a}* 2>/dev/null | sed 's,.*/,,' | sed -e 's;^lib\(boost_atomic.*\)\.so.*$;\1;' -e 's;^lib\(boost_atomic.*\)\.a*$;\1;' -e 's;^lib\(boost_atomic.*\)\.dylib$;\1;'` ; do - ax_lib=${libextension} - AC_CHECK_LIB($ax_lib, toupper, - [BOOST_ATOMIC_LIB="-l$ax_lib"; AC_SUBST(BOOST_ATOMIC_LIB) link_atomic="yes"; break], - [link_atomic="no"]) - done - - if test "x$link_atomic" != "xyes"; then - for libextension in `ls $BOOSTLIBDIR/boost_atomic*.{dll,a}* 2>/dev/null | sed 's,.*/,,' | sed -e 's;^\(boost_atomic.*\)\.dll.*$;\1;' -e 's;^\(boost_atomic.*\)\.a*$;\1;'` ; do - ax_lib=${libextension} - AC_CHECK_LIB($ax_lib, toupper, - [BOOST_ATOMIC_LIB="-l$ax_lib"; AC_SUBST(BOOST_ATOMIC_LIB) link_atomic="yes"; break], - [link_atomic="no"]) - done - fi - else - for ax_lib in $ax_boost_user_atomic_lib boost_atomic-$ax_boost_user_atomic_lib; do - AC_CHECK_LIB($ax_lib, main, - [BOOST_ATOMIC_LIB="-l$ax_lib"; AC_SUBST(BOOST_ATOMIC_LIB) link_atomic="yes"; break], - [link_atomic="no"]) - done - fi - - if test "x$link_atomic" != "xyes"; then - AC_MSG_ERROR([could not link against "$ax_lib"]) - fi - fi - - CPPFLAGS="$CPPFLAGS_SAVED" - LDFLAGS="$LDFLAGS_SAVED" - fi -]) diff --git a/config/ax_boost_base.m4 b/config/ax_boost_base.m4 deleted file mode 100644 index f4a2e086e89..00000000000 --- a/config/ax_boost_base.m4 +++ /dev/null @@ -1,290 +0,0 @@ -##### http://autoconf-archive.cryp.to/ax_boost_base.html -# -# SYNOPSIS -# -# AX_BOOST_BASE([MINIMUM-VERSION]) -# -# DESCRIPTION -# -# Test for the Boost C++ libraries of a particular version (or newer) -# -# If no path to the installed boost library is given the macro -# searchs under /usr, /usr/local, /opt and /opt/local and evaluates -# the $BOOST_ROOT environment variable. Further documentation is -# available at . -# -# This macro calls: -# -# AC_SUBST(BOOST_CPPFLAGS) / AC_SUBST(BOOST_LDFLAGS) -# -# And sets: -# -# HAVE_BOOST -# -# COPYLEFT -# -# Copyright (c) 2008 Thomas Porschberg -# -# 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. - -AC_DEFUN([AX_BOOST_BASE], -[ -AC_ARG_WITH([boost], - AS_HELP_STRING([--with-boost@<:@=DIR@:>@], [use boost (default is yes) - it is possible to specify the root directory for boost (optional)]), - [ - if test "$withval" = "no"; then - want_boost="no" - elif test "$withval" = "yes"; then - want_boost="yes" - ac_boost_path="" - else - want_boost="yes" - ac_boost_path="$withval" - fi - ], - [want_boost="yes"]) - - -AC_ARG_WITH([boost-libdir], - AS_HELP_STRING([--with-boost-libdir=LIB_DIR], - [Force given directory for boost libraries. Note that this will overwrite library path detection, so use this parameter only if default library detection fails and you know exactly where your boost libraries are located.]), - [ - if test -d $withval - then - ac_boost_lib_path="$withval" - else - AC_MSG_ERROR([--with-boost-libdir expected directory name]) - fi - ], - [ac_boost_lib_path=""] -) - -if test "x$want_boost" = "xyes"; then - boost_lib_version_req=ifelse([$1], ,1.20.0,$1) - boost_lib_version_req_shorten=`expr $boost_lib_version_req : '\([[0-9]]*\.[[0-9]]*\)'` - boost_lib_version_req_major=`expr $boost_lib_version_req : '\([[0-9]]*\)'` - boost_lib_version_req_minor=`expr $boost_lib_version_req : '[[0-9]]*\.\([[0-9]]*\)'` - boost_lib_version_req_sub_minor=`expr $boost_lib_version_req : '[[0-9]]*\.[[0-9]]*\.\([[0-9]]*\)'` - if test "x$boost_lib_version_req_sub_minor" = "x" ; then - boost_lib_version_req_sub_minor="0" - fi - WANT_BOOST_VERSION=`expr $boost_lib_version_req_major \* 100000 \+ $boost_lib_version_req_minor \* 100 \+ $boost_lib_version_req_sub_minor` - AC_MSG_CHECKING(for boostlib >= $boost_lib_version_req) - succeeded=no - - # DQ (2/4/2010): Added to support setting Automake conditionals for boost versions. - # export boost_lib_version_req_major - # export boost_lib_version_req_minor - # export boost_lib_version_req_sub_minor - - # echo "In ax boost base macro: boost_lib_version_req_major = $boost_lib_version_req_major" - # echo "In ax boost base macro: boost_lib_version_req_minor = $boost_lib_version_req_minor" - # echo "In ax boost base macro: boost_lib_version_req_sub_minor = $boost_lib_version_req_sub_minor" - - dnl first we check the system location for boost libraries - dnl this location ist chosen if boost libraries are installed with the --layout=system option - dnl or if you install boost with RPM - if test "$ac_boost_path" != ""; then - BOOST_LDFLAGS=" -L$ac_boost_path/lib" - BOOST_CPPFLAGS="-I$ac_boost_path/include" - ROSE_BOOST_INCLUDE_PATH="$ac_boost_path/include" - else - for ac_boost_path_tmp in /usr /usr/local /opt /opt/local ; do - if test -d "$ac_boost_path_tmp/include/boost" && test -r "$ac_boost_path_tmp/include/boost"; then - BOOST_LDFLAGS="-L$ac_boost_path_tmp/lib" - BOOST_CPPFLAGS="-I$ac_boost_path_tmp/include" - ROSE_BOOST_INCLUDE_PATH="$ac_boost_path_tmp/include" - break; - fi - done - fi - -# echo "WANT_BOOST_VERSION = $WANT_BOOST_VERSION" -# echo "boost_lib_version_req = $boost_lib_version_req" -# echo "BOOST_LDFLAGS = $BOOST_LDFLAGS" -# echo "BOOST_CPPFLAGS = $BOOST_CPPFLAGS" - -# DQ (1/1/2009): Set the default value based on BOOST_CPPFLAGS -# Liao (1/12/2009): ac_boost_path_tmp is one of the if's branches. -# Moved the assignment into the two branches above -# ROSE_BOOST_INCLUDE_PATH="$ac_boost_path_tmp/include" - - # DQ (1/1/2009): Added testing for previously installed Boost (always older version) - # so that we can trigger the use of "-isystem" option (to g++) only when required - # (it appears to be a problem for SWIG). - # Use this set of paths, and the set including "/home/dquinlan" for testing this macro. - # for ac_boost_path_tmp in /usr /usr/local /opt /opt/local /home/dquinlan; do - for ac_boost_path_tmp in /usr /usr/local /opt /opt/local ; do - if test "x${ac_boost_path_tmp}/include" != "x${ROSE_BOOST_INCLUDE_PATH}" && test -d "$ac_boost_path_tmp/include/boost" && test -r "$ac_boost_path_tmp/include/boost"; then - PREVIOUSLY_INSTALLED_BOOST="$ac_boost_path_tmp/include/boost" - AC_MSG_WARN([detected a previously installed version of boost library: "$PREVIOUSLY_INSTALLED_BOOST"]) - break; - fi - done - - dnl overwrite ld flags if we have required special directory with - dnl --with-boost-libdir parameter - if test "$ac_boost_lib_path" != ""; then - BOOST_LDFLAGS="-L$ac_boost_lib_path" - fi - - CPPFLAGS_SAVED="$CPPFLAGS" - CPPFLAGS="$CPPFLAGS $BOOST_CPPFLAGS" - export CPPFLAGS - - LDFLAGS_SAVED="$LDFLAGS" - LDFLAGS="$LDFLAGS $BOOST_LDFLAGS" - export LDFLAGS - - AC_LANG_PUSH(C++) - AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[ - @%:@include - ]], [[ - #if BOOST_VERSION >= $WANT_BOOST_VERSION - // Everything is okay - #else - # error Boost version is too old - #endif - ]])],[ - AC_MSG_RESULT(yes) - succeeded=yes - found_system=yes - ],[ - ]) - AC_LANG_POP([C++]) - - dnl if we found no boost with system layout we search for boost libraries - dnl built and installed without the --layout=system option or for a staged(not installed) version - if test "x$succeeded" != "xyes"; then - _version=0 - if test "$ac_boost_path" != ""; then - if test -d "$ac_boost_path" && test -r "$ac_boost_path"; then - for i in `ls -d $ac_boost_path/include/boost-* 2>/dev/null`; do - _version_tmp=`echo $i | sed "s#$ac_boost_path##" | sed 's/\/include\/boost-//' | sed 's/_/./'` - V_CHECK=`expr $_version_tmp \> $_version` - if test "$V_CHECK" = "1" ; then - _version=$_version_tmp - fi - VERSION_UNDERSCORE=`echo $_version | sed 's/\./_/'` - BOOST_CPPFLAGS="-I$ac_boost_path/include/boost-$VERSION_UNDERSCORE" - # DQ (12/22/2008): Modified macro to save the boost path so that it could be used with "-isystem" option (gcc). - ROSE_BOOST_INCLUDE_PATH="$ac_boost_path/include/boost-$VERSION_UNDERSCORE" - done - fi - else - for ac_boost_path in /usr /usr/local /opt /opt/local ; do - if test -d "$ac_boost_path" && test -r "$ac_boost_path"; then - for i in `ls -d $ac_boost_path/include/boost-* 2>/dev/null`; do - _version_tmp=`echo $i | sed "s#$ac_boost_path##" | sed 's/\/include\/boost-//' | sed 's/_/./'` - V_CHECK=`expr $_version_tmp \> $_version` - if test "$V_CHECK" = "1" ; then - _version=$_version_tmp - best_path=$ac_boost_path - fi - done - fi - done - - VERSION_UNDERSCORE=`echo $_version | sed 's/\./_/'` - BOOST_CPPFLAGS="-I$best_path/include/boost-$VERSION_UNDERSCORE" - if test "$ac_boost_lib_path" = "" - then - BOOST_LDFLAGS="-L$best_path/lib" - fi - - if test "x$BOOST_ROOT" != "x"; then - if test -d "$BOOST_ROOT" && test -r "$BOOST_ROOT" && test -d "$BOOST_ROOT/stage/lib" && test -r "$BOOST_ROOT/stage/lib"; then - version_dir=`expr //$BOOST_ROOT : '.*/\(.*\)'` - stage_version=`echo $version_dir | sed 's/boost_//' | sed 's/_/./g'` - stage_version_shorten=`expr $stage_version : '\([[0-9]]*\.[[0-9]]*\)'` - V_CHECK=`expr $stage_version_shorten \>\= $_version` - if test "$V_CHECK" = "1" -a "$ac_boost_lib_path" = "" ; then - AC_MSG_NOTICE([will use a staged boost library from $BOOST_ROOT]) - BOOST_CPPFLAGS="-I$BOOST_ROOT" - BOOST_LDFLAGS="-L$BOOST_ROOT/stage/lib" - fi - fi - fi - fi - - # DQ (12/22/2008): Fixup Boost to not use the system (OS) installation of Boost - # BOOST_CPPFLAGS="$BOOST_CPPFLAGS/boost" - - CPPFLAGS="$CPPFLAGS $BOOST_CPPFLAGS" - export CPPFLAGS - LDFLAGS="$LDFLAGS $BOOST_LDFLAGS" - export LDFLAGS - - AC_LANG_PUSH(C++) - AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[ - @%:@include - ]], [[ - #if BOOST_VERSION >= $WANT_BOOST_VERSION - // Everything is okay - #else - # error Boost version is too old - #endif - ]])],[ - AC_MSG_RESULT(yes) - succeeded=yes - found_system=yes - ],[ - ]) - AC_LANG_POP([C++]) - fi - - # DQ (2/4/2010): Added to get version information for what we are using. - AC_MSG_NOTICE([in boost base macro -- Boost version being used is: "$_version"]) - # rose_boost_version_number=$_version - # export rose_boost_version_number - - if test "$succeeded" != "yes" ; then - if test "$_version" = "0" ; then - # This was always a confusing error message so make it more explicit for users. - # AC_MSG_ERROR([[We could not detect the boost libraries (version $boost_lib_version_req_shorten or higher). If you have a staged boost library (still not installed) please specify \$BOOST_ROOT in your environment and do not give a PATH to --with-boost option. If you are sure you have boost installed, then check your version number looking in . See http://randspringer.de/boost for more documentation.]]) - AC_MSG_ERROR([Boost libraries (version $boost_lib_version_req_shorten or higher) must be specified on the configure line (using the --with-boost switch) and the boost libraries must be in your LD_LIBRARY_PATH]) - else - AC_MSG_FAILURE([your boost libraries seems to old (version $_version)]) - fi - else - AC_SUBST(BOOST_CPPFLAGS) - AC_SUBST(BOOST_LDFLAGS) - AC_DEFINE(HAVE_BOOST,,[define if the Boost library is available]) - fi - - CPPFLAGS="$CPPFLAGS_SAVED" - LDFLAGS="$LDFLAGS_SAVED" -fi - -# DQ (12/22/2008): Modified macro to save the boost path so that it could be used with "-isystem" -# option to include the boost path specified on the configure command ahead of "/usr/local/include" -# so that we can get the required version of Boost on systems that have it installed by default. -# echo "Final Test: ROSE_BOOST_INCLUDE_PATH = $ROSE_BOOST_INCLUDE_PATH" -# AC_SUBST(ROSE_BOOST_INCLUDE_PATH) - -# DQ (1/1/2009): This use of "-isystem" is not triggered only when there is -# a previously installed version of ROSE detected (e.g. in /usr/liclude/boost). -# Note that use of "-isystem" option with g++ will cause SWIG to fail. -if test "$PREVIOUSLY_INSTALLED_BOOST" != ""; then - # echo "Using the -isystem option of g++ to force the use of the specified version of Boost ahead of a previously installed version of boost on your system at: $PREVIOUSLY_INSTALLED_BOOST" - AC_MSG_NOTICE(using the -isystem option of g++ to force the use of the specified version of Boost ahead of a previously installed version of boost on your system at: $PREVIOUSLY_INSTALLED_BOOST) - AC_MSG_WARN([--with-javaport cannot be used with the -isystem option]) - ROSE_BOOST_PREINCLUDE_PATH="-isystem $ROSE_BOOST_INCLUDE_PATH" - ROSE_BOOST_NORMAL_INCLUDE_PATH="" - AC_MSG_WARN([detected previously installed version of boost (please remove older version of Boost before installing ROSE); continuing but expect Boost to be a problem]) - # AC_MSG_ERROR([[Detected previously installed version of boost (please remove older version of Boost before installing ROSE) (continuing but expect Boost to be a problem...)]]) - # Remove this exit (as a test) after detecting what I expect is a problem... - # exit 1 -else - AC_MSG_NOTICE(no previously installed version of boost detected: using boost include directories with normal -I option) - ROSE_BOOST_PREINCLUDE_PATH="" - ROSE_BOOST_NORMAL_INCLUDE_PATH="-I$ROSE_BOOST_INCLUDE_PATH" -fi - -AC_SUBST(ROSE_BOOST_PREINCLUDE_PATH) -AC_SUBST(ROSE_BOOST_NORMAL_INCLUDE_PATH) - - -]) diff --git a/config/ax_boost_chrono.m4 b/config/ax_boost_chrono.m4 deleted file mode 100644 index 619b4e8b29e..00000000000 --- a/config/ax_boost_chrono.m4 +++ /dev/null @@ -1,123 +0,0 @@ -# =========================================================================== -# https://www.gnu.org/software/autoconf-archive/ax_boost_chrono.html -# =========================================================================== -# -# SYNOPSIS -# -# AX_BOOST_CHRONO -# -# DESCRIPTION -# -# Test for Chrono library from the Boost C++ libraries. The macro requires -# a preceding call to AX_BOOST_BASE. Further documentation is available at -# . -# -# This macro calls: -# -# AC_SUBST(BOOST_CHRONO_LIB) -# -# And sets: -# -# HAVE_BOOST_CHRONO -# -# LICENSE -# -# Copyright (c) 2012 Xiyue Deng -# -# 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 3 - -AC_DEFUN([AX_BOOST_CHRONO], -[ - AC_ARG_WITH([boost-chrono], - AS_HELP_STRING([--with-boost-chrono@<:@=special-lib@:>@], - [use the Chrono library from boost - it is possible to specify a certain library for the linker - e.g. --with-boost-chrono=boost_chrono-gcc-mt ]), - [ - if test "$withval" = "no"; then - want_boost="no" - elif test "$withval" = "yes"; then - want_boost="yes" - ax_boost_user_chrono_lib="" - else - want_boost="yes" - ax_boost_user_chrono_lib="$withval" - fi - ], - [want_boost="yes"] - ) - - if test "x$want_boost" = "xyes"; then - AC_REQUIRE([AC_PROG_CC]) - AC_REQUIRE([AC_CANONICAL_BUILD]) - CPPFLAGS_SAVED="$CPPFLAGS" - CPPFLAGS="$CPPFLAGS $BOOST_CPPFLAGS" - export CPPFLAGS - - LDFLAGS_SAVED="$LDFLAGS" - LDFLAGS="$LDFLAGS $BOOST_LDFLAGS" - export LDFLAGS - - LIBS_SAVED="$LIBS" - LIBS="$LIBS $BOOST_SYSTEM_LIB $BOOST_THREAD_LIB" - export LIBS - - AC_CACHE_CHECK(whether the Boost::Chrono library is available, - ax_cv_boost_chrono, - [AC_LANG_PUSH([C++]) - CXXFLAGS_SAVE=$CXXFLAGS - - AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[@%:@include ]], - [[boost::chrono::system_clock::time_point time;]])], - ax_cv_boost_chrono=yes, ax_cv_boost_chrono=no) - CXXFLAGS=$CXXFLAGS_SAVE - AC_LANG_POP([C++]) - ]) - if test "x$ax_cv_boost_chrono" = "xyes"; then - AC_SUBST(BOOST_CPPFLAGS) - - AC_DEFINE(HAVE_BOOST_CHRONO,,[define if the Boost::Chrono library is available]) - BOOSTLIBDIR=`echo $BOOST_LDFLAGS | sed -e 's/@<:@^\/@:>@*//'` - - LDFLAGS_SAVE=$LDFLAGS - if test "x$ax_boost_user_chrono_lib" = "x"; then - for libextension in `ls $BOOSTLIBDIR/libboost_chrono*.so* $BOOSTLIBDIR/libboost_chrono*.dylib* $BOOSTLIBDIR/libboost_chrono*.a* 2>/dev/null | sed 's,.*/,,' | sed -e 's;^lib\(boost_chrono.*\)\.so.*$;\1;' -e 's;^lib\(boost_chrono.*\)\.dylib.*$;\1;' -e 's;^lib\(boost_chrono.*\)\.a.*$;\1;'` ; do - ax_lib=${libextension} - AC_CHECK_LIB($ax_lib, exit, - [BOOST_CHRONO_LIB="-l$ax_lib"; AC_SUBST(BOOST_CHRONO_LIB) link_chrono="yes"; break], - [link_chrono="no"]) - done - if test "x$link_chrono" != "xyes"; then - for libextension in `ls $BOOSTLIBDIR/boost_chrono*.dll* $BOOSTLIBDIR/boost_chrono*.a* 2>/dev/null | sed 's,.*/,,' | sed -e 's;^\(boost_chrono.*\)\.dll.*$;\1;' -e 's;^\(boost_chrono.*\)\.a.*$;\1;'` ; do - ax_lib=${libextension} - AC_CHECK_LIB($ax_lib, exit, - [BOOST_CHRONO_LIB="-l$ax_lib"; AC_SUBST(BOOST_CHRONO_LIB) link_chrono="yes"; break], - [link_chrono="no"]) - done - fi - - else - for ax_lib in $ax_boost_user_chrono_lib boost_chrono-$ax_boost_user_chrono_lib; do - AC_CHECK_LIB($ax_lib, exit, - [BOOST_CHRONO_LIB="-l$ax_lib"; AC_SUBST(BOOST_CHRONO_LIB) link_chrono="yes"; break], - [link_chrono="no"]) - done - - fi - if test "x$ax_lib" = "x"; then - AC_MSG_ERROR([could not find a version of the library]) - fi - if test "x$link_chrono" = "xno"; then - AC_MSG_ERROR([could not link against "$ax_lib"]) - fi - fi - - CPPFLAGS="$CPPFLAGS_SAVED" - LDFLAGS="$LDFLAGS_SAVED" - LIBS="$LIBS_SAVED" - fi -]) diff --git a/config/ax_boost_date_time.m4 b/config/ax_boost_date_time.m4 deleted file mode 100644 index d93840f73ee..00000000000 --- a/config/ax_boost_date_time.m4 +++ /dev/null @@ -1,105 +0,0 @@ -##### http://autoconf-archive.cryp.to/ax_boost_date_time.html -# -# SYNOPSIS -# -# AX_BOOST_DATE_TIME -# -# DESCRIPTION -# -# Test for Date_Time library from the Boost C++ libraries. The macro -# requires a preceding call to AX_BOOST_BASE. Further documentation -# is available at . -# -# This macro calls: -# -# AC_SUBST(BOOST_DATE_TIME_LIB) -# -# And sets: -# -# HAVE_BOOST_DATE_TIME -# -# COPYLEFT -# -# Copyright (c) 2007 Thomas Porschberg -# Copyright (c) 2007 Michael Tindal -# -# 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. - -AC_DEFUN([AX_BOOST_DATE_TIME], -[ - AC_ARG_WITH([boost-date-time], - AS_HELP_STRING([--with-boost-date-time@<:@=special-lib@:>@], - [use the Date_Time library from boost - it is possible to specify a certain library for the linker - e.g. --with-boost-date-time=boost_date_time-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_date_time_lib="" - else - want_boost="yes" - ax_boost_user_date_time_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" - export CPPFLAGS - - LDFLAGS_SAVED="$LDFLAGS" - LDFLAGS="$LDFLAGS $BOOST_LDFLAGS" - export LDFLAGS - - AC_CACHE_CHECK(whether the Boost::Date_Time library is available, - ax_cv_boost_date_time, - [AC_LANG_PUSH([C++]) - AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[@%:@include ]], - [[using namespace boost::gregorian; date d(2002,Jan,10); - return 0; - ]])], - ax_cv_boost_date_time=yes, ax_cv_boost_date_time=no) - AC_LANG_POP([C++]) - ]) - if test "x$ax_cv_boost_date_time" = "xyes"; then - AC_DEFINE(HAVE_BOOST_DATE_TIME,,[define if the Boost::Date_Time library is available]) - BOOSTLIBDIR=`echo $BOOST_LDFLAGS | sed -e 's/@<:@^\/@:>@*//'` - if test "x$ax_boost_user_date_time_lib" = "x"; then - for libextension in `ls $BOOSTLIBDIR/libboost_date_time*.{so,dylib,a}* 2>/dev/null | sed 's,.*/,,' | sed -e 's;^lib\(boost_date_time.*\)\.so.*$;\1;' -e 's;^lib\(boost_date_time.*\)\.a*$;\1;' -e 's;^lib\(boost_date_time.*\)\.dylib$;\1;'` ; do - ax_lib=${libextension} - AC_CHECK_LIB($ax_lib, toupper, - [BOOST_DATE_TIME_LIB="-l$ax_lib"; AC_SUBST(BOOST_DATE_TIME_LIB) link_date_time="yes"; break], - [link_date_time="no"]) - done - if test "x$link_date_time" != "xyes"; then - for libextension in `ls $BOOSTLIBDIR/boost_date_time*.{dll,a}* 2>/dev/null | sed 's,.*/,,' | sed -e 's;^\(boost_date_time.*\)\.dll.*$;\1;' -e 's;^\(boost_date_time.*\)\.a*$;\1;'` ; do - ax_lib=${libextension} - AC_CHECK_LIB($ax_lib, toupper, - [BOOST_DATE_TIME_LIB="-l$ax_lib"; AC_SUBST(BOOST_DATE_TIME_LIB) link_date_time="yes"; break], - [link_date_time="no"]) - done - fi - - else - for ax_lib in $ax_boost_user_date_time_lib boost_date_time-$ax_boost_user_date_time_lib; do - AC_CHECK_LIB($ax_lib, main, - [BOOST_DATE_TIME_LIB="-l$ax_lib"; AC_SUBST(BOOST_DATE_TIME_LIB) link_date_time="yes"; break], - [link_date_time="no"]) - done - - fi - if test "x$link_date_time" != "xyes"; then - AC_MSG_ERROR([could not link against "$ax_lib"]) - fi - fi - - CPPFLAGS="$CPPFLAGS_SAVED" - LDFLAGS="$LDFLAGS_SAVED" - fi -]) diff --git a/config/ax_boost_filesystem.m4 b/config/ax_boost_filesystem.m4 deleted file mode 100644 index 876db4b75e4..00000000000 --- a/config/ax_boost_filesystem.m4 +++ /dev/null @@ -1,112 +0,0 @@ -# =========================================================================== -# http://autoconf-archive.cryp.to/ax_boost_filesystem.html -# =========================================================================== -# -# SYNOPSIS -# -# AX_BOOST_FILESYSTEM -# -# DESCRIPTION -# -# Test for Filesystem library from the Boost C++ libraries. The macro -# requires a preceding call to AX_BOOST_BASE. Further documentation is -# available at . -# -# This macro calls: -# -# AC_SUBST(BOOST_FILESYSTEM_LIB) -# -# And sets: -# -# HAVE_BOOST_FILESYSTEM -# -# COPYLEFT -# -# Copyright (c) 2008 Thomas Porschberg -# Copyright (c) 2008 Michael Tindal -# Copyright (c) 2008 Roman Rybalko (using BOOST_SYSTEM_LIB) -# -# 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. - -AC_DEFUN([AX_BOOST_FILESYSTEM], -[ - AC_ARG_WITH([boost-filesystem], - AS_HELP_STRING([--with-boost-filesystem@<:@=special-lib@:>@], - [use the Filesystem library from boost - it is possible to specify a certain library for the linker - e.g. --with-boost-filesystem=boost_filesystem-gcc-mt ]), - [ - if test "$withval" = "no"; then - want_boost="no" - elif test "$withval" = "yes"; then - want_boost="yes" - ax_boost_user_filesystem_lib="" - else - want_boost="yes" - ax_boost_user_filesystem_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" - export CPPFLAGS - - LDFLAGS_SAVED="$LDFLAGS" - LDFLAGS="$LDFLAGS $BOOST_LDFLAGS" - export LDFLAGS - - LIBS_SAVED=$LIBS - LIBS="$LIBS $BOOST_SYSTEM_LIB" - export LIBS - - AC_CACHE_CHECK(whether the Boost::Filesystem library is available, - ax_cv_boost_filesystem, - [AC_LANG_PUSH([C++]) - AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[@%:@include ]], - [[using namespace boost::filesystem; - path my_path( "foo/bar/data.txt" ); - return 0;]])], - ax_cv_boost_filesystem=yes, ax_cv_boost_filesystem=no) - AC_LANG_POP([C++]) - ]) - if test "x$ax_cv_boost_filesystem" = "xyes"; then - AC_DEFINE(HAVE_BOOST_FILESYSTEM,,[define if the Boost::Filesystem library is available]) - BOOSTLIBDIR=`echo $BOOST_LDFLAGS | sed -e 's/@<:@^\/@:>@*//'` - if test "x$ax_boost_user_filesystem_lib" = "x"; then - for libextension in `ls $BOOSTLIBDIR/libboost_filesystem*.{so,dylib,a}* 2>/dev/null | sed 's,.*/,,' | sed -e 's;^lib\(boost_filesystem.*\)\.so.*$;\1;' -e 's;^lib\(boost_filesystem.*\)\.a*$;\1;' -e 's;^lib\(boost_filesystem.*\)\.dylib$;\1;'` ; do - ax_lib=${libextension} - AC_CHECK_LIB($ax_lib, toupper, - [BOOST_FILESYSTEM_LIB="-l$ax_lib"; AC_SUBST(BOOST_FILESYSTEM_LIB) link_filesystem="yes"; break], - [link_filesystem="no"]) - done - if test "x$link_program_options" != "xyes"; then - for libextension in `ls $BOOSTLIBDIR/boost_filesystem*.{dll,a}* 2>/dev/null | sed 's,.*/,,' | sed -e 's;^\(boost_filesystem.*\)\.dll.*$;\1;' -e 's;^\(boost_filesystem.*\)\.a*$;\1;'` ; do - ax_lib=${libextension} - AC_CHECK_LIB($ax_lib, toupper, - [BOOST_FILESYSTEM_LIB="-l$ax_lib"; AC_SUBST(BOOST_FILESYSTEM_LIB) link_filesystem="yes"; break], - [link_filesystem="no"]) - done - fi - else - for ax_lib in $ax_boost_user_filesystem_lib boost_filesystem-$ax_boost_user_filesystem_lib; do - AC_CHECK_LIB($ax_lib, toupper, - [BOOST_FILESYSTEM_LIB="-l$ax_lib"; AC_SUBST(BOOST_FILESYSTEM_LIB) link_filesystem="yes"; break], - [link_filesystem="no"]) - done - - fi - if test "x$link_filesystem" != "xyes"; then - AC_MSG_ERROR([could not link against "$ax_lib"]) - fi - fi - - CPPFLAGS="$CPPFLAGS_SAVED" - LDFLAGS="$LDFLAGS_SAVED" - LIBS="$LIBS_SAVED" - fi -]) diff --git a/config/ax_boost_iostreams.m4 b/config/ax_boost_iostreams.m4 deleted file mode 100644 index 9cfe0904694..00000000000 --- a/config/ax_boost_iostreams.m4 +++ /dev/null @@ -1,122 +0,0 @@ -##### http://autoconf-archive.cryp.to/ax_boost_iostreams.html -# -# SYNOPSIS -# -# AX_BOOST_IOSTREAMS -# -# DESCRIPTION -# -# Test for IOStreams library from the Boost C++ libraries. The macro -# requires a preceding call to AX_BOOST_BASE. Further documentation -# is available at . -# -# This macro calls: -# -# AC_SUBST(BOOST_IOSTREAMS_LIB) -# -# And sets: -# -# HAVE_BOOST_IOSTREAMS -# -# COPYLEFT -# -# Copyright (c) 2007 Thomas Porschberg -# -# 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. -# -# MODIFIED -# Robb Matzke, 2015-01: fixed indentation -# Robb Matzke, 2015-01: fixed message about "library not found" when it's the headers that aren't found -# Robb Matzke, 2015-01: it is not an error for the iostreams library to be missing when headers are present -# Robb Matzke, 2015-01: replaced test .C file with mapped_file_params since that's what ROSE needs from iostreams - -AC_DEFUN([AX_BOOST_IOSTREAMS], -[ - AC_ARG_WITH([boost-iostreams], - AS_HELP_STRING([--with-boost-iostreams@<:@=special-lib@:>@], - [use the IOStreams library from boost - it is possible to specify a certain library for the linker - e.g. --with-boost-iostreams=boost_iostreams-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_iostreams_lib="" - else - want_boost="yes" - ax_boost_user_iostreams_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" - export CPPFLAGS - - LDFLAGS_SAVED="$LDFLAGS" - LDFLAGS="$LDFLAGS $BOOST_LDFLAGS" - export LDFLAGS - - AC_CACHE_CHECK([whether the boost::iostreams headers are available], - ax_cv_boost_iostreams, - [ - AC_LANG_PUSH([C++]) - AC_COMPILE_IFELSE( - [AC_LANG_PROGRAM( - [[ - @%:@include - ]], - [[ - boost::iostreams::mapped_file_params params; - boost::iostreams::mapped_file f(params); - f.const_data(); - return 0; - ]])], - ax_cv_boost_iostreams=yes, - ax_cv_boost_iostreams=no) - AC_LANG_POP([C++]) - ]) - - - if test "x$ax_cv_boost_iostreams" = "xyes"; then - AC_DEFINE(HAVE_BOOST_IOSTREAMS,,[define if the Boost::IOStreams library is available]) - BOOSTLIBDIR=`echo $BOOST_LDFLAGS | sed -e 's/@<:@^\/@:>@*//'` - if test "x$ax_boost_user_iostreams_lib" = "x"; then - for libextension in `ls $BOOSTLIBDIR/libboost_iostreams*.{so,dylib,a}* 2>/dev/null | sed 's,.*/,,' | sed -e 's;^lib\(boost_iostreams.*\)\.so.*$;\1;' -e 's;^lib\(boost_iostreams.*\)\.a*$;\1;' -e 's;^lib\(boost_iostreams.*\)\.dylib$;\1;'` ; do - ax_lib=${libextension} - AC_CHECK_LIB($ax_lib, toupper, - [BOOST_IOSTREAMS_LIB="-l$ax_lib"; AC_SUBST(BOOST_IOSTREAMS_LIB) link_iostreams="yes"; break], - [link_iostreams="no"]) - done - - if test "x$link_iostreams" != "xyes"; then - for libextension in `ls $BOOSTLIBDIR/boost_iostreams*.{dll,a}* 2>/dev/null | sed 's,.*/,,' | sed -e 's;^\(boost_iostreams.*\)\.dll.*$;\1;' -e 's;^\(boost_iostreams.*\)\.a*$;\1;'` ; do - ax_lib=${libextension} - AC_CHECK_LIB($ax_lib, toupper, - [BOOST_IOSTREAMS_LIB="-l$ax_lib"; AC_SUBST(BOOST_IOSTREAMS_LIB) link_iostreams="yes"; break], - [link_iostreams="no"]) - done - fi - else - for ax_lib in $ax_boost_user_iostreams_lib boost_iostreams-$ax_boost_user_iostreams_lib; do - AC_CHECK_LIB($ax_lib, main, - [BOOST_IOSTREAMS_LIB="-l$ax_lib"; AC_SUBST(BOOST_IOSTREAMS_LIB) link_iostreams="yes"; break], - [link_iostreams="no"]) - done - fi - - dnl Failing to link against libiostreams should not be an error here; perhaps at a higher level it is. - if test "x$link_iostreams" != "xyes"; then - AC_MSG_NOTICE([boost::iostreams headers are available, but not the library]) - fi - fi - - CPPFLAGS="$CPPFLAGS_SAVED" - LDFLAGS="$LDFLAGS_SAVED" - fi -]) diff --git a/config/ax_boost_program_options.m4 b/config/ax_boost_program_options.m4 deleted file mode 100644 index 8143e57ece7..00000000000 --- a/config/ax_boost_program_options.m4 +++ /dev/null @@ -1,101 +0,0 @@ -##### http://autoconf-archive.cryp.to/ax_boost_program_options.html -# -# SYNOPSIS -# -# AX_BOOST_PROGRAM_OPTIONS -# -# DESCRIPTION -# -# Test for program options library from the Boost C++ libraries. The -# macro requires a preceding call to AX_BOOST_BASE. Further -# documentation is available at -# . -# -# This macro calls: -# -# AC_SUBST(BOOST_PROGRAM_OPTIONS_LIB) -# -# And sets: -# -# HAVE_BOOST_PROGRAM_OPTIONS -# -# COPYLEFT -# -# Copyright (c) 2007 Thomas Porschberg -# -# 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. - -AC_DEFUN([AX_BOOST_PROGRAM_OPTIONS], -[ - AC_ARG_WITH([boost-program-options], - AS_HELP_STRING([--with-boost-program-options@<:@=special-lib@:>@], - [use the program options library from boost - it is possible to specify a certain library for the linker - e.g. --with-boost-program-options=boost_program_options-gcc-mt-1_33_1 ]), - [ - if test "$withval" = "no"; then - want_boost="no" - elif test "$withval" = "yes"; then - want_boost="yes" - ax_boost_user_program_options_lib="" - else - want_boost="yes" - ax_boost_user_program_options_lib="$withval" - fi - ], - [want_boost="yes"] - ) - - if test "x$want_boost" = "xyes"; then - AC_REQUIRE([AC_PROG_CC]) - export want_boost - CPPFLAGS_SAVED="$CPPFLAGS" - CPPFLAGS="$CPPFLAGS $BOOST_CPPFLAGS" - export CPPFLAGS - LDFLAGS_SAVED="$LDFLAGS" - LDFLAGS="$LDFLAGS $BOOST_LDFLAGS" - export LDFLAGS - AC_CACHE_CHECK([whether the Boost::Program_Options library is available], - ax_cv_boost_program_options, - [AC_LANG_PUSH(C++) - AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[@%:@include - ]], - [[boost::program_options::options_description generic("Generic options"); - return 0;]])], - ax_cv_boost_program_options=yes, ax_cv_boost_program_options=no) - AC_LANG_POP([C++]) - ]) - if test "$ax_cv_boost_program_options" = yes; then - AC_DEFINE(HAVE_BOOST_PROGRAM_OPTIONS,,[define if the Boost::PROGRAM_OPTIONS library is available]) - BOOSTLIBDIR=`echo $BOOST_LDFLAGS | sed -e 's/@<:@^\/@:>@*//'` - if test "x$ax_boost_user_program_options_lib" = "x"; then - for libextension in `ls $BOOSTLIBDIR/libboost_program_options*.{so,dylib,a}* 2>/dev/null | sed 's,.*/,,' | sed -e 's;^lib\(boost_program_options.*\)\.so.*$;\1;' -e 's;^lib\(boost_program_options.*\)\.a*$;\1;' -e 's;^lib\(boost_program_options.*\)\.dylib$;\1;'` ; do - ax_lib=${libextension} - AC_CHECK_LIB($ax_lib, toupper, - [BOOST_PROGRAM_OPTIONS_LIB="-l$ax_lib"; AC_SUBST(BOOST_PROGRAM_OPTIONS_LIB) link_program_options="yes"; break], - [link_program_options="no"]) - done - if test "x$link_program_options" != "xyes"; then - for libextension in `ls $BOOSTLIBDIR/boost_program_options*.{dll,a}* 2>/dev/null | sed 's,.*/,,' | sed -e 's;^\(boost_program_options.*\)\.dll.*$;\1;' -e 's;^\(boost_program_options.*\)\.a*$;\1;'` ; do - ax_lib=${libextension} - AC_CHECK_LIB($ax_lib, toupper, - [BOOST_PROGRAM_OPTIONS_LIB="-l$ax_lib"; AC_SUBST(BOOST_PROGRAM_OPTIONS_LIB) link_program_options="yes"; break], - [link_program_options="no"]) - done - fi - else - for ax_lib in $ax_boost_user_program_options_lib boost_program_options-$ax_boost_user_program_options_lib; do - AC_CHECK_LIB($ax_lib, main, - [BOOST_PROGRAM_OPTIONS_LIB="-l$ax_lib"; AC_SUBST(BOOST_PROGRAM_OPTIONS_LIB) link_program_options="yes"; break], - [link_program_options="no"]) - done - fi - if test "x$link_program_options" != "xyes"; then - AC_MSG_ERROR([could not link against "$ax_lib"]) - fi - fi - CPPFLAGS="$CPPFLAGS_SAVED" - LDFLAGS="$LDFLAGS_SAVED" - fi -]) diff --git a/config/ax_boost_python.m4 b/config/ax_boost_python.m4 deleted file mode 100644 index c2d56e65b1d..00000000000 --- a/config/ax_boost_python.m4 +++ /dev/null @@ -1,127 +0,0 @@ -# Copied and modified from ax_boost_chrono with ROSE-specific changes. -# -# SYNOPSIS -# -# AX_BOOST_PYTHON -# -# DESCRIPTION -# -# Test for Python library from the Boost C++ libraries. The macro requires -# a preceding call to AX_BOOST_BASE. Further documentation is available at -# . -# -# This macro calls: -# -# AC_SUBST(BOOST_PYTHON_LIB) -# -# And sets: -# -# HAVE_BOOST_PYTHON -# -# LICENSE -# -# Copyright (c) 2012 Xiyue Deng -# -# 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 3 - -AC_DEFUN([AX_BOOST_PYTHON], -[ - AC_ARG_WITH([boost-python], - AS_HELP_STRING([--with-boost-python@<:@=special-lib@:>@], - [use the Python library from boost - it is possible to specify a certain library for the linker - e.g. --with-boost-python=boost_python-gcc-mt ]), - [ - if test "$withval" = "no"; then - want_boost="no" - elif test "$withval" = "yes"; then - want_boost="yes" - ax_boost_user_python_lib="" - else - want_boost="yes" - ax_boost_user_python_lib="$withval" - fi - ], - [want_boost="yes"]) - - if test "x$want_boost" = "xyes"; then - AC_REQUIRE([AC_PROG_CC]) - AC_REQUIRE([AC_CANONICAL_BUILD]) - CPPFLAGS_SAVED="$CPPFLAGS" - CPPFLAGS="$CPPFLAGS $BOOST_CPPFLAGS" - export CPPFLAGS - - LDFLAGS_SAVED="$LDFLAGS" - LDFLAGS="$LDFLAGS $BOOST_LDFLAGS" - export LDFLAGS - - LIBS_SAVED="$LIBS" - LIBS="$LIBS $BOOST_SYSTEM_LIB $BOOST_THREAD_LIB" - export LIBS - - AC_CACHE_CHECK([whether the Boost::Python library is available], ax_cv_boost_python, - [ - AC_LANG_PUSH([C++]) - CXXFLAGS_SAVE=$CXXFLAGS - - AC_COMPILE_IFELSE( - [AC_LANG_PROGRAM([[@%:@include ]], [[int dummy;]])], - ax_cv_boost_python=yes, - ax_cv_boost_python=no) - CXXFLAGS=$CXXFLAGS_SAVE - AC_LANG_POP([C++]) - ]) - - if test "x$ax_cv_boost_python" = "xyes"; then - AC_SUBST(BOOST_CPPFLAGS) - - AC_DEFINE(HAVE_BOOST_PYTHON,,[define if the Boost::Python library is available]) - BOOSTLIBDIR=`echo $BOOST_LDFLAGS | sed -e 's/@<:@^\/@:>@*//'` - - LDFLAGS_SAVE=$LDFLAGS - if test "x$ax_boost_user_python_lib" = "x"; then - for libextension in `ls $BOOSTLIBDIR/libboost_python*.so* $BOOSTLIBDIR/libboost_python*.dylib* $BOOSTLIBDIR/libboost_python*.a* 2>/dev/null |\ - sed 's,.*/,,' |\ - sed -e 's;^lib\(boost_python.*\)\.so.*$;\1;' -e 's;^lib\(boost_python.*\)\.dylib.*$;\1;' -e 's;^lib\(boost_python.*\)\.a.*$;\1;'` ; do - ax_lib=${libextension} - AC_CHECK_LIB($ax_lib, exit, - [BOOST_PYTHON_LIB="-l$ax_lib"; AC_SUBST(BOOST_PYTHON_LIB) link_python="yes"; break], - [link_python="no"]) - done - - if test "x$link_python" != "xyes"; then - for libextension in `ls $BOOSTLIBDIR/boost_python*.dll* $BOOSTLIBDIR/boost_python*.a* 2>/dev/null |\ - sed 's,.*/,,' |\ - sed -e 's;^\(boost_python.*\)\.dll.*$;\1;' -e 's;^\(boost_python.*\)\.a.*$;\1;'` ; do - ax_lib=${libextension} - AC_CHECK_LIB($ax_lib, exit, - [BOOST_PYTHON_LIB="-l$ax_lib"; AC_SUBST(BOOST_PYTHON_LIB) link_python="yes"; break], - [link_python="no"]) - done - fi - else - for ax_lib in $ax_boost_user_python_lib boost_python-$ax_boost_user_python_lib; do - AC_CHECK_LIB($ax_lib, exit, - [BOOST_PYTHON_LIB="-l$ax_lib"; AC_SUBST(BOOST_PYTHON_LIB) link_python="yes"; break], - [link_python="no"]) - done - fi - - if test "x$ax_lib" = "x"; then - AC_MSG_ERROR([could not find a version of the library]) - fi - - if test "x$link_python" = "xno"; then - AC_MSG_ERROR([could not link against "$ax_lib"]) - fi - fi - - CPPFLAGS="$CPPFLAGS_SAVED" - LDFLAGS="$LDFLAGS_SAVED" - LIBS="$LIBS_SAVED" - fi -]) diff --git a/config/ax_boost_random.m4 b/config/ax_boost_random.m4 deleted file mode 100644 index a8e1a33ee32..00000000000 --- a/config/ax_boost_random.m4 +++ /dev/null @@ -1,97 +0,0 @@ -# Cut-n-pasted from boost_chrono.m4 instead of downloading from the original -# location, in order to preserve any local bug fixes already applied by the -# ROSE team to the boost_chrono detection. All instances of "chrono" were -# then replaced by "random" (preserving capitalizations) and a single occurrence -# of "boost::chrono::system_clock::time_point time" was replaced by a suitable -# type from boost::random. - -AC_DEFUN([AX_BOOST_RANDOM], -[ - AC_ARG_WITH([boost-random], - AS_HELP_STRING([--with-boost-random@<:@=special-lib@:>@], - [use the Random library from boost - it is possible to specify a certain library for the linker - e.g. --with-boost-random=boost_random-gcc-mt ]), - [ - if test "$withval" = "no"; then - want_boost="no" - elif test "$withval" = "yes"; then - want_boost="yes" - ax_boost_user_random_lib="" - else - want_boost="yes" - ax_boost_user_random_lib="$withval" - fi - ], - [want_boost="yes"] - ) - - if test "x$want_boost" = "xyes"; then - AC_REQUIRE([AC_PROG_CC]) - AC_REQUIRE([AC_CANONICAL_BUILD]) - CPPFLAGS_SAVED="$CPPFLAGS" - CPPFLAGS="$CPPFLAGS $BOOST_CPPFLAGS" - export CPPFLAGS - - LDFLAGS_SAVED="$LDFLAGS" - LDFLAGS="$LDFLAGS $BOOST_LDFLAGS" - export LDFLAGS - - LIBS_SAVED="$LIBS" - LIBS="$LIBS $BOOST_SYSTEM_LIB $BOOST_THREAD_LIB" - export LIBS - - AC_CACHE_CHECK(whether the Boost::Random library is available, - ax_cv_boost_random, - [AC_LANG_PUSH([C++]) - CXXFLAGS_SAVE=$CXXFLAGS - - AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[@%:@include ]], - [[boost::random::mt19937 rng;]])], - ax_cv_boost_random=yes, ax_cv_boost_random=no) - CXXFLAGS=$CXXFLAGS_SAVE - AC_LANG_POP([C++]) - ]) - if test "x$ax_cv_boost_random" = "xyes"; then - AC_SUBST(BOOST_CPPFLAGS) - - AC_DEFINE(HAVE_BOOST_RANDOM,,[define if the Boost::Random library is available]) - BOOSTLIBDIR=`echo $BOOST_LDFLAGS | sed -e 's/@<:@^\/@:>@*//'` - - LDFLAGS_SAVE=$LDFLAGS - if test "x$ax_boost_user_random_lib" = "x"; then - for libextension in `ls $BOOSTLIBDIR/libboost_random*.so* $BOOSTLIBDIR/libboost_random*.dylib* $BOOSTLIBDIR/libboost_random*.a* 2>/dev/null | sed 's,.*/,,' | sed -e 's;^lib\(boost_random.*\)\.so.*$;\1;' -e 's;^lib\(boost_random.*\)\.dylib.*$;\1;' -e 's;^lib\(boost_random.*\)\.a.*$;\1;'` ; do - ax_lib=${libextension} - AC_CHECK_LIB($ax_lib, exit, - [BOOST_RANDOM_LIB="-l$ax_lib"; AC_SUBST(BOOST_RANDOM_LIB) link_random="yes"; break], - [link_random="no"]) - done - if test "x$link_random" != "xyes"; then - for libextension in `ls $BOOSTLIBDIR/boost_random*.dll* $BOOSTLIBDIR/boost_random*.a* 2>/dev/null | sed 's,.*/,,' | sed -e 's;^\(boost_random.*\)\.dll.*$;\1;' -e 's;^\(boost_random.*\)\.a.*$;\1;'` ; do - ax_lib=${libextension} - AC_CHECK_LIB($ax_lib, exit, - [BOOST_RANDOM_LIB="-l$ax_lib"; AC_SUBST(BOOST_RANDOM_LIB) link_random="yes"; break], - [link_random="no"]) - done - fi - - else - for ax_lib in $ax_boost_user_random_lib boost_random-$ax_boost_user_random_lib; do - AC_CHECK_LIB($ax_lib, exit, - [BOOST_RANDOM_LIB="-l$ax_lib"; AC_SUBST(BOOST_RANDOM_LIB) link_random="yes"; break], - [link_random="no"]) - done - - fi - if test "x$ax_lib" = "x"; then - AC_MSG_ERROR([could not find a version of the library]) - fi - if test "x$link_random" = "xno"; then - AC_MSG_ERROR([could not link against "$ax_lib"]) - fi - fi - - CPPFLAGS="$CPPFLAGS_SAVED" - LDFLAGS="$LDFLAGS_SAVED" - LIBS="$LIBS_SAVED" - fi -]) diff --git a/config/ax_boost_regex.m4 b/config/ax_boost_regex.m4 deleted file mode 100644 index 9a44203cfeb..00000000000 --- a/config/ax_boost_regex.m4 +++ /dev/null @@ -1,106 +0,0 @@ -##### http://autoconf-archive.cryp.to/ax_boost_regex.html -# -# SYNOPSIS -# -# AX_BOOST_REGEX -# -# DESCRIPTION -# -# Test for Regex library from the Boost C++ libraries. The macro -# requires a preceding call to AX_BOOST_BASE. Further documentation -# is available at . -# -# This macro calls: -# -# AC_SUBST(BOOST_REGEX_LIB) -# -# And sets: -# -# HAVE_BOOST_REGEX -# -# COPYLEFT -# -# Copyright (c) 2007 Thomas Porschberg -# Copyright (c) 2007 Michael Tindal -# -# 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. - -AC_DEFUN([AX_BOOST_REGEX], -[ - AC_ARG_WITH([boost-regex], - AS_HELP_STRING([--with-boost-regex@<:@=special-lib@:>@], - [use the Regex library from boost - it is possible to specify a certain library for the linker - e.g. --with-boost-regex=boost_regex-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_regex_lib="" - else - want_boost="yes" - ax_boost_user_regex_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" - export CPPFLAGS - - LDFLAGS_SAVED="$LDFLAGS" - LDFLAGS="$LDFLAGS $BOOST_LDFLAGS" - export LDFLAGS - - AC_CACHE_CHECK(whether the Boost::Regex library is available, - ax_cv_boost_regex, - [AC_LANG_PUSH([C++]) - AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[@%:@include ]], - [[boost::regex r(); return 0;]])], - ax_cv_boost_regex=yes, ax_cv_boost_regex=no) - AC_LANG_POP([C++]) - ]) - - if test "x$ax_cv_boost_regex" = "xyes"; then - AC_DEFINE(HAVE_BOOST_REGEX,,[define if the Boost::Regex library is available]) - BOOSTLIBDIR=`echo $BOOST_LDFLAGS | sed -e 's/@<:@^\/@:>@*//'` - - if test "x$ax_boost_user_regex_lib" = "x"; then - - for libextension in `ls $BOOSTLIBDIR/libboost_regex*.{so,dylib,a}* 2>/dev/null | sed 's,.*/,,' | sed -e 's;^lib\(boost_regex.*\)\.so.*$;\1;' -e 's;^lib\(boost_regex.*\)\.a*$;\1;' -e 's;^lib\(boost_regex.*\)\.dylib$;\1;'` ; do - ax_lib=${libextension} - AC_CHECK_LIB($ax_lib, toupper, - [BOOST_REGEX_LIB="-l$ax_lib"; AC_SUBST(BOOST_REGEX_LIB) link_regex="yes"; break], - [link_regex="no"]) - done - - if test "x$link_regex" != "xyes"; then - for libextension in `ls $BOOSTLIBDIR/boost_regex*.{dll,a}* 2>/dev/null | sed 's,.*/,,' | sed -e 's;^\(boost_regex.*\)\.dll.*$;\1;' -e 's;^\(boost_regex.*\)\.a*$;\1;'` ; do - ax_lib=${libextension} - AC_CHECK_LIB($ax_lib, toupper, - [BOOST_REGEX_LIB="-l$ax_lib"; AC_SUBST(BOOST_REGEX_LIB) link_regex="yes"; break], - [link_regex="no"]) - done - fi - else - for ax_lib in $ax_boost_user_regex_lib boost_regex-$ax_boost_user_regex_lib; do - AC_CHECK_LIB($ax_lib, main, - [BOOST_REGEX_LIB="-l$ax_lib"; AC_SUBST(BOOST_REGEX_LIB) link_regex="yes"; break], - [link_regex="no"]) - done - fi - - if test "x$link_regex" != "xyes"; then - AC_MSG_ERROR([could not link against "$ax_lib"]) - fi - fi - - CPPFLAGS="$CPPFLAGS_SAVED" - LDFLAGS="$LDFLAGS_SAVED" - fi -]) diff --git a/config/ax_boost_signals.m4 b/config/ax_boost_signals.m4 deleted file mode 100644 index ef1dd4a24bd..00000000000 --- a/config/ax_boost_signals.m4 +++ /dev/null @@ -1,106 +0,0 @@ -##### http://autoconf-archive.cryp.to/ax_boost_signals.html -# -# SYNOPSIS -# -# AX_BOOST_SIGNALS -# -# DESCRIPTION -# -# Test for Signals library from the Boost C++ libraries. The macro -# requires a preceding call to AX_BOOST_BASE. Further documentation -# is available at . -# -# This macro calls: -# -# AC_SUBST(BOOST_SIGNALS_LIB) -# -# And sets: -# -# HAVE_BOOST_SIGNALS -# -# COPYLEFT -# -# Copyright (c) 2007 Thomas Porschberg -# Copyright (c) 2007 Michael Tindal -# -# 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. - -AC_DEFUN([AX_BOOST_SIGNALS], -[ - AC_ARG_WITH([boost-signals], - AS_HELP_STRING([--with-boost-signals@<:@=special-lib@:>@], - [use the Signals library from boost - it is possible to specify a certain library for the linker - e.g. --with-boost-signals=boost_signals-gcc-mt-d ]), - [ - if test "$withval" = "no"; then - want_boost="no" - elif test "$withval" = "yes"; then - want_boost="yes" - ax_boost_user_signals_lib="" - else - want_boost="yes" - ax_boost_user_signals_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" - export CPPFLAGS - - LDFLAGS_SAVED="$LDFLAGS" - LDFLAGS="$LDFLAGS $BOOST_LDFLAGS" - export LDFLAGS - - AC_CACHE_CHECK(whether the Boost::Signals library is available, - ax_cv_boost_signals, - [AC_LANG_PUSH([C++]) - AC_COMPILE_IFELSE(AC_LANG_PROGRAM([[@%:@include - ]], - [[boost::signal sig; - return 0; - ]]), - ax_cv_boost_signals=yes, ax_cv_boost_signals=no) - AC_LANG_POP([C++]) - ]) - if test "x$ax_cv_boost_signals" = "xyes"; then - AC_DEFINE(HAVE_BOOST_SIGNALS,,[define if the Boost::Signals library is available]) - BOOSTLIBDIR=`echo $BOOST_LDFLAGS | sed -e 's/@<:@^\/@:>@*//'` - if test "x$ax_boost_user_signals_lib" = "x"; then - for libextension in `ls $BOOSTLIBDIR/libboost_signals*.{so,dylib,a}* 2>/dev/null | sed 's,.*/,,' | sed -e 's;^lib\(boost_signals.*\)\.so.*$;\1;' -e 's;^lib\(boost_signals.*\)\.a*$;\1;' -e 's;^lib\(boost_signals.*\)\.dylib$;\1;'` ; do - ax_lib=${libextension} - AC_CHECK_LIB($ax_lib, toupper, - [BOOST_SIGNALS_LIB="-l$ax_lib"; AC_SUBST(BOOST_SIGNALS_LIB) link_signals="yes"; break], - [link_signals="no"]) - done - if test "x$link_signals" != "xyes"; then - for libextension in `ls $BOOSTLIBDIR/boost_signals*.{dll,a}* 2>/dev/null | sed 's,.*/,,' | sed -e 's;^\(boost_signals.*\)\.dll.*$;\1;' -e 's;^\(boost_signals.*\)\.a*$;\1;'` ; do - ax_lib=${libextension} - AC_CHECK_LIB($ax_lib, toupper, - [BOOST_SIGNALS_LIB="-l$ax_lib"; AC_SUBST(BOOST_SIGNALS_LIB) link_signals="yes"; break], - [link_signals="no"]) - done - fi - - else - for ax_lib in $ax_boost_user_signals_lib boost_signals-$ax_boost_user_signals_lib; do - AC_CHECK_LIB($ax_lib, main, - [BOOST_SIGNALS_LIB="-l$ax_lib"; AC_SUBST(BOOST_SIGNALS_LIB) link_signals="yes"; break], - [link_signals="no"]) - done - - fi - if test "x$link_signals" != "xyes"; then - AC_MSG_ERROR([could not link against "$ax_lib"]) - fi - fi - - CPPFLAGS="$CPPFLAGS_SAVED" - LDFLAGS="$LDFLAGS_SAVED" - fi -]) diff --git a/config/ax_boost_system.m4 b/config/ax_boost_system.m4 deleted file mode 100644 index b5f2f41061d..00000000000 --- a/config/ax_boost_system.m4 +++ /dev/null @@ -1,114 +0,0 @@ -##### http://autoconf-archive.cryp.to/ax_boost_system.html -# -# SYNOPSIS -# -# AX_BOOST_SYSTEM -# -# DESCRIPTION -# -# Test for System library from the Boost C++ libraries. The macro -# requires a preceding call to AX_BOOST_BASE. Further documentation -# is available at . -# -# This macro calls: -# -# AC_SUBST(BOOST_SYSTEM_LIB) -# -# And sets: -# -# HAVE_BOOST_SYSTEM -# -# COPYLEFT -# -# Copyright (c) 2008 Thomas Porschberg -# Copyright (c) 2008 Michael Tindal -# Copyright (c) 2008 Daniel Casimiro -# -# 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. - -AC_DEFUN([AX_BOOST_SYSTEM], -[ - AC_BEFORE([$0], [AX_BOOST_THREAD]) - - AC_ARG_WITH([boost-system], - AS_HELP_STRING([--with-boost-system@<:@=special-lib@:>@], - [use the System library from boost - it is possible to specify a certain library for the linker - e.g. --with-boost-system=boost_system-gcc-mt ]), - [ - if test "$withval" = "no"; then - want_boost="no" - elif test "$withval" = "yes"; then - want_boost="yes" - ax_boost_user_system_lib="" - else - want_boost="yes" - ax_boost_user_system_lib="$withval" - fi - ], - [want_boost="yes"] - ) - - if test "x$want_boost" = "xyes"; then - AC_REQUIRE([AC_PROG_CC]) - AC_REQUIRE([AC_CANONICAL_BUILD]) - CPPFLAGS_SAVED="$CPPFLAGS" - CPPFLAGS="$CPPFLAGS $BOOST_CPPFLAGS" - export CPPFLAGS - - LDFLAGS_SAVED="$LDFLAGS" - LDFLAGS="$LDFLAGS $BOOST_LDFLAGS" - export LDFLAGS - - AC_CACHE_CHECK(whether the Boost::System library is available, - ax_cv_boost_system, - [AC_LANG_PUSH([C++]) - CXXFLAGS_SAVE=$CXXFLAGS - - AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[@%:@include ]], - [[boost::system::system_category]])], - ax_cv_boost_system=yes, ax_cv_boost_system=no) - CXXFLAGS=$CXXFLAGS_SAVE - AC_LANG_POP([C++]) - ]) - if test "x$ax_cv_boost_system" = "xyes"; then - AC_SUBST(BOOST_CPPFLAGS) - - AC_DEFINE(HAVE_BOOST_SYSTEM,,[define if the Boost::System library is available]) - BOOSTLIBDIR=`echo $BOOST_LDFLAGS | sed -e 's/@<:@^\/@:>@*//'` - - LDFLAGS_SAVE=$LDFLAGS - if test "x$ax_boost_user_system_lib" = "x"; then - for libextension in `ls $BOOSTLIBDIR/libboost_system*.{so,dylib,a}* 2>/dev/null | sed 's,.*/,,' | sed -e 's;^lib\(boost_system.*\)\.so.*$;\1;' -e 's;^lib\(boost_system.*\)\.a*$;\1;' -e 's;^lib\(boost_system.*\)\.dylib$;\1;'` ; do - ax_lib=${libextension} - AC_CHECK_LIB($ax_lib, toupper, - [BOOST_SYSTEM_LIB="-l$ax_lib"; AC_SUBST(BOOST_SYSTEM_LIB) link_system="yes"; break], - [link_system="no"]) - done - if test "x$link_system" != "xyes"; then - for libextension in `ls $BOOSTLIBDIR/boost_system*.{dll,a}* 2>/dev/null | sed 's,.*/,,' | sed -e 's;^\(boost_system.*\)\.dll.*$;\1;' -e 's;^\(boost_system.*\)\.a*$;\1;'` ; do - ax_lib=${libextension} - AC_CHECK_LIB($ax_lib, toupper, - [BOOST_SYSTEM_LIB="-l$ax_lib"; AC_SUBST(BOOST_SYSTEM_LIB) link_system="yes"; break], - [link_system="no"]) - done - fi - - else - for ax_lib in $ax_boost_user_system_lib boost_system-$ax_boost_user_system_lib; do - AC_CHECK_LIB($ax_lib, toupper, - [BOOST_SYSTEM_LIB="-l$ax_lib"; AC_SUBST(BOOST_SYSTEM_LIB) link_system="yes"; break], - [link_system="no"]) - done - - fi - if test "x$link_system" = "xno"; then - AC_MSG_ERROR([could not link against "$ax_lib"]) - AC_DEFINE([USE_ROSE_BOOST_WAVE_SUPPORT],1,[Controls use of BOOST WAVE support in ROSE.]) - fi - fi - CPPFLAGS="$CPPFLAGS_SAVED" - LDFLAGS="$LDFLAGS_SAVED" - fi -]) diff --git a/config/ax_boost_test_exec_monitor.m4 b/config/ax_boost_test_exec_monitor.m4 deleted file mode 100644 index cd4293ea5dd..00000000000 --- a/config/ax_boost_test_exec_monitor.m4 +++ /dev/null @@ -1,132 +0,0 @@ -##### http://autoconf-archive.cryp.to/ax_boost_test_exec_monitor.html -# -# SYNOPSIS -# -# AX_BOOST_TEST_EXEC_MONITOR -# -# DESCRIPTION -# -# Test for Test_Exec_Monitor library from the Boost C++ libraries. -# The macro requires a preceding call to AX_BOOST_BASE. Further -# documentation is available at -# . -# -# This macro calls: -# -# AC_SUBST(BOOST_TEST_EXEC_MONITOR_LIB) -# -# And sets: -# -# HAVE_BOOST_TEST_EXEC_MONITOR -# -# COPYLEFT -# -# Copyright (c) 2007 Dodji Seketeli -# Copyright (c) 2007 Thomas Porschberg -# -# 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. - -AC_DEFUN([AX_BOOST_TEST_EXEC_MONITOR], -[ - AC_ARG_WITH([boost-test-exec-monitor], - AS_HELP_STRING([--with-boost-test-exec-monitor@<:@=special-lib@:>@], - [use the Test_Exec_Monitor library from boost - it is possible to specify a certain library for the linker - e.g. --with-boost-test-exec-monitor=boost_test_exec_monitor-gcc ]), - [ - if test "$withval" = "no"; then - want_boost="no" - elif test "$withval" = "yes"; then - want_boost="yes" - ax_boost_user_test_exec_monitor_lib="" - else - want_boost="yes" - ax_boost_user_test_exec_monitor_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" - export CPPFLAGS - - LDFLAGS_SAVED="$LDFLAGS" - LDFLAGS="$LDFLAGS $BOOST_LDFLAGS" - export LDFLAGS - - AC_CACHE_CHECK(whether the Boost::Test_Exec_Monitor library is available, - ax_cv_boost_test_exec_monitor, - [AC_LANG_PUSH([C++]) - AC_COMPILE_IFELSE(AC_LANG_PROGRAM([[@%:@include ]], - [[int i=1 ; BOOST_REQUIRE(i==1); ; return 0;]]), - ax_cv_boost_test_exec_monitor=yes, ax_cv_boost_test_exec_monitor=no) - AC_LANG_POP([C++]) - ]) - if test "x$ax_cv_boost_test_exec_monitor" = "xyes"; then - AC_DEFINE(HAVE_BOOST_TEST_EXEC_MONITOR,,[define if the Boost::Test_Exec_Monitor library is available]) - BOOSTLIBDIR=`echo $BOOST_LDFLAGS | sed -e 's/@<:@^\/@:>@*//'` - - if test "x$ax_boost_user_test_exec_monitor_lib" = "x"; then - saved_ldflags="${LDFLAGS}" - - for monitor_library in `ls $BOOSTLIBDIR/libboost_test_exec_monitor*.{so,dylib,a}* 2>/dev/null` ; do - if test -r $monitor_library ; then - libextension=`echo $monitor_library | sed 's,.*/,,' | sed -e 's;^lib\(boost_test_exec_monitor.*\)\.so.*$;\1;' -e 's;^lib\(boost_test_exec_monitor.*\)\.a*$;\1;' -e 's;^lib\(boost_test_exec_monitor.*\)\.dylib$;\1;'` - ax_lib=${libextension} - link_test_exec_monitor="yes" - else - link_test_exec_monitor="no" - fi - - if test "x$link_test_exec_monitor" = "xyes"; then - BOOST_TEST_EXEC_MONITOR_LIB="-l$ax_lib" - AC_SUBST(BOOST_TEST_EXEC_MONITOR_LIB) - break - fi - done - if test "x$link_test_exec_monitor" != "xyes"; then - for libextension in `ls $BOOSTLIBDIR/boost_test_exec_monitor*.{dll,a}* 2>/dev/null | sed 's,.*/,,' | sed -e 's;^\(boost_test_exec_monitor.*\)\.dll.*$;\1;' -e 's;^\(boost_test_exec_monitor.*\)\.a*$;\1;'` ; do - ax_lib=${libextension} - AC_CHECK_LIB($ax_lib, toupper, - [BOOST_TEST_EXEC_MONITOR_LIB="-l$ax_lib"; AC_SUBST(BOOST_TEST_EXEC_MONITOR_LIB) link_test_exec_monitor="yes"; break], - [link_test_exec_monitor="no"]) - done - fi - - else - link_test_exec_monitor="no" - saved_ldflags="${LDFLAGS}" - for ax_lib in boost_test_exec_monitor-$ax_boost_user_test_exec_monitor_lib $ax_boost_user_test_exec_monitor_lib ; do - if test "x$link_test_exec_monitor" = "xyes"; then - break; - fi - for monitor_library in `ls $BOOSTLIBDIR/lib${ax_lib}.{so,dylib,a}* 2>/dev/null` ; do - if test -r $monitor_library ; then - libextension=`echo $monitor_library | sed 's,.*/,,' | sed -e 's;^lib\(boost_test_exec_monitor.*\)\.so.*$;\1;' -e 's;^lib\(boost_test_exec_monitor.*\)\.a*$;\1;' -e 's;^lib\(boost_test_exec_monitor.*\)\.dylib$;\1;'` - ax_lib=${libextension} - link_test_exec_monitor="yes" - else - link_test_exec_monitor="no" - fi - - if test "x$link_test_exec_monitor" = "xyes"; then - BOOST_TEST_EXEC_MONITOR_LIB="-l$ax_lib" - AC_SUBST(BOOST_TEST_EXEC_MONITOR_LIB) - break - fi - done - done - fi - if test "x$link_test_exec_monitor" != "xyes"; then - AC_MSG_ERROR([could not link against "$ax_lib"]) - fi - fi - - CPPFLAGS="$CPPFLAGS_SAVED" - LDFLAGS="$LDFLAGS_SAVED" - fi -]) diff --git a/config/ax_boost_thread.m4 b/config/ax_boost_thread.m4 deleted file mode 100644 index 230af2cbb46..00000000000 --- a/config/ax_boost_thread.m4 +++ /dev/null @@ -1,148 +0,0 @@ -##### http://autoconf-archive.cryp.to/ax_boost_thread.html -# -# SYNOPSIS -# -# AX_BOOST_THREAD -# -# DESCRIPTION -# -# Test for Thread library from the Boost C++ libraries. The macro -# requires a preceding call to AX_BOOST_BASE. Further documentation -# is available at . -# -# This macro calls: -# -# AC_SUBST(BOOST_THREAD_LIB) -# -# And sets: -# -# HAVE_BOOST_THREAD -# -# COPYLEFT -# -# Copyright (c) 2007 Thomas Porschberg -# Copyright (c) 2007 Michael Tindal -# -# 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. - -AC_DEFUN([AX_BOOST_THREAD], -[ - AC_ARG_WITH([boost-thread], - AS_HELP_STRING([--with-boost-thread@<:@=special-lib@:>@], - [Use the Thread library from Boost. If the value is 'yes' or a certain library then ROSE will - incorporate multi-thread support into some of its algorithms. The default is to incorporate - multi-thread support into ROSE algorithms since Boost is compiled with thread support by default. - If thread support is enabled then user code should also be compiled and linked with switches - appropriate for multi-threading e.g., -pthread for GCC. If the user compiles Boost without - thread support, then --without-boost-thread can be given on the ROSE configure commandline. ]), - [ - if test "$withval" = "no"; then - want_boost="no" - elif test "$withval" = "yes"; then - want_boost="yes" - ax_boost_user_thread_lib="" - else - want_boost="yes" - ax_boost_user_thread_lib="$withval" - fi - ], - [want_boost="yes"] - ) - - if test "x$want_boost" = "xyes"; then - AC_REQUIRE([AC_PROG_CC]) - AC_REQUIRE([AC_CANONICAL_BUILD]) - CPPFLAGS_SAVED="$CPPFLAGS" - CPPFLAGS="$CPPFLAGS $BOOST_CPPFLAGS" - export CPPFLAGS - - LDFLAGS_SAVED="$LDFLAGS" - LDFLAGS="$LDFLAGS $BOOST_LDFLAGS" - export LDFLAGS - - AC_CACHE_CHECK(whether the boost/thread/thread.hpp header is available, - ax_cv_boost_thread, - [ - AC_LANG_PUSH([C++]) - CXXFLAGS_SAVE=$CXXFLAGS - - case "$build_os" in - solaris ) CXXFLAGS="-pthreads $CXXFLAGS" ;; - ming32 ) CXXFLAGS="-mthreads $CXXFLAGS" ;; - # DQ (12/6/2016): Added pthread option since it appears that the default installation of Boost used pthread library. - # Note that their is no "s" on the -pthread option for Clang or GNU g++. - # Note that since boost appears to not be compiled on OSX with threading enabled, we don't want to specify -pthread option to the compiler. - # darwin* ) CXXFLAGS="$CXXFLAGS" ;; - # darwin* ) CXXFLAGS="-pthread $CXXFLAGS" ;; - darwin* ) CXXFLAGS="$CXXFLAGS" ;; - * ) CXXFLAGS="-pthread $CXXFLAGS" ;; - esac - AC_COMPILE_IFELSE( - [AC_LANG_PROGRAM([[@%:@include ]], - [[boost::thread_group thrds; - return 0;]])], - ax_cv_boost_thread=yes, - ax_cv_boost_thread=no) - - CXXFLAGS=$CXXFLAGS_SAVE - AC_LANG_POP([C++]) - ]) - - if test "x$ax_cv_boost_thread" = "xyes"; then - AC_MSG_NOTICE([boost thread header found; checking for library...]) - case "$build_os" in - solaris ) BOOST_CPPFLAGS="-pthreads $BOOST_CPPFLAGS" ;; - ming32 ) BOOST_CPPFLAGS="-mthreads $BOOST_CPPFLAGS" ;; - darwin* ) BOOST_CPPFLAGS="$BOOST_CPPFLAGS" ;; - * ) BOOST_CPPFLAGS="-pthread $BOOST_CPPFLAGS" ;; - esac - - AC_SUBST(BOOST_CPPFLAGS) - - AC_DEFINE(HAVE_BOOST_THREAD,,[define if the Boost::Thread library is available]) - BOOSTLIBDIR=`echo $BOOST_LDFLAGS | sed -e 's/@<:@^\/@:>@*//'` - - LDFLAGS_SAVE=$LDFLAGS - case "x$build_os" in - *bsd* ) LDFLAGS="-pthread $LDFLAGS" ;; - esac - if test "x$ax_boost_user_thread_lib" = "x"; then - for libextension in `ls $BOOSTLIBDIR/libboost_thread*.{so,dylib,a}* 2>/dev/null | sed 's,.*/,,' | sed -e 's;^lib\(boost_thread.*\)\.so.*$;\1;' -e 's;^lib\(boost_thread.*\)\.a*$;\1;' -e 's;^lib\(boost_thread.*\)\.dylib$;\1;'` ; do - ax_lib=${libextension} - AC_CHECK_LIB($ax_lib, toupper, - [BOOST_THREAD_LIB="-l$ax_lib"; AC_SUBST(BOOST_THREAD_LIB) link_thread="yes"; break], - [link_thread="no"], [${BOOST_SYSTEM_LIB}]) - done - if test "x$link_thread" != "xyes"; then - for libextension in `ls $BOOSTLIBDIR/boost_thread*.{dll,a}* 2>/dev/null | sed 's,.*/,,' | sed -e 's;^\(boost_thread.*\)\.dll.*$;\1;' -e 's;^\(boost_thread.*\)\.a*$;\1;'` ; do - ax_lib=${libextension} - AC_CHECK_LIB($ax_lib, toupper, - [BOOST_THREAD_LIB="-l$ax_lib"; AC_SUBST(BOOST_THREAD_LIB) link_thread="yes"; break], - [link_thread="no"], [${BOOST_SYSTEM_LIB}]) - done - fi - else - for ax_lib in $ax_boost_user_thread_lib boost_thread-$ax_boost_user_thread_lib; do - AC_CHECK_LIB($ax_lib, toupper, - [BOOST_THREAD_LIB="-l$ax_lib"; AC_SUBST(BOOST_THREAD_LIB) link_thread="yes"; break], - [link_thread="no"], [${BOOST_SYSTEM_LIB}]) - done - fi - - if test "x$link_thread" != "xyes"; then - AC_MSG_ERROR([could not link against -lboost_thread; ROSE requires this library in "$BOOSTLIBDIR"]) - else - case "x$build_os" in - *bsd* ) BOOST_LDFLAGS="-pthread $BOOST_LDFLAGS" ;; - *linux-gnu*) BOOST_LDFLAGS="-pthread $BOOST_LDFLAGS" ;; - esac - AC_MSG_RESULT([boost thread library found: $BOOST_LDFLAGS]) - fi - fi - - CPPFLAGS="$CPPFLAGS_SAVED" - LDFLAGS="$LDFLAGS_SAVED" - fi -]) diff --git a/config/ax_boost_unit_test_framework.m4 b/config/ax_boost_unit_test_framework.m4 deleted file mode 100644 index a1add1657e9..00000000000 --- a/config/ax_boost_unit_test_framework.m4 +++ /dev/null @@ -1,130 +0,0 @@ -##### http://autoconf-archive.cryp.to/ax_boost_unit_test_framework.html -# -# SYNOPSIS -# -# AX_BOOST_UNIT_TEST_FRAMEWORK -# -# DESCRIPTION -# -# Test for Unit_Test_Framework library from the Boost C++ libraries. -# The macro requires a preceding call to AX_BOOST_BASE. Further -# documentation is available at -# . -# -# This macro calls: -# -# AC_SUBST(BOOST_UNIT_TEST_FRAMEWORK_LIB) -# -# And sets: -# -# HAVE_BOOST_UNIT_TEST_FRAMEWORK -# -# COPYLEFT -# -# Copyright (c) 2007 Thomas Porschberg -# -# 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. - -AC_DEFUN([AX_BOOST_UNIT_TEST_FRAMEWORK], -[ - AC_ARG_WITH([boost-unit-test-framework], - AS_HELP_STRING([--with-boost-unit-test-framework@<:@=special-lib@:>@], - [use the Unit_Test_Framework library from boost - it is possible to specify a certain library for the linker - e.g. --with-boost-unit-test-framework=boost_unit_test_framework-gcc ]), - [ - if test "$withval" = "no"; then - want_boost="no" - elif test "$withval" = "yes"; then - want_boost="yes" - ax_boost_user_unit_test_framework_lib="" - else - want_boost="yes" - ax_boost_user_unit_test_framework_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" - export CPPFLAGS - - LDFLAGS_SAVED="$LDFLAGS" - LDFLAGS="$LDFLAGS $BOOST_LDFLAGS" - export LDFLAGS - - AC_CACHE_CHECK(whether the Boost::Unit_Test_Framework library is available, - ax_cv_boost_unit_test_framework, - [AC_LANG_PUSH([C++]) - AC_COMPILE_IFELSE(AC_LANG_PROGRAM([[@%:@include ]], - [[using boost::unit_test::test_suite; - test_suite* test= BOOST_TEST_SUITE( "Unit test example 1" ); return 0;]]), - ax_cv_boost_unit_test_framework=yes, ax_cv_boost_unit_test_framework=no) - AC_LANG_POP([C++]) - ]) - if test "x$ax_cv_boost_unit_test_framework" = "xyes"; then - AC_DEFINE(HAVE_BOOST_UNIT_TEST_FRAMEWORK,,[define if the Boost::Unit_Test_Framework library is available]) - BOOSTLIBDIR=`echo $BOOST_LDFLAGS | sed -e 's/@<:@^\/@:>@*//'` - - if test "x$ax_boost_user_unit_test_framework_lib" = "x"; then - saved_ldflags="${LDFLAGS}" - for monitor_library in `ls $BOOSTLIBDIR/libboost_unit_test_framework*.{so,dylib,a}* 2>/dev/null` ; do - if test -r $monitor_library ; then - libextension=`echo $monitor_library | sed 's,.*/,,' | sed -e 's;^lib\(boost_unit_test_framework.*\)\.so.*$;\1;' -e 's;^lib\(boost_unit_test_framework.*\)\.a*$;\1;' -e 's;^lib\(boost_unit_test_framework.*\)\.dylib$;\1;'` - ax_lib=${libextension} - link_unit_test_framework="yes" - else - link_unit_test_framework="no" - fi - - if test "x$link_unit_test_framework" = "xyes"; then - BOOST_UNIT_TEST_FRAMEWORK_LIB="-l$ax_lib" - AC_SUBST(BOOST_UNIT_TEST_FRAMEWORK_LIB) - break - fi - done - if test "x$link_unit_test_framework" != "xyes"; then - for libextension in `ls $BOOSTLIBDIR/boost_unit_test_framework*.{dll,a}* 2>/dev/null | sed 's,.*/,,' | sed -e 's;^\(boost_unit_test_framework.*\)\.dll.*$;\1;' -e 's;^\(boost_unit_test_framework.*\)\.a*$;\1;'` ; do - ax_lib=${libextension} - AC_CHECK_LIB($ax_lib, toupper, - [BOOST_UNIT_TEST_FRAMEWORK_LIB="-l$ax_lib"; AC_SUBST(BOOST_UNIT_TEST_FRAMEWORK_LIB) link_unit_test_framework="yes"; break], - [link_unit_test_framework="no"]) - done - fi - else - link_unit_test_framework="no" - saved_ldflags="${LDFLAGS}" - for ax_lib in boost_unit_test_framework-$ax_boost_user_unit_test_framework_lib $ax_boost_user_unit_test_framework_lib ; do - if test "x$link_unit_test_framework" = "xyes"; then - break; - fi - for unittest_library in `ls $BOOSTLIBDIR/lib${ax_lib}.{so,dylib,a}* 2>/dev/null` ; do - if test -r $unittest_library ; then - libextension=`echo $unittest_library | sed 's,.*/,,' | sed -e 's;^lib\(boost_unit_test_framework.*\)\.so.*$;\1;' -e 's;^lib\(boost_unit_test_framework.*\)\.a*$;\1;' -e 's;^lib\(boost_unit_test_framework.*\)\.dylib$;\1;'` - ax_lib=${libextension} - link_unit_test_framework="yes" - else - link_unit_test_framework="no" - fi - - if test "x$link_unit_test_framework" = "xyes"; then - BOOST_UNIT_TEST_FRAMEWORK_LIB="-l$ax_lib" - AC_SUBST(BOOST_UNIT_TEST_FRAMEWORK_LIB) - break - fi - done - done - fi - if test "x$link_unit_test_framework" != "xyes"; then - AC_MSG_ERROR([could not link against "$ax_lib"]) - fi - fi - - CPPFLAGS="$CPPFLAGS_SAVED" - LDFLAGS="$LDFLAGS_SAVED" - fi -]) diff --git a/config/ax_boost_wave.m4 b/config/ax_boost_wave.m4 deleted file mode 100644 index 4473ea8bee8..00000000000 --- a/config/ax_boost_wave.m4 +++ /dev/null @@ -1,119 +0,0 @@ - http://autoconf-archive.cryp.to/ax_boost_regex.html -# -# SYNOPSIS -# -# AX_BOOST_WAVE -# -# DESCRIPTION -# -# Test for Wave library from the Boost C++ libraries. The macro -# requires a preceding call to AX_BOOST_BASE. Further documentation -# is available at . -# -# This macro calls: -# -# AC_SUBST(BOOST_WAVE_LIB) -# -# And sets: -# -# HAVE_BOOST_WAVE -# -# COPYLEFT -# -# Copyright (c) 2007 Thomas Porschberg -# Copyright (c) 2007 Michael Tindal -# -# 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. - -AC_DEFUN([AX_BOOST_WAVE], -[ - AC_ARG_WITH([boost-wave], - AS_HELP_STRING([--with-boost-wave@<:@=special-lib@:>@], - [use the Wave library from boost - it is possible to specify a certain library for the linker - e.g. --with-boost-wave=boost_wave-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_wave_lib="" - else - want_boost="yes" - ax_boost_user_wave_lib="$withval" - fi - ], - [want_boost="yes"] - ) - AM_CONDITIONAL(ROSE_USE_BOOST_WAVE, test "x$want_boost" = "xyes" ) - - if test "x$want_boost" = "xyes"; then - AC_REQUIRE([AC_PROG_CC]) - CPPFLAGS_SAVED="$CPPFLAGS" - CPPFLAGS="$CPPFLAGS $BOOST_CPPFLAGS" - export CPPFLAGS - - LDFLAGS_SAVED="$LDFLAGS" - LDFLAGS="$LDFLAGS $BOOST_LDFLAGS" - export LDFLAGS - - LIBS_SAVED=$LIBS - LIBS="$LIBS $BOOST_SYSTEM_LIB $BOOST_THREAD_LIB" - export LIBS - - AC_CACHE_CHECK(whether the Boost::Wave library is available, - ax_cv_boost_wave, - [AC_LANG_PUSH([C++]) - AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[@%:@include - ]], - [[boost::wave::token_category r; return 0;]])], - ax_cv_boost_wave=yes, ax_cv_boost_wave=no) - AC_LANG_POP([C++]) - ]) - if test "x$ax_cv_boost_wave" = "xyes"; then - - AC_DEFINE(HAVE_BOOST_WAVE,,[define if the Boost::Wave library is available]) - BOOSTLIBDIR=`echo $BOOST_LDFLAGS | sed -e 's/@<:@^\/@:>@*//'` - if test "x$ax_boost_user_wave_lib" = "x"; then - for libextension in `ls $BOOSTLIBDIR/libboost_wave*.{so,dylib,a}* 2>/dev/null | sed 's,.*/,,' | sed -e 's;^lib\(boost_wave.*\)\.so.*$;\1;' -e 's;^lib\(boost_wave.*\)\.a*$;\1;' -e 's;^lib\(boost_wave.*\)\.dylib$;\1;'` ; do - ax_lib=${libextension} - AC_CHECK_LIB($ax_lib, toupper, - [BOOST_WAVE_LIB="-l$ax_lib"; AC_SUBST(BOOST_WAVE_LIB) link_wave="yes"; break], - [link_wave="no"]) - done - if test "x$link_wave" != "xyes"; then - for libextension in `ls $BOOSTLIBDIR/boost_wave*.{dll,a}* 2>/dev/null | sed 's,.*/,,' | sed -e 's;^\(boost_wave.*\)\.dll.*$;\1;' -e 's;^\(boost_wave.*\)\.a*$;\1;'` ; do - ax_lib=${libextension} - AC_CHECK_LIB($ax_lib, toupper, - [BOOST_WAVE_LIB="-l$ax_lib"; AC_SUBST(BOOST_WAVE_LIB) link_wave="yes"; break], - [link_wave="no"]) - done - fi - - else - for ax_lib in $ax_boost_user_wave_lib boost_wave-$ax_boost_user_wave_lib; do - AC_CHECK_LIB($ax_lib, main, - [BOOST_WAVE_LIB="-l$ax_lib"; AC_SUBST(BOOST_WAVE_LIB) link_wave="yes"; break], - [link_wave="no"]) - done - fi - if test "x$link_wave" != "xyes"; then - AC_MSG_ERROR([could not link against "$ax_lib"]) - fi - # DQ (4/7/2006): build a macro to use in source code to know when WAVE is to be used. - AC_DEFINE([USE_ROSE_BOOST_WAVE_SUPPORT],1,[Controls use of BOOST WAVE support in ROSE.]) - - else - AC_DEFINE([USE_ROSE_BOOST_WAVE_SUPPORT],0,[Controls use of BOOST WAVE support in ROSE.]) - - fi - - - - CPPFLAGS="$CPPFLAGS_SAVED" - LDFLAGS="$LDFLAGS_SAVED" - LIBS="$LIBS_SAVED" - - fi -]) diff --git a/config/ax_boost_wserialization.m4 b/config/ax_boost_wserialization.m4 deleted file mode 100644 index 48f232d409f..00000000000 --- a/config/ax_boost_wserialization.m4 +++ /dev/null @@ -1,109 +0,0 @@ -##### http://autoconf-archive.cryp.to/ax_boost_wserialization.html -# -# SYNOPSIS -# -# AX_BOOST_WSERIALIZATION -# -# DESCRIPTION -# -# Test for Serialization library from the Boost C++ libraries. The -# macro requires a preceding call to AX_BOOST_BASE. Further -# documentation is available at -# . -# -# This macro calls: -# -# AC_SUBST(BOOST_WSERIALIZATION_LIB) -# -# And sets: -# -# HAVE_BOOST_WSERIALIZATION -# -# COPYLEFT -# -# Copyright (c) 2007 Thomas Porschberg -# -# 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. - -AC_DEFUN([AX_BOOST_WSERIALIZATION], -[ - AC_ARG_WITH([boost-wserialization], - AS_HELP_STRING([--with-boost-wserialization@<:@=special-lib@:>@], - [use the WSerialization library from boost - it is possible to specify a certain library for the linker - e.g. --with-boost-wserialization=boost_wserialization-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_wserialization_lib="" - else - want_boost="yes" - ax_boost_user_wserialization_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" - export CPPFLAGS - - LDFLAGS_SAVED="$LDFLAGS" - LDFLAGS="$LDFLAGS $BOOST_LDFLAGS" - export LDFLAGS - - AC_CACHE_CHECK(whether the Boost::WSerialization library is available, - ax_cv_boost_wserialization, - [AC_LANG_PUSH([C++]) - AC_COMPILE_IFELSE(AC_LANG_PROGRAM([[@%:@include - @%:@include - @%:@include - ]], - [[std::ofstream ofs("filename"); - boost::archive::text_oarchive oa(ofs); - return 0; - ]]), - ax_cv_boost_wserialization=yes, ax_cv_boost_wserialization=no) - AC_LANG_POP([C++]) - ]) - if test "x$ax_cv_boost_wserialization" = "xyes"; then - AC_DEFINE(HAVE_BOOST_WSERIALIZATION,,[define if the Boost::WSerialization library is available]) - BOOSTLIBDIR=`echo $BOOST_LDFLAGS | sed -e 's/@<:@^\/@:>@*//'` - if test "x$ax_boost_user_wserialization_lib" = "x"; then - for libextension in `ls $BOOSTLIBDIR/libboost_wserialization*.{so,dylib,a}* 2>/dev/null | sed 's,.*/,,' | sed -e 's;^lib\(boost_wserialization.*\)\.so.*$;\1;' -e 's;^lib\(boost_wserialization.*\)\.a*$;\1;' -e 's;^lib\(boost_wserialization.*\)\.dylib$;\1;'` ; do - ax_lib=${libextension} - AC_CHECK_LIB($ax_lib, toupper, - [BOOST_WSERIALIZATION_LIB="-l$ax_lib"; AC_SUBST(BOOST_WSERIALIZATION_LIB) link_wserialization="yes"; break], - [link_wserialization="no"]) - done - if test "x$link_wserialization" != "xyes"; then - for libextension in `ls $BOOSTLIBDIR/boost_wserialization*.{dll,a}* 2>/dev/null | sed 's,.*/,,' | sed -e 's;^\(boost_wserialization.*\)\.dll.*$;\1;' -e 's;^\(boost_wserialization.*\)\.a*$;\1;'` ; do - ax_lib=${libextension} - AC_CHECK_LIB($ax_lib, toupper, - [BOOST_WSERIALIZATION_LIB="-l$ax_lib"; AC_SUBST(BOOST_WSERIALIZATION_LIB) link_wserialization="yes"; break], - [link_wserialization="no"]) - done - fi - - else - for ax_lib in $ax_boost_user_wserialization_lib boost_wserialization-$ax_boost_user_wserialization_lib; do - AC_CHECK_LIB($ax_lib, main, - [BOOST_WSERIALIZATION_LIB="-l$ax_lib"; AC_SUBST(BOOST_WSERIALIZATION_LIB) link_wserialization="yes"; break], - [link_wserialization="no"]) - done - - fi - if test "x$link_wserialization" != "xyes"; then - AC_MSG_ERROR([could not link against "$ax_lib"]) - fi - fi - - CPPFLAGS="$CPPFLAGS_SAVED" - LDFLAGS="$LDFLAGS_SAVED" - fi -]) diff --git a/config/ax_rose_lib.m4 b/config/ax_rose_lib.m4 deleted file mode 100644 index 21924602e03..00000000000 --- a/config/ax_rose_lib.m4 +++ /dev/null @@ -1,100 +0,0 @@ -##### http://autoconf-archive.cryp.to/ax_rose.html -# -# SYNOPSIS -# -# AX_ROSE_LIB -# -# DESCRIPTION -# -# Test for program options library from the Boost C++ libraries. The -# macro requires a preceding call to AX_ROSE_LIB_BASE. Further -# documentation is available at -# . -# -# This macro calls: -# -# AC_SUBST(ROSE_LIB) -# -# And sets: -# -# HAVE_ROSE -# -# COPYLEFT -# -# Copyright (c) 2007 Thomas Porschberg -# -# 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. - -AC_DEFUN([AX_ROSE_LIB], -[ - AC_ARG_WITH([rose-lib], - AS_HELP_STRING([--with-rose-lib@<:@=special-lib@:>@], - [use the program options library from rose - it is possible to specify a certain library for the linker - e.g. --with-rose-lib=rose-gcc-mt-1_33_1 ]), - [ - if test "$withval" = "no"; then - want_rose="no" - elif test "$withval" = "yes"; then - want_rose="yes" - ax_rose_user_lib="" - else - want_rose="yes" - ax_rose_user_lib="$withval" - fi - ], - [want_rose="yes"] - ) - - if test "x$want_rose" = "xyes"; then - AC_REQUIRE([AC_PROG_CC]) - export want_rose - CPPFLAGS_SAVED="$CPPFLAGS" - CPPFLAGS="$CPPFLAGS $ROSE_CPPFLAGS $BOOST_CPPFLAGS " - export CPPFLAGS - LDFLAGS_SAVED="$LDFLAGS" - LDFLAGS="$LDFLAGS $ROSE_LDFLAGS $BOOST_LDFLAGS " - export LDFLAGS - AC_CACHE_CHECK([whether the Boost::Program_Options library is available], - ax_cv_rose, - [AC_LANG_PUSH(C++) - AC_COMPILE_IFELSE(AC_LANG_PROGRAM([[@%:@include - ]], - [[ return 0;]]), - ax_cv_rose=yes, ax_cv_rose=no) - AC_LANG_POP([C++]) - ]) - if test "$ax_cv_rose" = yes; then - AC_DEFINE(HAVE_ROSE,,[define if the Boost::PROGRAM_OPTIONS library is available]) - ROSELIBDIR=`echo $ROSE_LDFLAGS | sed -e 's/@<:@^\/@:>@*//'` - if test "x$ax_rose_user_lib" = "x"; then - for libextension in `ls $ROSELIBDIR/librose*.{so,a}* 2>/dev/null | sed 's,.*/,,' | sed -e 's;^lib\(rose.*\)\.so.*$;\1;' -e 's;^lib\(rose.*\)\.a*$;\1;'` ; do - ax_lib=${libextension} - AC_CHECK_LIB($ax_lib, exit, - [ROSE_LIB="-l$ax_lib"; AC_SUBST(ROSE_LIB) link="yes"; break], - [link="no"]) - done - if test "x$link" != "xyes"; then - for libextension in `ls $ROSELIBDIR/rose*.{dll,a}* 2>/dev/null | sed 's,.*/,,' | sed -e 's;^\(rose.*\)\.dll.*$;\1;' -e 's;^\(rose.*\)\.a*$;\1;'` ; do - ax_lib=${libextension} - AC_CHECK_LIB($ax_lib, exit, - [ROSE_LIB="-l$ax_lib"; AC_SUBST(ROSE_LIB) link="yes"; break], - [link="no"]) - done - fi - else - for ax_lib in $ax_rose_user_lib rose-$ax_rose_user_lib; do - AC_CHECK_LIB($ax_lib, main, - [ROSE_LIB="-l$ax_lib"; AC_SUBST(ROSE_LIB) link="yes"; break], - [link="no"]) - done - fi - if test "x$link" != "xyes"; then - AC_MSG_ERROR([could not link against "$ax_lib"]) - fi - fi - CPPFLAGS="$CPPFLAGS_SAVED" - LDFLAGS="$LDFLAGS_SAVED" - fi -]) diff --git a/config/support-blacklist.m4 b/config/support-blacklist.m4 deleted file mode 100644 index a1ff8faf1de..00000000000 --- a/config/support-blacklist.m4 +++ /dev/null @@ -1,123 +0,0 @@ -# Support for gracefully bailing out of configure for certain combinations of dependency versions -# or other situations. - -AC_DEFUN([ROSE_SUPPORT_BLACKLIST],[ - prohibited= - - # ----------------------- - # Versions we HAVE - # ----------------------- - - # Debugging blacklists... Spit out the values that will be needed by users when they're - # trying to figure out why their configuration is blacklisted. These are the versions they - # HAVE. The versions that are PROHIBITED will be emitted later in this function. The version - # number variables should be set wherever we're detecting the dependency, not here. - - # ----------------------- - # Versions we PROHIBIT - # ----------------------- - - ROSE_CONFIGURE_SECTION([Checking blacklisted configurations]) - while true; do - # Boost 1.54 has numerous bugs related to threads. These manifest themselves as compile errors in - # the first ROSE source that happens to include boost thread support, usually something in the - # src/util/Sawyer directory. - if test "$rose_boost_version" = 105400 -a \ - "$FRONTEND_CXX_COMPILER_VENDOR" = "gnu" -a \ - "$FRONTEND_CXX_VERSION_MAJOR" = 4 -a \ - "$FRONTEND_CXX_VERSION_MINOR" -ge 8; then - prohibited="boost 1.54 with gcc >= 4.8 and gcc < 5" - break - fi - - # Boost-1.60.0 serialization cannot be compiled with GCC-6.1.0 because of ambiguous destructors. Also, when - # optimizations are disabled and assertions are enabled, the assembler ("as") takes about an hour to compile - # src/Rose/BinaryAnalysis/SerialIo.C on a fast machine (this is true of boost-1.61 with GCC-6.1.0 as well). - if test "$support_binaries_frontend" = yes -a \ - "$rose_boost_version" = 106000 -a \ - "$FRONTEND_CXX_COMPILER_VENDOR" = gnu -a \ - "$FRONTEND_CXX_VERSION_MAJOR" = 6 -a \ - "$FRONTEND_CXX_VERSION_MINOR" = 1; then - prohibited="binary analysis enabled with boost 1.60.x and GCC 6.1.x" - break - fi - - # Boost-1.61 through 1.63 serialization cause link errors when compiled by Intel compilers. Binary analysis - # is the only thing that uses serialization at this time. - if test "$rose_boost_version" -ge 106100 -a "$rose_boost_version" -le 106300 -a \ - "$FRONTEND_CXX_COMPILER_VENDOR" = "intel" -a \ - "$support_binaries_frontend" = "yes"; then - prohibited="binary analysis enabled with boost 1.61 through 1.63 with Intel compiler" - break - fi - - # Boost-1.65.x have segmentation faults in the destructors of some serialization static objects within the Boost - # library. I thought this was just for GCC 4 and 5, but after enabling wider testing, we're also getting the - # segmentation faults with GCC 7 and 8. Therefore, this version of boost is blacklisted if binary analysis - # support is enabled. - if test "$rose_boost_version" = 106500 -o "$rose_boost_version" = 106501; then - if test "$support_binaries_frontend" = yes -a "$FRONTEND_CXX_COMPILER_VENDOR" = gnu ; then - prohibited="binary analysis enabled with boost 1.65 with GCC compiler" - break - fi - fi - - # Boost-1.68.0 has serialization bugs reported by numerous other projects. Within ROSE, 1.68.0 fails the - # basic boost serialization tests that we've written. These tests don't depend on ROSE, rather link only - # with boost. - if test "$rose_boost_version" = 106800; then - prohibited="boost-1.68.0" - break - fi - - # Boost versions prior to 1.68.0 do not work with C++17 and GNU++17 compilers. They experience compiler - # errors when a program tries to use the two-argument version of boost::lock, which is needed by ROSE for - # thread synchronization. - if test "$rose_boost_version" -le 106800; then - if test "$HOST_CXX_LANGUAGE" = "c++17" -o "$HOST_CXX_LANGUAGE" = "gnu++17"; then - prohibited="boost-$rose_boost_version with $HOST_CXX_LANGUAGE (problems with boost::lock)" - break - fi - fi - - # Z3 4.7.1 is blacklisted because it introduced an API change without any easy way to detect the change - # at compile time. - if test "$Z3_VERSION" = "4.7.1.0"; then - prohibited="z3-4.7.1" - break - fi - - # Add more blacklist items right above this line with comments like the others. If you detect - # a combination that's blacklisted, then set the "prohibited" string to say what is blacklisted - # and then break out of the loop to avoid testing other combinations. - : whatever tests you like - - # If we made it this far then this combination is not blacklisted - prohibited= - break - done - - # ----------------------- - # Output results - # ----------------------- - AC_ARG_ENABLE([blacklist], - AS_HELP_STRING([--disable-blacklist], - [Disabling the blacklist check causes blacklist related messages to become non-fatal. - The default --enable-blacklist, means trying to use a blacklisted configuration is fatal.]), - [should_die="$enableval"], [should_die=yes]) - - if test "$prohibited" != ""; then - if test "$should_die" != no; then - AC_MSG_FAILURE([blacklisted: $prohibited - The above combination of ROSE software dependencies is blacklisted. The ROSE - team occassionally blacklists combinations that are known to cause failures in - perhaps subtle ways. If you would like to continue with this configuration at your - own risk, then reconfigure with --disable-blacklist. (This message comes from - config/support-blacklist.m4, which also contains more information about the reason - for blacklisting.)]) - else - AC_MSG_WARN([blacklisted: $prohibited]) - AC_MSG_WARN([ continuing with unsafe configuration at user's request (--disable-blacklist)]) - fi - fi -]) diff --git a/config/support-boost.m4 b/config/support-boost.m4 deleted file mode 100644 index 39e89097d6f..00000000000 --- a/config/support-boost.m4 +++ /dev/null @@ -1,198 +0,0 @@ -##### http://www.rosecompiler.org -# -# SYNOPSIS -# -# ROSE_SUPPORT_BOOST([]) -# -# DESCRIPTION -# -# Handle Boost C++ Library settings. -# -# This macro calls: -# -# AC_SUBST(ac_boost_path) -# -# And sets: -# -# Automake conditionals: -# AM_CONDITIONAL(ROSE_USING_BOOST_VERSION_X_XX) -# -# CPP #defines: -# AC_DEFINE_UNQUOTED(ROSE_BOOST_PATH) -# AC_DEFINE_UNQUOTED(ROSE_WAVE_PATH) -# -# COPYLEFT -# -# Copyright (c) 2013 Justin Too -# -# 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. - -AC_DEFUN([ROSE_SUPPORT_BOOST], -[ - ROSE_CONFIGURE_SECTION([Checking Boost]) - - - #============================================================================ - # --enable-boost-version-check - #============================================================================ - ROSE_ARG_ENABLE( - [boost-version-check], - [if we should validate your Boost version], - [validate version of Boost C++ libraries (default: yes)], - [yes] - ) - -AX_BOOST_BASE([1.51.0], [], [echo "Boost 1.51.0 - 1.61.0 except 1.54 is required for ROSE" 1>&2; exit 1]) - -dnl Hack using an internal variable from AX_BOOST_BASE -- this path should only -dnl be used to set --with-boost in distcheck. -AC_SUBST(ac_boost_path) - -BOOST_VERSION_HEADER="${ac_boost_path}/include/boost/version.hpp" - -# Liao, 2019/3/12. Check file existence before calling grep -if test -f "$BOOST_VERSION_HEADER" ; then - rose_boost_version=`grep "#define BOOST_VERSION " ${ac_boost_path}/include/boost/version.hpp | cut -d" " -f 3 | tr -d '\r'` -else - ROSE_MSG_ERROR([Unable to find $ac_boost_path/include/boost/version.hpp . Please specify the right boost installation path with --with-boost=/path/to/boost]) -fi - -AC_MSG_NOTICE([rose_boost_version = '$rose_boost_version']) - -if test "x$rose_boost_version" = "x"; then - ROSE_MSG_ERROR([Unable to compute the version of your Boost C++ libraries from '$ac_boost_path'/include/boost/version.hpp . Please make sure the file exists or specify the right path with --with-boost]) -fi - -# DQ (10/22/2015): Added more tests (1.55 through 1.62) -# Define macros for conditional compilation of parts of ROSE based on version of boost -# (this ONLY happens for the tests in tests/nonsmoke/functional/CompilerOptionsTests/testWave) -# -# !! We don't want conditional compilation or code in ROSE based on version numbers of Boost. !! -# -AM_CONDITIONAL(ROSE_USING_BOOST_VERSION_1_35, test "$rose_boost_version" = "103500" -o "$_version" = "1.35") -AM_CONDITIONAL(ROSE_USING_BOOST_VERSION_1_36, test "$rose_boost_version" = "103600" -o "$_version" = "1.36") -AM_CONDITIONAL(ROSE_USING_BOOST_VERSION_1_37, test "$rose_boost_version" = "103700" -o "$_version" = "1.37") -AM_CONDITIONAL(ROSE_USING_BOOST_VERSION_1_38, test "$rose_boost_version" = "103800" -o "$_version" = "1.38") -AM_CONDITIONAL(ROSE_USING_BOOST_VERSION_1_39, test "$rose_boost_version" = "103900" -o "$_version" = "1.39") -AM_CONDITIONAL(ROSE_USING_BOOST_VERSION_1_40, test "$rose_boost_version" = "104000" -o "$_version" = "1.40") -AM_CONDITIONAL(ROSE_USING_BOOST_VERSION_1_41, test "$rose_boost_version" = "104100" -o "$_version" = "1.41") -AM_CONDITIONAL(ROSE_USING_BOOST_VERSION_1_42, test "$rose_boost_version" = "104200" -o "$_version" = "1.42") -AM_CONDITIONAL(ROSE_USING_BOOST_VERSION_1_43, test "$rose_boost_version" = "104300" -o "$_version" = "1.43") -AM_CONDITIONAL(ROSE_USING_BOOST_VERSION_1_44, test "$rose_boost_version" = "104400" -o "$_version" = "1.44") -AM_CONDITIONAL(ROSE_USING_BOOST_VERSION_1_45, test "$rose_boost_version" = "104500" -o "$_version" = "1.45") -AM_CONDITIONAL(ROSE_USING_BOOST_VERSION_1_46, test "$rose_boost_version" = "104600" -o "$_version" = "1.46") -AM_CONDITIONAL(ROSE_USING_BOOST_VERSION_1_46, test "$rose_boost_version" = "104601" -o "$_version" = "1.46") -AM_CONDITIONAL(ROSE_USING_BOOST_VERSION_1_47, test "$rose_boost_version" = "104700" -o "$_version" = "1.47") -AM_CONDITIONAL(ROSE_USING_BOOST_VERSION_1_48, test "$rose_boost_version" = "104800" -o "$_version" = "1.48") -AM_CONDITIONAL(ROSE_USING_BOOST_VERSION_1_49, test "$rose_boost_version" = "104900" -o "$_version" = "1.49") -AM_CONDITIONAL(ROSE_USING_BOOST_VERSION_1_50, test "$rose_boost_version" = "105000" -o "$_version" = "1.50") -AM_CONDITIONAL(ROSE_USING_BOOST_VERSION_1_51, test "$rose_boost_version" = "105100" -o "$_version" = "1.51") -AM_CONDITIONAL(ROSE_USING_BOOST_VERSION_1_52, test "$rose_boost_version" = "105200" -o "$_version" = "1.52") -AM_CONDITIONAL(ROSE_USING_BOOST_VERSION_1_53, test "$rose_boost_version" = "105300" -o "$_version" = "1.53") -AM_CONDITIONAL(ROSE_USING_BOOST_VERSION_1_54, test "$rose_boost_version" = "105400" -o "$_version" = "1.54") -AM_CONDITIONAL(ROSE_USING_BOOST_VERSION_1_55, test "$rose_boost_version" = "105500" -o "$_version" = "1.55") -AM_CONDITIONAL(ROSE_USING_BOOST_VERSION_1_56, test "$rose_boost_version" = "105600" -o "$_version" = "1.56") -AM_CONDITIONAL(ROSE_USING_BOOST_VERSION_1_57, test "$rose_boost_version" = "105700" -o "$_version" = "1.57") -AM_CONDITIONAL(ROSE_USING_BOOST_VERSION_1_58, test "$rose_boost_version" = "105800" -o "$_version" = "1.58") -AM_CONDITIONAL(ROSE_USING_BOOST_VERSION_1_59, test "$rose_boost_version" = "105900" -o "$_version" = "1.59") -AM_CONDITIONAL(ROSE_USING_BOOST_VERSION_1_60, test "$rose_boost_version" = "106000" -o "$_version" = "1.60") -AM_CONDITIONAL(ROSE_USING_BOOST_VERSION_1_61, test "$rose_boost_version" = "106100" -o "$_version" = "1.61") -AM_CONDITIONAL(ROSE_USING_BOOST_VERSION_1_62, test "$rose_boost_version" = "106200" -o "$_version" = "1.62") -AM_CONDITIONAL(ROSE_USING_BOOST_VERSION_1_63, test "$rose_boost_version" = "106300" -o "$_version" = "1.63") -AM_CONDITIONAL(ROSE_USING_BOOST_VERSION_1_64, test "$rose_boost_version" = "106400" -o "$_version" = "1.64") -AM_CONDITIONAL(ROSE_USING_BOOST_VERSION_1_65, test "$rose_boost_version" = "106500" -o "$_version" = "1.65") -AM_CONDITIONAL(ROSE_USING_BOOST_VERSION_1_66, test "$rose_boost_version" = "106600" -o "$_version" = "1.66") -AM_CONDITIONAL(ROSE_USING_BOOST_VERSION_1_67, test "$rose_boost_version" = "106700" -o "$_version" = "1.67") -AM_CONDITIONAL(ROSE_USING_BOOST_VERSION_1_68, test "$rose_boost_version" = "106800" -o "$_version" = "1.68") -AM_CONDITIONAL(ROSE_USING_BOOST_VERSION_1_69, test "$rose_boost_version" = "106900" -o "$_version" = "1.69") - -# DQ (10/22/2015): Added more tests (1.55 through 1.62) -# TOO1 (3/16/2015): -AM_CONDITIONAL(ROSE_USING_BOOST_VERSION_GE_1_35, test $rose_boost_version -ge 103500) -AM_CONDITIONAL(ROSE_USING_BOOST_VERSION_GE_1_36, test $rose_boost_version -ge 103600) -AM_CONDITIONAL(ROSE_USING_BOOST_VERSION_GE_1_37, test $rose_boost_version -ge 103700) -AM_CONDITIONAL(ROSE_USING_BOOST_VERSION_GE_1_38, test $rose_boost_version -ge 103800) -AM_CONDITIONAL(ROSE_USING_BOOST_VERSION_GE_1_39, test $rose_boost_version -ge 103900) -AM_CONDITIONAL(ROSE_USING_BOOST_VERSION_GE_1_40, test $rose_boost_version -ge 104000) -AM_CONDITIONAL(ROSE_USING_BOOST_VERSION_GE_1_41, test $rose_boost_version -ge 104100) -AM_CONDITIONAL(ROSE_USING_BOOST_VERSION_GE_1_42, test $rose_boost_version -ge 104200) -AM_CONDITIONAL(ROSE_USING_BOOST_VERSION_GE_1_43, test $rose_boost_version -ge 104300) -AM_CONDITIONAL(ROSE_USING_BOOST_VERSION_GE_1_44, test $rose_boost_version -ge 104400) -AM_CONDITIONAL(ROSE_USING_BOOST_VERSION_GE_1_45, test $rose_boost_version -ge 104500) -AM_CONDITIONAL(ROSE_USING_BOOST_VERSION_GE_1_46, test $rose_boost_version -ge 104600) -AM_CONDITIONAL(ROSE_USING_BOOST_VERSION_GE_1_46, test $rose_boost_version -ge 104601) -AM_CONDITIONAL(ROSE_USING_BOOST_VERSION_GE_1_47, test $rose_boost_version -ge 104700) -AM_CONDITIONAL(ROSE_USING_BOOST_VERSION_GE_1_48, test $rose_boost_version -ge 104800) -AM_CONDITIONAL(ROSE_USING_BOOST_VERSION_GE_1_49, test $rose_boost_version -ge 104900) -AM_CONDITIONAL(ROSE_USING_BOOST_VERSION_GE_1_50, test $rose_boost_version -ge 105000) -AM_CONDITIONAL(ROSE_USING_BOOST_VERSION_GE_1_51, test $rose_boost_version -ge 105100) -AM_CONDITIONAL(ROSE_USING_BOOST_VERSION_GE_1_52, test $rose_boost_version -ge 105200) -AM_CONDITIONAL(ROSE_USING_BOOST_VERSION_GE_1_53, test $rose_boost_version -ge 105300) -AM_CONDITIONAL(ROSE_USING_BOOST_VERSION_GE_1_54, test $rose_boost_version -ge 105400) -AM_CONDITIONAL(ROSE_USING_BOOST_VERSION_GE_1_55, test $rose_boost_version -ge 105500) -AM_CONDITIONAL(ROSE_USING_BOOST_VERSION_GE_1_56, test $rose_boost_version -ge 105600) -AM_CONDITIONAL(ROSE_USING_BOOST_VERSION_GE_1_57, test $rose_boost_version -ge 105700) -AM_CONDITIONAL(ROSE_USING_BOOST_VERSION_GE_1_58, test $rose_boost_version -ge 105800) -AM_CONDITIONAL(ROSE_USING_BOOST_VERSION_GE_1_59, test $rose_boost_version -ge 105900) -AM_CONDITIONAL(ROSE_USING_BOOST_VERSION_GE_1_60, test $rose_boost_version -ge 106000) -AM_CONDITIONAL(ROSE_USING_BOOST_VERSION_GE_1_61, test $rose_boost_version -ge 106100) -AM_CONDITIONAL(ROSE_USING_BOOST_VERSION_GE_1_62, test $rose_boost_version -ge 106200) -AM_CONDITIONAL(ROSE_USING_BOOST_VERSION_GE_1_63, test $rose_boost_version -ge 106300) -AM_CONDITIONAL(ROSE_USING_BOOST_VERSION_GE_1_64, test $rose_boost_version -ge 106400) -AM_CONDITIONAL(ROSE_USING_BOOST_VERSION_GE_1_65, test $rose_boost_version -ge 106500) -AM_CONDITIONAL(ROSE_USING_BOOST_VERSION_GE_1_66, test $rose_boost_version -ge 106600) -AM_CONDITIONAL(ROSE_USING_BOOST_VERSION_GE_1_67, test $rose_boost_version -ge 106700) -AM_CONDITIONAL(ROSE_USING_BOOST_VERSION_GE_1_68, test $rose_boost_version -ge 106800) -AM_CONDITIONAL(ROSE_USING_BOOST_VERSION_GE_1_69, test $rose_boost_version -ge 106900) - -# DQ (10/22/2015): Added acceptable case 1.54. -# DQ (8/2/2016): Added acceptable case 1.55 through 1.61. -# [Matzke, 2016-09-19] Acceptable cases now 1.49-1.53, 1.55-1.60 decided at Jun 17 meeting, but leaving in 1.61 -# [Matzke, 2019-01-31] Acceptable versions no 1.57-1.69. We decided to support only latest 10 versions from now on. -boost_minimum_version=105700 - -if test "$rose_boost_version" -lt "$boost_minimum_version"; then - if test "$ROSE_ENABLE_BOOST_VERSION_CHECK" = "yes"; then - AC_MSG_FAILURE([boost version $rose_boost_version is unsupported (need $boost_minimum_version or later)]) - else - AC_MSG_WARN([boost version $rose_boost_version is unsupported (need $boost_minimum_version or later)]) - fi -else - AC_MSG_NOTICE([reasonable version of Boost found: $rose_boost_version]) -fi - -# DQ (12/22/2008): Fix boost configure to handle OS with older version of Boost that will -# not work with ROSE, and use the newer version specified by the user on the configure line. -AC_MSG_NOTICE([in ROSE/configure: ac_boost_path = "$ac_boost_path"]) -#AC_DEFINE([ROSE_BOOST_PATH],"$ac_boost_path",[Location of Boost specified on configure line.]) -AC_DEFINE_UNQUOTED([ROSE_BOOST_PATH],"$ac_boost_path",[Location (unquoted) of Boost specified on configure line.]) -#AC_DEFINE([ROSE_WAVE_PATH],"$ac_boost_path/wave",[Location of Wave specified on configure line.]) -AC_DEFINE_UNQUOTED([ROSE_WAVE_PATH],"$ac_boost_path/wave",[Location (unquoted) of Wave specified on configure line.]) - -AC_DEFINE_UNQUOTED([ROSE_BOOST_VERSION], $rose_boost_version, [Version of Boost specified on configure line.]) - -AX_BOOST_ATOMIC -AX_BOOST_SYSTEM -AX_BOOST_THREAD -AX_BOOST_DATE_TIME -AX_BOOST_CHRONO -AX_BOOST_RANDOM dnl needed by Wt and other libraries that use boost -AX_BOOST_REGEX -AX_BOOST_PROGRAM_OPTIONS -#AX_BOOST_SERIALIZATION -#AX_BOOST_ASIO -#AX_BOOST_SIGNALS -#AX_BOOST_TEST_EXEC_MONITOR -AX_BOOST_FILESYSTEM -AX_BOOST_WAVE -#AX_BOOST_PYTHON -AX_BOOST_IOSTREAMS - -# AM_CONDITIONAL(ROSE_USE_BOOST_WAVE,test "$with_wave" = true) -AM_COND_IF([OS_MACOSX],[LDFLAGS="-Xlinker -rpath $ac_boost_path/lib $LDFLAGS"],[]) - -# End macro ROSE_SUPPORT_BOOST. -]) - diff --git a/config/support-ofp.m4 b/config/support-ofp.m4 index 274ac157105..16d24ce2f08 100644 --- a/config/support-ofp.m4 +++ b/config/support-ofp.m4 @@ -7,7 +7,7 @@ ROSE_CONFIGURE_SECTION([Checking Open Fortran Parser (OFP)]) # Used in ../src/3rdPartyLibraries/fortran-parser/Makefile.am # and ../src/frontend/SageIII/sageSupport.C # -default_ofp_version=20200819-JDK8 +default_ofp_version=20200704 ofp_major_version_number=0 ofp_minor_version_number=8 @@ -90,8 +90,16 @@ AC_DEFINE_UNQUOTED([ROSE_OFP_JAR_FILE], $ofp_jar_file , [OFP jar file]) # DQ (4/5/2010): Moved the specification of CLASSPATH to after the specification # of OFP version number so that we can use it to set the class path. - -CLASSPATH=${ABSOLUTE_SRCDIR}/src/3rdPartyLibraries/antlr-jars/antlr-3.5.2-complete.jar:${ABSOLUTE_SRCDIR}${OPEN_FORTRAN_PARSER_PATH}/${ROSE_OFP_JAR_FILE} +ROSE_CLASSPATH=${ABSOLUTE_SRCDIR}/src/3rdPartyLibraries/antlr-jars/antlr-3.5.2-complete.jar:${ABSOLUTE_SRCDIR}${OPEN_FORTRAN_PARSER_PATH}/${ROSE_OFP_JAR_FILE} + +# Prepend ROSE_CLASSPATH to CLASSPATH if already set; otherwise initialize CLASSPATH +AS_IF([test -n "$CLASSPATH"], + [ + CLASSPATH="${ROSE_CLASSPATH}:${CLASSPATH}" + ], + [ + CLASSPATH="${ROSE_CLASSPATH}" + ]) export CLASSPATH AC_SUBST(CLASSPATH) diff --git a/config/support-rose.m4 b/config/support-rose.m4 index 9692860956e..8a068ecb22b 100644 --- a/config/support-rose.m4 +++ b/config/support-rose.m4 @@ -262,15 +262,6 @@ fi # AC_DEFINE([ROSE_USE_NEW_GRAPH_NODES], [], [Whether to use the new graph IR nodes]) #fi -# DQ (5/2/2009): Added support for backward compatability of new IR nodes with older API. -AC_ARG_ENABLE(use_new_graph_node_backward_compatability, - AS_HELP_STRING([--enable-use_new_graph_node_backward_compatability], [Enable new (experimental) graph IR nodes backward compatability API])) -AM_CONDITIONAL(ROSE_USING_GRAPH_IR_NODES_FOR_BACKWARD_COMPATABILITY, [test "x$enable_use_new_graph_node_backward_compatability" = xyes]) -if test "x$enable_use_new_graph_node_backward_compatability" = "xyes"; then - AC_MSG_WARN([using the new graph IR nodes in ROSE (experimental)!]) - AC_DEFINE([ROSE_USING_GRAPH_IR_NODES_FOR_BACKWARD_COMPATABILITY], [], [Whether to use the new graph IR nodes compatability option with older API]) -fi - # Set the value of srcdir so that it will be an absolute path instead of a relative path # srcdir=`dirname "$0"` # echo "In ROSE/con figure: srcdir = $srcdir" @@ -392,8 +383,6 @@ AC_SUBST(ROSE_HOME) AC_LANG(C++) -ROSE_SUPPORT_BOOST - # Rasmussen (12/16/2017): Added test for Bison version (Mac OSX Bison version may be too old) ROSE_SUPPORT_BISON @@ -693,8 +682,6 @@ AC_PROG_MAKE_SET AC_MSG_NOTICE([testing the value of CC: (CC = "$CC")]) AC_MSG_NOTICE([testing the value of CPPFLAGS: (CPPFLAGS = "$CPPFLAGS")]) -AX_BOOST_IOSTREAMS - ROSE_SUPPORT_VECTORIZATION ROSE_SUPPORT_LIBHARU @@ -1197,7 +1184,6 @@ docs/Rose/leftmenu.html docs/Rose/manual.tex docs/Rose/rose-install-demo.cfg docs/Rose/rose.cfg -docs/Rose/roseQtWidgets.doxygen docs/Rose/sage.cfg docs/testDoxygen/Makefile docs/testDoxygen/test.cfg @@ -1222,7 +1208,6 @@ src/ROSETTA/src/Makefile src/backend/Makefile src/frontend/CxxFrontend/Clang/Makefile src/frontend/CxxFrontend/Makefile -src/frontend/Experimental_General_Language_Support/Makefile src/frontend/Makefile src/frontend/OpenFortranParser_SAGE_Connection/Makefile src/frontend/SageIII/GENERATED_CODE_DIRECTORY_Cxx_Grammar/Makefile @@ -1290,7 +1275,6 @@ tests/nonsmoke/functional/CompileTests/RoseExample_tests/Makefile tests/nonsmoke/functional/CompileTests/STL_tests/Makefile tests/nonsmoke/functional/CompileTests/UnparseHeadersTests/Makefile tests/nonsmoke/functional/CompileTests/UnparseHeadersUsingTokenStream_tests/Makefile -tests/nonsmoke/functional/CompileTests/boost_tests/Makefile tests/nonsmoke/functional/CompileTests/colorAST_tests/Makefile tests/nonsmoke/functional/CompileTests/copyAST_tests/Makefile tests/nonsmoke/functional/CompileTests/frontend_integration/Makefile @@ -1384,7 +1368,6 @@ tests/smoke/specimens/Makefile tests/smoke/specimens/c++/Makefile tests/smoke/specimens/c/Makefile tests/smoke/specimens/fortran/Makefile -tests/smoke/unit/Boost/Makefile tests/smoke/unit/Makefile tests/smoke/unit/Utility/Makefile tools/Makefile diff --git a/config/support-summary.m4 b/config/support-summary.m4 index e844a4a1306..f2efd2486cd 100644 --- a/config/support-summary.m4 +++ b/config/support-summary.m4 @@ -58,29 +58,6 @@ ROSE_COMPILER_FEATURES([fortran], [$FC $FCLAGS], [HOST_FC_]) echo " Fortran ${support_fortran_frontend:-no}" echo " OpenCL ${support_opencl_frontend:-no}" - #-------------------------------------------------------------------------------- - ROSE_SUMMARY_HEADING([Boost library]) - echo " location ${ac_boost_path:-unknown}" - echo " version constant ${rose_boost_version:-unknown}" - echo " asio library ${BOOST_ASIO_LIB:-none}" - echo " atomic library ${BOOST_ATOMIC_LIB:-none}" - echo " chrono library ${BOOST_CHRONO_LIB:-none}" - echo " date/time library ${BOOST_DATE_TIME_LIB:-none}" - echo " filesystem library ${BOOST_FILESYSTEM_LIB:-none}" - echo " iostreams library ${BOOST_IOSTREAMS_LIB:-none}" - echo " program options library ${BOOST_PROGRAM_OPTIONS_LIB:-none}" - echo " python library ${BOOST_PYTHON_LIB:-none}" - echo " random library ${BOOST_RANDOM_LIB:-none}" - echo " regex library ${BOOST_REGEX_LIB:-none}" - echo " serialization library ${BOOST_SERIALIZATION_LIB:-none}" - echo " signals library ${BOOST_SIGNALS_LIB:-none}" - echo " system library ${BOOST_SYSTEM_LIB:-none}" - echo " test exec monitor library ${BOOST_TEST_EXEC_MONITOR_LIB:-none}" - echo " thread library ${BOOST_THREAD_LIB:-none}" - echo " unit test framework library ${BOOST_UNIT_TEST_FRAMEWORK_LIB:-none}" - echo " wave library ${BOOST_WAVE_LIB:-none}" - echo " wserialization library ${BOOST_WSERIALIZATION_LIB:-none}" - #-------------------------------------------------------------------------------- if test -n "$support_cxx_frontend" -o -n "$verbose"; then ROSE_SUMMARY_HEADING([C/C++ analysis support]) diff --git a/configure.ac b/configure.ac index 765bbe83ea0..39dd67585fc 100644 --- a/configure.ac +++ b/configure.ac @@ -143,7 +143,6 @@ ROSE_SUPPORT_ROSE_PART_6 ROSE_SUPPORT_ROSE_PART_7 dnl Fail gracefully for blacklisted dependencies and other situations -ROSE_SUPPORT_BLACKLIST ROSE_SUPPORT_SUMMARY dnl Now generate all the output files (specified above) diff --git a/docs/CMakeLists.txt b/docs/CMakeLists.txt index f68f0994b4c..fd85a65dcfa 100644 --- a/docs/CMakeLists.txt +++ b/docs/CMakeLists.txt @@ -1,38 +1,6 @@ -include_directories(${KDE4_INCLUDES} ${KDE4_INCLUDE_DIR} ${QT_INCLUDES} ) - add_subdirectory(Rose) +# add_subdirectory(Rosetta) +# add_subdirectory(testDoxygen) -message(STATUS "${CMAKE_CURRENT_SOURCE_DIR}: skipped subdir $(DEVELOPER_DISTRIBUTION_DIRECTORY)") - -########### install files ############### - - - - -#original Makefile.am contents follow: - -# -## DQ (7/24/2008): Only the developer version needs the test directory specific to Doxygen support -## JJW (8/3/2008): This line will be removed in binary distributions -#DEVELOPER_DISTRIBUTION_DIRECTORY = testDoxygen -# -## Later we will add ROSETTA documentation here ... -## SUBDIRS = Rose Rosetta testDoxygen -# -## DQ (9/11/2006): Removed Rosetta directory, an internal tool not documented -## within ROSE for use externally. -## SUBDIRS = Rose Rosetta testDoxygen -## SUBDIRS = Rose testDoxygen -#SUBDIRS = Rose $(DEVELOPER_DISTRIBUTION_DIRECTORY) -# -## New rule to simplify generation of documentation (we want to avoid using the -## automake generated "docs" rule because the generation of documentation is -## dependent upon separate tools which the user might not have available -## (true for bothe the LaTeX and html documentation). -## documentation: -#docs: -# @echo " Generate all possible documentation cd Rose; make documentation;" -# @cd Rose; $(MAKE) docs; -# -#EXTRA_DIST = +message(STATUS "${CMAKE_CURRENT_SOURCE_DIR}: skipped subdir Rosetta and testDoxygen") \ No newline at end of file diff --git a/docs/Makefile.am b/docs/Makefile.am index 29f9f33aaaa..6f005587b37 100644 --- a/docs/Makefile.am +++ b/docs/Makefile.am @@ -1,22 +1,7 @@ - -# DQ (7/24/2008): Only the developer version needs the test directory specific to Doxygen support -# JJW (8/3/2008): This line will be removed in binary distributions -DEVELOPER_DISTRIBUTION_DIRECTORY = testDoxygen - -# Later we will add ROSETTA documentation here ... -# SUBDIRS = Rose Rosetta testDoxygen - -# DQ (9/11/2006): Removed Rosetta directory, an internal tool not documented -# within ROSE for use externally. # SUBDIRS = Rose Rosetta testDoxygen # SUBDIRS = Rose testDoxygen -SUBDIRS = Rose $(DEVELOPER_DISTRIBUTION_DIRECTORY) +SUBDIRS = Rose -# New rule to simplify generation of documentation (we want to avoid using the -# automake generated "docs" rule because the generation of documentation is -# dependent upon separate tools which the user might not have available -# (true for bothe the LaTeX and html documentation). -# documentation: docs: @echo " Generate all possible documentation cd Rose; make documentation;" @cd Rose; $(MAKE) docs; diff --git a/docs/Rose/BinaryTutorial.dox b/docs/Rose/BinaryTutorial.dox deleted file mode 100644 index 55f36a6cf9f..00000000000 --- a/docs/Rose/BinaryTutorial.dox +++ /dev/null @@ -1,434 +0,0 @@ -// -*- c++ -*- - -namespace Rose { -namespace BinaryAnalysis { - -/** @page binary_tutorial Binary analysis tutorial - * - * Getting started guide for binary analysis. - * - * @section bintut_why Why binary analysis? - * - * ROSE was originally designed as a source-to-source analysis and transformation system, but it turns out that parsing and - * analyzing a binary specimen shares many of the same basic ideas: - * - * @li A binary specimen usually lives in a container that describes areas of memory, symbols, and other things needed when - * the specimen is executed or linked. These various containers (executables, libraries, object files, core dumps) can be - * parsed by a ROSE frontend and result in an abstract syntax tree (AST) much like parsing of source code. - * - * @li The machine instructions of a binary specimen can be parsed an have semantics similar to statements in a source - * language. They also result in abstract syntax trees. - * - * @li Data areas in the specimen can be parsed and are similar to initialized data in a source language. These also become - * abstract syntax trees. - * - * @li %Analysis can be performed on an intermediate representation (IR) for both binaries and source code. One such - * intermediate representation is the abstract syntax tree. - * - * @li Transformations modify the AST and the resulting AST can be "unparsed" to create a new binary specimen, much like - * unparsing transformed source code results in a new implementation. - * - * Of course there are also many differences between source code and binary specimens, but ROSE is situated in the unique - * position of being able to process both. On the one hand, it can operate on a specimen for which no source code is - * available, and on the other it can perform analysis and transformations where both source and binary are available at - * once. - * - * - * - * - * @section bintut_features What binary analysis features are available? - * - * ROSE can parse a variety of binary inputs. It can parse executable formats such as Linux ELF executables, shared libraries, - * core dumps, object files, and library archives; and Microsoft Windows PE and DOS executables and libraries. It can parse - * memory initialization formats such as Motorola S-Records, Intel HEX files, and raw memory dumps. It can analyze running or - * paused programs on Linux. ROSE can also analyze combinations of these formats&emdash;such as an ELF file extended by - * providing additional initialized memory from an S-Record file&emdash;and has a mini command-line language for specifying - * this for all binary analysis tools. - * - * The ROSE disassembler uses a hybrid linear sweep and recursive descent approach that handles things like overlapping - * instructions (on architectures where that's possible), interleaved functions, rewritten execution flow, and more. ROSE has - * instruction decoders for ARM, AMD64 (x86_64), Intel x86, MIPS, Motorola 68k, and PowerPC (32- and 64-bit). ROSE is designed - * so that most analysis is architecture independent. - * - * ROSE understands semantics for common subsets of AMD64, Intel x86, Motorola 68k, and PowerPC (32- and 64-bit) and can - * therefore reason about how execution of instructions affects a machine's state. It can perform this reasoning symbolically, - * using only concrete values, using sets of intervals of concrete values, and many more special-purpose domains. If an - * Satisfiability Modulo Theory (SMT) solver is available, ROSE can use it to increase the fidelity of its analyses, including - * reasoning that's employed during the disassembly phase. - * - * ROSE is able to construct control flow graphs and call graphs and has a number of pre-built analysis capabilities such as - * tainted flow analysis, edit distances, code statistics, memory maps, reasoning about register interactions, address usage - * maps, execution paths and their feasibility, generic inlining and interprocedural data-flow, no-op sequence detection, - * opaque predicate detection, algorithmic CFG rewriting, calling convention detection, function may-return analysis, address - * labeling passes, thunk detection and manipulating, switch statement analysis, interrupt vector processing, overlapping - * instructions, cross referencing, function stack delta analysis, register and memory usage analysis, magic numbers, static - * and dynamic string decoding, control flow dominance, pointer detection, DWARF parsing, library identification, etc. - * - * %Analysis results are available in a number of formats, depending on the analysis: through various APIs, decoration of the - * abstract syntax tree or control flow graph, commentary in assembly listings, databases, or to a certain extent as a new - * translated binary specimen. - * - * This document only attempts to describe a few of the easiest features to get you started. - * - * - * - * - * @section bintut_config Installing and confguring ROSE for binary analysis - * - * The binary analysis features have a large number of software dependencies beyond what the source-to-source side of ROSE - * uses, but fortunately all of them are optional. If a software dependency is not available then the analysis that uses it - * is simply not available. In a few cases cases the analysis can use a different dependency or a slower or less accurate - * implementation. See @ref installation for instructions on how to install ROSE. ROSE must be configured with "binaries" - * being one of the "--enable-languages" values. - * - * - * - * - * @section bintut_helloworld Hello, World! - * - * Every system needs a basic "Hello, World!" example, so here's that example for binary analysis within the ROSE - * framework. It parses a specimen from a variety of formats (see its "--help" output), then disassembles the instructions - * optionally using instruction semantics to help drive the disassembly, then partitions the instructions into functional - * units, and finally displays an assembly listing. - * - * @snippet binaryHelloWorld.C rose include - * - * All programs start by including the main ROSE include file that declares most things that are common to source and binary - * analysis. This must be the first ROSE header to be included. - * - * @snippet binaryHelloWorld.C other includes - * - * ROSE's binary components are declared in individual header files that can only be included after including "rose.h". The - * binary headers themselves can be included in any order (after rose.h) since each header includes those other headers on - * which it depends. The binary analysis headers usually have the same names as the primary class they contain. - * - * @snippet binaryHelloWorld.C commandline - * - * The binary analysis uses a different command-line processor than most of the rest of ROSE because the command-line options - * for these tools don't typically interact with a compiler and therefore don't need to parse the host of compiler switches - * that the source tools need to recognize. This also frees the binary tool's command-line parser to be able to generate Unix - * man pages on the fly. For instance, if you invoke this tool with "--help" (or just "-h") you should see quite lengthy - * documentation about how to invoke the tool and what all its switches mean. A tool more advanced than "Hello, World!" can - * modify the command-line parser. - * - * @snippet binaryHelloWorld.C disassembly - * - * ROSE divides disassembly into two phases. Within ROSE, a @ref Disassembler is responsible for parsing the bytes of a single - * machine instruction and turning them into an abstract syntax tree, while the @ref Partitioner2 namespace contains the - * machinery for driving disassembly. The partitioner partitions the specimen's memory image into parts that are either - * instructions or data (actually, "partitioner" is a bit of a misnomer since instructions and data can also overlap, although - * they seldom do in practice). - * - * The Partitioner2 namespace contains many classes, but @ref Partitioner2::Engine "Engine" and @ref Partitioner2::Partitioner - * "Partitioner" are the two most important classes. The @ref Partitioner2::Engine "Engine" is used to drive the disassembly - * process and create a @ref Partitioner2::Partitioner "Partitioner", which holds the results in data structures that have - * better time complexities than an AST when it comes to most forms of analysis. In this example, we are invoking the @ref - * Partitioner2::Engine::frontend "Engine::frontend", which is similar in nature to ROSE's global @ref ::frontend in that it - * does everything necessary to make ROSE ready to do analysis: it parses, loads, disassembles, partitions, runs basic - * analysis, and checks consistency. In the end, it returns an abstract syntax tree (AST) instead of a @ref - * Partitioner2::Partitioner "Partitioner". - * - * AST nodes in ROSE all begin with the letters "Sg" (from "Sage"). Those nodes that are specific to binary analysis begin - * with "SgAsm" (from "Sage assembly"). Within source code analysis, source files combine to form a single @ref SgProject - * node, and the same is often true with binary analysis also. For specimens that have a container, like Linux ELF and - * Windows PE files, the AST has two large subtrees: one subtree describes the containers (there may be more than one), and - * another subtree describes the instructions organized into interpretation subtrees (@ref SgAsmInterpretation). - * Interpretations organize instructions into coherent sets, such as the PE32 and DOS subcomponents of a Windows PE - * file. However not all specimen formats have containers, in which case the AST is abbreviated and contains only the - * instructions rooted at a "global block" (SgAsmBlock). - * - * @snippet binaryHelloWorld.C unparsing - * - * Now that an abstract syntax tree has been created we can "unparse" it. Unparsing in a binary is slightly different - * than unparsing source code. Binary specimens are usually not transformed like source code, so the unparser for a binary - * generates a human-readable pseudo-assembly listing instead. We could have also called the global @ref ::backend (same as - * source code) which would have produced a number of output files including a new executable, but backend only works on - * SgProject nodes which might not be present (see above). Note that there are better ways to obtain an unparser, and we'll - * see them later. - * - * Here's the entire "Hello, World!" program: - * - * @includelineno binaryHelloWorld.C - * - * - * - * @section bintut_compile Compiling programs that use ROSE - * - * To compile this program you'll want to use the same compiler, preprocessor switches, compiler switches, and loader switches - * as are used when compiling ROSE. This is important! Since C++ has no official, documented application binary interface, - * mixing libraries compiled with different compilers, compiler versions, compiler optimization levels, or even other - * seemingly benign compiler switches is not guaranteed to work. The easiest way to compile the above example is to change - * directories to $ROSE_BUILD/tutorial, where $ROSE_BUILD is the top of your build tree, and run make - * binaryHelloWorld. Similar commands will work for the other examples in this tutorial. - * - * On the other hand, if you've already installed the ROSE library and blown away your build tree, or if you're writing your - * own programs that use ROSE, you won't be able to leverage ROSE's own build system to compile your program, and you probably - * have no idea what compiler command was used to compile ROSE. Fear not, ROSE installed a "rose-config.cfg" file that has the - * information you need, and in a format that can be included directly into GNU make files. See @ref tooldev for an example - * Makefile. - * - * - * - * @section bintut_fcfg Generating a function control flow graph. - * - * This example shows how to load a specimen into analysis space and generate a control flow graph for each function. First we - * include @c rose.h and then any additional binary analysis header files: - * - * @snippet binaryFunctionCfg.C prologue - * - * Then, in the @c main program, we create a disassembling and partitioning engine and use it to parse the command-line. This - * allows our tool to easily support the multitude of partitioner settings and container formats. The command-line parser and - * its documentation is easily customizable for more advanced tools, but the following works fine for this tool: - * - * @snippet binaryFunctionCfg.C setup - * - * The "mlog[FATAL]" in the previous code uses ROSE's diagnostics facility, a large set of coordinated streams for different - * software components and message severity levels, all of which can be controlled from the command-line. - * - * Next, now that the engine is configured and we know the name(s) or resources for the specimen, we can parse the specimen - * container, load the specimen into memory, disassemble, and discover functions. The results are stored in a @ref - * Partitioner2::Partitioner "Partitioner" object: - * - * @snippet binaryFunctionCfg.C partition - * - * Finally, we'll iterate over those functions to create function control flow graphs and print each graph. The @ref - * Partitioner2::Partitioner::cfg "cfg" method returns a const reference to a global control flow graph, which normally serves - * as the starting point for many analyses. But in this case, we want only the subgraph that represents an individual - * function, so we copy the global CFG and then remove those vertices and edges that are uninteresting: - * - * @snippet binaryFunctionCfg.C function cfg - * - * In the above code, the @ref Partitioner2::ControlFlowGraph is a specialization of @ref Sawyer::Graph, which is a generic - * yet easy-to-use graph implementation with very good time complexity for most operations. So the previous "for" loop has - * linear time complexity with respect to the total number of vertices and edges. - * - * The @ref Partitioner2::DataFlow namespace has a @ref Partitioner2::DataFlow::buildDfCfg "buldDfCfg" function that creates a - * slightly different kind of control flow graph--one that's more useful for data-flow--which also permits intra- and - * inter-procedural analysis based on user criteria. - * - * Here's the entire program: - * - * @includelineno binaryFunctionCfg.C - * - * - * - * @section bintut_cg Generating a binary function call graph in GraphViz format. - * - * This example is similar to the @ref bintut_helloworld example, but demonstrates how to analyze function call information to - * construct a function call graph (CG) and then emit that graph as a GraphViz file. The output can be converted to a picture - * with the "dot" command, or visualized interactively with ZGRViewer. - * - * @snippet binaryCallGraph.C headers - * - * As before, the "rose.h" header is the first of the ROSE headers to be included, followed by the binary analysis headers in - * any order. - * - * @snippet binaryCallGraph.C namespaces - * - * This time we'll use a few namespaces to reduce our typing. The @ref Rose::Diagnostics namespace brings into scope the - * diagnostic support (@c mlog and @c FATAL in this example) which is accessed through the "--log" command-line switches and - * controls what kinds of diagnostic output is produced. If you run this program with "--log=all" you'll get traces and - * debugging from all the ROSE components that use this mechanism (lots of output); see "--log=help" for info about fine - * tuning this. - * - * @snippet binaryCallGraph.C settings - * - * Many of the binary analysis tools find that holding all command-line settings in a single struct is a convenient way to - * organize things. This example only has one tool-specific setting--the name of the output file for the call graph. - * - * @snippet binaryCallGraph.C commandline - * - * The @ref bintut_helloworld example showed the simplest way to parse a command-line, but this time we'll do something a - * little more complex. This time we want to augment the command-line parser so it knows about the switches that this tool - * supports. The parser itself comes from the [Sawyer](https://github.com/matzke1/sawyer) library, part of which is - * distributed along with the ROSE source code. We obtain the default parser from the disassembly and partitioning engine, - * and augment it with a switch group containing the switches specific to this tool. Our "--output" or "-O" switch takes a - * single argument, a file name that can be any string. The "doc" property is the documentation for our switch and will - * appear in the Unix man page produced by running with "--help". Finally, we invoke the parser with our additional switch - * group on the argument list in @c argv. If the parsing is successful we apply the results to our @c settings and then return - * the rest of the command line (probably information about the specimen). - * - * @snippet binaryCallGraph.C setup - * - * In the @p main program we initialize our @p settings and instantiate a disassembly/partitioning engine, then parse the - * command-line and get the list of non-switch arguments. If there are none, give the user some help; this is often an - * indication that the user invoked the command with no arguments at all in order to get an error message that hopefully - * contains some usage hints. - * - * @snippet binaryCallGraph.C partition - * - * Instead of calling @ref Partitioner2::Engine::frontend "engine.frontend", this time we call @ref - * Partitioner2::Engine::partition "engine.partition" in order to get access to the partitioning analysis results. No AST is - * created in this case, although we could get one if we wanted by querying the engine for it. The data structures used by - * the partitioner are much more efficiently tuned for analysis than an AST, so we'll stick with the partitioner. - * - * @snippet binaryCallGraph.C callgraph - * - * The partitioner knows how to construct a call graph from its internal data structures. The @ref - * Partitioner2::FunctionCallGraph "FunctionCallGraph" class can also be manipulated directly. Now's a good time to point out - * that many binary analysis data structures use pointers to shared objects. The objects are reference counted and deleted - * automatically. Classes that are used in this way do not have public constructors, but rather @c instance methods (and - * sometimes additional factories as well) that allocate and initialize the object and return a smart pointer. In this - * example, if we were to delete the @c partitioner or @c engine the @c callgraph would still point to valid functions, which - * still point to valid instructions, etc. - * - * @snippet binaryCallGraph.C emit - * - * Finally we can emit the call graph as a GraphViz file. This is done through a @ref Partitioner2::GraphViz::CgEmitter - * "CgEmitter" that specializes a more general GraphViz emitter. The emitter API allows you to fine tune the output by - * adjusting colors and other GraphViz edge and vertex properties. - * - * Here's the full listing. Compile it using the same instructions as for the @ref bintut_helloworld example. - * - * @includelineno binaryCallGraph.C - * - * - * - * - * @section bintut_strings Finding static strings in a binary specimen - * - * This example parses and disassembles a binary specimen and search for all static strings, similar to the Unix "strings" - * command. This simple example can be a starting point for a more in depth strings analysis than what's possible with the - * Unix command. - * - * @snippet binaryStrings.C headers - * - * Include headers. The "rose.h" must always be before other ROSE headers. - * - * @snippet binaryStrings.C commandline - * - * Yet another way to parse a command-line. This time we're trying to avoid calling @ref Partitioner2::Engine::frontend - * because we don't actually need to disassemble or partition anything--string searching operates on raw memory rather than - * instructions, so we can save some time. - * - * @snippet binaryStrings.C load - * - * The @ref Partitioner2::Engine::loadSpecimens "engine.loadSpecimens" method parses the speicmen container if present (e.g., - * Linux ELF) and determines how the specimen should be mapped into memory. The result is a @ref MemoryMap that describes - * memory segments with addresses, permissions, names, etc. Try inserting a call to @ref MemoryMap::dump here to get an - * idea of what it contains. - * - * The byte order will be needed by the string decoder in order to know how to decode the multi-byte length fields. We could - * have gotten this same information any number of other ways, but this is the most convenient in this situation. Note that - * knowledge of the byte order depends upon knowledge of the specimen architecture even though we don't actually need to - * disassemble anything. - * - * @snippet binaryStrings.C analysis - * - * Here we perform the string searching. Most binary analysis algorithms are packaged into a class. The idea is that one - * instantiates the analyzer, configures it, calls some method to perform the analysis (here it's @ref - * Strings::StringFinder::find "find"), and then queries the results. - * - * The @ref MemoryMap::require and @ref MemoryMap::prohibit methods are a form of filtering. They're filtering the memory - * map so that the string analyzer only sees memory that's readable but not writable. - * - * @snippet binaryStrings.C output - * - * Generating the output is a matter of iterating over the strings that were found and printing some information. Most - * analyzer objects also know how to print themselves although those defaults are not always suitable for a polished tool. - * - * Here's the entire program: - * - * @includelineno binaryStrings.C - * - * - * - * @section bintut_dominators Graph dominators and post dominators - * - * Loosely speaking, the dominator of a vertex of a graph is another vertex that's visited on every path from some - * starting vertex to the vertex in question. Most of the time, we're interested in an immediate dominator, which is the - * closest dominator to the vertex in question. A more rigorous definition can be found in Wikipedia, among other places. - * Post-dominators are similar in that a post dominator of a vertex is some other vertex that's visited on every path from the - * vertex in question to some ending vertex. - * - * ROSE uses the @ref Sawyer::Container::Graph "Sawyer Graph API" for all binary analysis graphs, and Sawyer has functions for - * calculating dominators and post-dominators. The following example is a tool that finds the dominator for each vertex in the - * control flow graph of each function. - * - * @snippet binaryDominance.C headers - * - * The first step, above, is to include the appropriate declarations. Our convention for writing tools is to describe the tool - * with a couple of strings that appear at the very top of the source code. These strings are used later in the program to - * generate the documentation for the "--help" output. - * - * This tool is so simple that everything else is in "main". First we initialize things: - * - * @snippet binaryDominance.C init - * - * The @ref Rose::initialize "ROSE_INITIALIZE" macro is always the first ROSE-related statement and checks that this tool was - * compiled with header files that are binary compatible with the ROSE library. Then we create a partitioning engine to parse - * the command-line to get the specimen resources. The specimen is some combination of a ELF or PE file name, raw memory - * dumps, S-Records, and/or process IDs. The @ref Rose::BinaryAnalysis::Partitioner2::Engine::partition "engine.partition" - * call does all the hard work of parsing containers, loading data into the virtual address space, decoding CPU instructions, - * and creating basic blocks and functions. It returns a @ref Rose::BinaryAnalysis::Partitioner2::Partitioner "partitioner" - * object that stores all the results, which include a global control flow graph. - * - * Then we iterate over the functions: - * - * @snippet binaryDominance.C iterate - * - * We want to create a function CFG, but all we have from the partitioner is a global CFG. We can use the fact that a function - * CFG is a subset of the global CFG and therefore create the function CFG by copying the global CFG and removing all vertices - * and edges that are not part of the function CFG. Although this isn't the most efficient way to create function CFGs in a - * loop over all functions, it is very simple. - * - * We'll need to know the entry vertex of the function's CFG: - * - * @snippet binaryDominance.C cfg_enter - * - * We found the entry vertex in the function CFG by first finding it in the global CFG and then using a feature of Sawyer - * graphs, namely, when a graph is copied its vertices and edges have the same IDs as those in the source graph, and we can - * obtain a vertex pointer (iterator) in constant time if we know its ID. We have to convert the ID to a vertex pointer - * before removing the non-function vertices because IDs are not stable across erase operations, but iterators are. - * - * Next we erase the non-function vertices and edges: - * - * @snippet binaryDominance.C cfg_build - * - * This is the simple way to build a function CFG from a global CFG. It's important to use a post-increment in the - * @c eraseVertex call. Since we're inside a loop iterating over every function, a more efficient implementation would have - * created all the function CFGs in a single pass over the global CFG. As of June 2017, ROSE does not have functions for - * returning function CFGs -- it only has a global CFG -- because there are many details that need to be considered depending - * on the situation (e.g., function calls and returns are two cases that typically need massaging in a function CFG depending - * on the purpose of the CFG). - * - * Finally, we get to the real meat of this example: finding the immediate dominator for every vertex in the function CFG - * given the CFG's entry vertex: - * - * @snippet binaryDominance.C dominators - * - * The @ref Sawyer::Container::Algorithm::graphDominators "graphDominators" function can handle any type of Sawyer graph, thus - * we could also pass a function call graph or a data-flow graph. - * - * The return value is a vector indexed by vertex ID, whose values point to either the corresponding immediate dominator or - * the vertex end iterator (not all vertices have an immediate dominator). Using a vector indexed by vertex ID is an idiom - * used throughout ROSE whenever we need to associated extra data with an existing graph. Since a vertex pointer (iterator) - * can be converted to a vertex ID in constant time, and indexing into the vector is constant time, we can always find the - * extra data in constant time. And since vertex IDs are consecutive integers beginning at zero, this is also a - * space-efficient way to represent data that's present for most, if not all, vertices. - * - * Finally, let us iterate over the results to print them: - * - * @snippet binaryDominance.C results - * - * Since vector indexes are equivalent to vertex IDs, we can obtain a vertex with a constant-time @c findVertex call and a - * constant-time iterator dereference. Since this is a CFG from the partitioner (or at least a copy thereof), we can use the - * @ref Rose::BinaryAnalysis::Partitioner2::Partitioner::vertexName "vertexName" static method to print some info about - * it. Using the static method (that takes a vertex value) is important; the non-static method (that takes a vertex iterator) - * will think that we're handing it a pointer to some vertex in the partitioner's own global CFG. - * - * Here's the entire program: - * - * @includelineno binaryDominance.C - * - * - * - * @section bintut_next Next steps - * - * Most binary analysis capabilities are documented in the @ref Rose::BinaryAnalysis namespace. The test directory, - * "$ROSE_SOURCE/tests/nonsmoke/functional/roseTests/BinaryTests", also has many examples, some of which are slightly hard to read since there - * main purpose is to test rather than demonstrate. The "$ROSE_SOURCE/projects/BinaryAnalysisTools" directory (as well as - * some other project directories) has real programs that use the binary analysis interface. */ - -} // namespace -} // namespace diff --git a/docs/Rose/CMakeLists.txt b/docs/Rose/CMakeLists.txt index 4e1187b6acc..232a9b0d462 100644 --- a/docs/Rose/CMakeLists.txt +++ b/docs/Rose/CMakeLists.txt @@ -1,4 +1,4 @@ -include_directories(${KDE4_INCLUDES} ${KDE4_INCLUDE_DIR} ${QT_INCLUDES} ) +# include_directories() add_subdirectory(Tutorial) diff --git a/docs/Rose/Makefile.am b/docs/Rose/Makefile.am index daa7f8bd303..081eba13b65 100644 --- a/docs/Rose/Makefile.am +++ b/docs/Rose/Makefile.am @@ -192,17 +192,11 @@ make-web-pages: $(RoseDoxygenDocumentation) $(PACKAGE_NAME)-$(PACKAGE_VERSION)-U cp -f footer.html ROSE_WebPages/footer.html cp -f $(srcdir)/rose.html ROSE_WebPages/rose.html cp -f $(srcdir)/rose.html ROSE_WebPages/index.html - cp -f $(srcdir)/projects.html ROSE_WebPages/projects.html cp -f $(srcdir)/FAQ.html ROSE_WebPages/FAQ.html cp -f $(srcdir)/documents.html ROSE_WebPages/documents.html cp -f $(srcdir)/highlights.html ROSE_WebPages/highlights.html cp -f $(srcdir)/news.html ROSE_WebPages/news.html cp -f $(srcdir)/regressionTest.html ROSE_WebPages/regressionTest.html - cp -f $(COMPASS_MANUAL) ROSE_WebPages/ - cp -f $(AUTOTUNING_MANUAL) ROSE_WebPages/ - cp -f $(QROSE_MANUAL) ROSE_WebPages/ -# mkdir -p ROSE_WebPages/ROSE_HaskellAPI -# cp -fr $(HASKELLPORT_APIDOCS)/* ROSE_WebPages/ROSE_HaskellAPI/ cp -fr $(srcdir)/powerpoints ROSE_WebPages/ cp -f ROSE_InstallationInstructions.pdf ROSE_WebPages/ROSE_InstallationInstructions.pdf cp -f ROSE_Exam.pdf ROSE_WebPages/ROSE_Exam.pdf @@ -217,12 +211,7 @@ make-web-pages: $(RoseDoxygenDocumentation) $(PACKAGE_NAME)-$(PACKAGE_VERSION)-U # Upload web pages to the LBL server copyWebPages: make-web-pages -# Liao 5/6/2010 migrate to the new web server -# Liao, 7/13/2009, must ensure the file permissions here -# Liao, 12/8/2010, use dedicated data transferring node dtn01 cd ROSE_WebPages; chmod -R a+rx *; rsync -avz * liaoch@dtn01.nersc.gov:/project/projectdirs/rosecompiler/www.rosecompiler.org -# cd ROSE_WebPages; chmod -R a+rx *; rsync -avz * liaoch@portal-auth.nersc.gov:/project/projectdirs/rosecompiler/www.rosecompiler.org -# cd ROSE_WebPages; chmod -R a+rx *; rsync -avz * liaoch@web-dev.nersc.gov:/www/host/rosecompiler # scp $(PACKAGE_NAME)-$(PACKAGE_VERSION)-HTML-Docs.tar.gz quinlan1@cmg-1.llnl.gov:/green_dev/www/casc/rose # Liao 12/7/2009, we mirror the content of the internal diff --git a/docs/Rose/Tutorial/CMakeLists.txt b/docs/Rose/Tutorial/CMakeLists.txt index 9fd4aa54267..7936f8ffdf9 100644 --- a/docs/Rose/Tutorial/CMakeLists.txt +++ b/docs/Rose/Tutorial/CMakeLists.txt @@ -23,14 +23,14 @@ include_directories(${KDE4_INCLUDES} ${KDE4_INCLUDE_DIR} ${QT_INCLUDES} ) # templateParameter.tex instrumentationExample.tex addVariableDeclaration.tex \ # addAssignmentStmt.tex addExpression.tex\ # addFunctionDeclaration.tex buildCFG.tex parallelChecker.tex defuseAnalysis.tex \ -# binaryAnalysis.tex buildCallGraph.tex classHierarchyGraph.tex loopOptimization.tex inliner.tex outliner.tex \ +# buildCallGraph.tex classHierarchyGraph.tex loopOptimization.tex inliner.tex outliner.tex \ # parser-docs.tex codeCoverage.tex globalVariableHandling.tex scopeInformation.tex sideeffect-docs.tex \ # tauInstrumentation.tex templateSupport.tex dataBaseSupport.tex recognitionOfAbstractions.tex \ # debuggingSupport.tex commandlineProcessing.tex customGraphs.tex tutorialMakefile.tex wrapup.tex \ # appendix.tex astFileIO.tex uniqueNames.tex wholeGraphAST.tex addingComments.tex \ # partialRedundancyElimination.tex codeGenerationFormatControl.tex copyHelp.tex \ # roseHPCT.tex sharedMemoryTraversals.tex distributedMemoryTraversals.tex bugSeeding.tex \ -# modifiers.tex howToContribute.tex virtualCFG.tex binaryConstruction.tex reductionRecognition.tex \ +# modifiers.tex howToContribute.tex virtualCFG.tex reductionRecognition.tex \ # haskell.tex # ## This is an evolving list, but these are a few of the required files diff --git a/docs/Rose/Tutorial/Makefile.am b/docs/Rose/Tutorial/Makefile.am index 8241c103387..b1120147484 100644 --- a/docs/Rose/Tutorial/Makefile.am +++ b/docs/Rose/Tutorial/Makefile.am @@ -11,14 +11,14 @@ latexFiles = \ traversal.tex loopRecognition.tex typeInfoFromFunctionParameters.tex resolveOverloadedFunction.tex \ templateParameter.tex \ buildCFG.tex parallelChecker.tex defuseAnalysis.tex \ - binaryAnalysis.tex GenericDFA.tex buildCallGraph.tex buildVFA.tex classHierarchyGraph.tex loopOptimization.tex inliner.tex outliner.tex \ + GenericDFA.tex buildCallGraph.tex buildVFA.tex classHierarchyGraph.tex loopOptimization.tex inliner.tex outliner.tex \ parser-docs.tex codeCoverage.tex scopeInformation.tex sideeffect-docs.tex \ tauInstrumentation.tex templateSupport.tex dataBaseSupport.tex recognitionOfAbstractions.tex \ debuggingSupport.tex commandlineProcessing.tex customGraphs.tex tutorialMakefile.tex wrapup.tex \ appendix.tex astFileIO.tex uniqueNames.tex wholeGraphAST.tex addingComments.tex \ partialRedundancyElimination.tex codeGenerationFormatControl.tex copyHelp.tex \ - roseHPCT.tex sharedMemoryTraversals.tex distributedMemoryTraversals.tex bugSeeding.tex \ - modifiers.tex howToContribute.tex virtualCFG.tex binaryConstruction.tex reductionRecognition.tex \ + sharedMemoryTraversals.tex distributedMemoryTraversals.tex bugSeeding.tex \ + modifiers.tex howToContribute.tex virtualCFG.tex reductionRecognition.tex \ livenessAnalysis.tex CFGTraversalTutorial.tex parserBuildingBlocks.tex astConstruction.tex # This is an evolving list, but these are a few of the required files @@ -35,7 +35,6 @@ generatedCodeExamples = \ $(top_builddir)/tutorial/codeCoverage.out \ $(top_builddir)/tutorial/vcfg.pdf \ $(top_builddir)/tutorial/rose_inputCode_inlineTransformations.C \ - $(top_builddir)/tutorial/roseHPCT/profiled.out \ $(top_builddir)/tutorial/sourceTraversalTutorial.C \ $(top_builddir)/tutorial/binaryTraversalTutorial.C diff --git a/docs/Rose/Tutorial/binaryAnalysis.tex b/docs/Rose/Tutorial/binaryAnalysis.tex deleted file mode 100644 index b213187a0f0..00000000000 --- a/docs/Rose/Tutorial/binaryAnalysis.tex +++ /dev/null @@ -1,347 +0,0 @@ -\chapter{Binary Analysis} - -% This tutorial has been replaced by a doxygen version. - -See doxgyen ``Getting started with binary analysis'' chapter. - -\section{DataFlow Analysis} - -%\begin{figure} -%%\centerline{\epsfig{file=\TutorialExampleBuildDirectory/controlFlowGraph.ps, -%% height=1.3\linewidth,width=1.0\linewidth,angle=0}} -%\includegraphics[scale=0.7]{\TutorialExampleBuildDirectory/binaryAnalysis_pic2} -%\caption{Dataflowflow graph for example program.} -%\label{Tutorial:examplefig2} -%\end{figure} - -Based on the control flow many forms of dataflow analysis may be performed. -Dataflow analyses available are: - -\subsection{Def-Use Analysis} - -Definition-Usage is one way to compute dataflow information about a binary program. - -\subsection{Variable Analysis} - -This analysis helps to detect different types within a binary. -Currently, we use this analysis to detect interrupt calls and their parameters together with the def-use analysis. -This allows us to track back the value of parameters to the calls, such as eax and therefore -determine whether a interrupt call is for instance a write or read. -Another feature is the buffer overflow analysis. By traversing the CFG, we can detect buffer overflows. - - -\section{Dynamic Analysis} - - ROSE has support for dynamic analysis and for mixing of dynamic -and static analysis using the Intel Pin framework. This optional support in ROSE -requires a configure option ({\tt --with-IntelPin=$}). The {\tt path} in -the configure option is the {\bf absolute path} to the top level directory of the location of -the Intel Pin distribution. This support for Intel Pin has only been tested -on a 64bit Linux system using the most recent distribution of Intel Pin (version 2.6). - -Note: The dwarf support in ROSE is currently incompatable with the dwarf support in -Intel Pin. A message in the configuration of ROSE will detect if both support for -Dwarf and Intel Pin are both specified and exit with an error message that they -are incompatable options. - -See {\tt tutorial/intelPin} directory for examples using static and dynamic analysis. -These example will be improved in the future, at the moment they just call the -generation of the binary AST. - - -Note: We have added a fix to Intel Pin pin.H file: -\begin{verbatim} -// DQ (3/9/2009): Avoid letting "using" declarations into header files. -#ifndef REQUIRE_PIN_TO_USE_NAMESPACES -using namespace LEVEL_PINCLIENT; -#endif -\end{verbatim} -so that the namespace of Intel Pin would not be a problem for ROSE. -The development team have suggested that they may fix their use of "using" -declarations for namespaces in their header files. - -Also note that the path must be absolute since it will be the -prefix for the {\bf pin} executable to be run in the internal tests and -anything else might be a problem if the path does not contain the -current directory ({\bf "."}). Or, perhaps we should test for this -in the future. - -Note 2: Linking to libdwarf.a is a special problem. -Both ROSE and Intel Pin use libdwarf.a and both build shred libraries -that link to the static version of the library (libdwarf.a). This is -a problem im building Pin Tools since both the PinTool and librose.so will use -a statically linked dwarf library (internally). This causes the first -use of dwarf to fail, because there are then two versions of the same -library in place. The solution is to force at most one static version -of the library and let the other one be a shared library. - - Alternatively both the Pin tool and librose.so can be -built using the shared version of dwarf (libdwarf.so). -There is a makefile rule in libdwarf to build the shared -version of the library, but the default is to only build the -static library (libdwarf.a), so use {\tt make make libdwarf.so} -to build the shared library. So we allow ROSE to link to -the libdwarf.a (statically), which is how ROSE has always -worked (this may be revisited in the future). And we force -the Pin tool to link using the shared dwarf library (libdwarf.so). -% but with rpath so that we don't require the user to modify the LD\_LIBRARY\_PATH. -{\em Note: The specification of the location of libdwarf.so in the Intel Pin -directory structure is problematic using {\bf rpath}, so for the case of -using the Intel Pin package with ROSE please set the {\bf LD\_LIBRARY\_PATH} -explicitly (a better solution using {\bf rpath} may be made available in -the future).} - - - -\section{Analysis and Transformations on Binaries} - - This section demonstrates how the binary can be analyized and -transformed via operations on the AST. In this tutorial example we will -recognize sequences of NOP (No OPeration) instructions (both single byte -and less common multi-byte NOPs) and replace them in the binary with as -few multi-byte NOP instructions as required to overwrite the identified -NOP sequence (also called a {\em nop sled}). - -In the following subsections we will demonstrate three example codes that -work together to demonstrate aspects of the binary analysis and transforamation using -ROSE. All of these codes are located in the directory {\em tutorial/binaryAnalysis} -of the ROSE distribution. We show specifically: -\begin{enumerate} - \item How to insert NOP sequences into binaries via source-to-source transformations. - The tutorial example will demonstrate the trival insertion of random length - nop sequences into all functions of an input source code application. - The purpose of this is to really just generate arbitrary test codes - upon which to use in sperately demonstrating (and testing) the binary analysis - support and the binary transformation support (next). This example is - shown in figure~\ref{Tutorial:exampleTransformSourceToInsertNOPs}. - The file name is: - \item How to identify sequences of NOP instructions in the binary ({\em nop sleds}). - The tutorial example show how to identify arbitrary NOP sequences in the - binary. Note that our approach looks only for single instructions that have - no side-effect operations and thus qualify as a NOP, and specifically does not - look at collections of multiple statements that taken togehter have no - side-effect and thus could be considered a NOP sequence. Our test on each - instruciton is isolated to the {\tt SageInterface::isNOP(SgAsmInstruction*)} - function. Initially this function only detects NOP instructions that are - single and multi-byte Intel x86 suggested NOP instructions. The catagory of - NOP instructions that have no side-effects is broader than this and will - be addressed more completely in the future. This example is - shown in figures \ref{Tutorial:exampleTransformBinaryToDetectNOPs_header}, - \ref{Tutorial:exampleTransformBinaryToDetectNOPs_source}, and - \ref{Tutorial:exampleTransformBinaryToDetectNOPs_main}. - \item How transformations on the binary executable are done to support rewriting - all identified NOP sequences as Intel x86 suggested NOP instructions. - Importantly, this tutorial example of an AST rewrite does not change the - size of any part of the final executable. This example is - shown in figure~\ref{Tutorial:exampleTransformBinaryToInsertNOPs}. -\end{enumerate} - -\begin{figure}[!h] -{\indent -{\mySmallFontSize - -% Do this when processing latex to generate non-html (not using latex2html) -\begin{latexonly} - \lstinputlisting{\TutorialExampleDirectory/binaryAnalysis/nopSourceTransform.C} -\end{latexonly} - -% Do this when processing latex to build html (using latex2html) -\begin{htmlonly} - \verbatiminput{\TutorialExampleDirectory/binaryAnalysis/nopSourceTransform.C} -\end{htmlonly} - -% end of scope in font size -} -% End of scope in indentation -} -\caption{Source-to-source transformation to introduce NOP assemble instructions in the - generated binary executable.} -\label{Tutorial:exampleTransformSourceToInsertNOPs} -\end{figure} - - -\subsection{Source-to-source transformations to introduce NOPs} - - This tutorial example (see figure~\ref{Tutorial:exampleTransformSourceToInsertNOPs}) -is a source-to-source trnasformation that is used to -generate test codes for the binary NOP sequence detection example and the -NOP sequence transformation example (the next two tutorial examples). -This tutorial uses C language {\em asm} statements that are inserted into -each function in the source code, the resulting generated source code (with {\em asm} -statements) is then compiled to generate inputs to use in our detection and -transformation of NOP sequences. Although it is possible, the backend -compiler (at least the one we are using), does not optimize away these -{\em asm} statements that represent NOP instructions. In general all -C and C++ compilers turn off optimizations upon encountering the {\em asm} -language construct, so it is easy to use this approach to build binaries -from arbitrary source code that have a range of properties. Seeding -the source code with such properties causes the binary to have the similar -properties. We include this example in the tutorial because it is a cute -example of how we can combine source code analsys with binary analysis -(in this case we are only supporting testing of the binary analysis). -Much more interesting example of the connection of source code and -binary analysis are available. - - -\begin{figure}[!h] -{\indent -{\mySmallFontSize - -% Do this when processing latex to generate non-html (not using latex2html) -\begin{latexonly} - \lstinputlisting{\TutorialExampleDirectory/binaryAnalysis/detectNopSequencesTraversal.h} -\end{latexonly} - -% Do this when processing latex to build html (using latex2html) -\begin{htmlonly} - \verbatiminput{\TutorialExampleDirectory/binaryAnalysis/detectNopSequencesTraversal.h} -\end{htmlonly} - -% end of scope in font size -} -% End of scope in indentation -} -\caption{Header file for the traversal used to identify the NOP sequences in the binary executable.} -\label{Tutorial:exampleTransformBinaryToDetectNOPs_header} -\end{figure} - - -\begin{figure}[!h] -{\indent -{\mySmallFontSize - -% Do this when processing latex to generate non-html (not using latex2html) -\begin{latexonly} - \lstinputlisting{\TutorialExampleDirectory/binaryAnalysis/detectNopSequencesTraversal.C} -\end{latexonly} - -% Do this when processing latex to build html (using latex2html) -\begin{htmlonly} - \verbatiminput{\TutorialExampleDirectory/binaryAnalysis/detectNopSequencesTraversal.C} -\end{htmlonly} - -% end of scope in font size -} -% End of scope in indentation -} -\caption{Example code to identify the NOP sequences in the binary executable.} -\label{Tutorial:exampleTransformBinaryToDetectNOPs_source} -\end{figure} - - - - - - - - -\begin{figure}[!h] -{\indent -{\mySmallFontSize - -% Do this when processing latex to generate non-html (not using latex2html) -\begin{latexonly} - \lstinputlisting{\TutorialExampleDirectory/binaryAnalysis/detectNopSequences.C} -\end{latexonly} - -% Do this when processing latex to build html (using latex2html) -\begin{htmlonly} - \verbatiminput{\TutorialExampleDirectory/binaryAnalysis/detectNopSequences.C} -\end{htmlonly} - -% end of scope in font size -} -% End of scope in indentation -} -\caption{Main program using the traversal to identify the NOP sequences in the binary executable.} -\label{Tutorial:exampleTransformBinaryToDetectNOPs_main} -\end{figure} - - -\subsection{Detection of NOP sequences in the binary AST} - - The tutorial example (see figures \ref{Tutorial:exampleTransformBinaryToDetectNOPs_header}, -\ref{Tutorial:exampleTransformBinaryToDetectNOPs_source}, and -\ref{Tutorial:exampleTransformBinaryToDetectNOPs_main}) -shows the detection of NOP sequences and is separated into three -figures (the header file, the source code, and the main program). The header file -and source file will be reused in the next tutorial example to demonstrate the -transformation of the NOP sequences that this tutorial identifies. The -transformation will be done on the AST (and a new modified executable generated -by unparsing the AST). - - Using a simple preorder traversal over the AST we identify independent sequences of -NOP instructions. This traversal save the sequence so that it can be used in both the -tutorial example that detects the NOP sequences and also the tutorial example that -will transform them to be more compact multi-byte NOP sequences that will use the -suggested Intel x86 multi-byte NOP instructions. - - In this example, the sequence of a NOP sequence is saved as the address of the -starting NOP instruction and the number of instructions in the sequence. The function -{\tt SageInterface::isNOP(SgAsmInstruction*)} is used to test of an instruction is -a NOP. Presently this test only identifies single or multi-byte NOP instrucitons -that have been suggested for use as single and multi-byte NOP instructions by Intel. -Other instruction may semantically be equivalent to a NOP instruction and they are -not identified in this initial work. Later work may include this capability and -for this purpose we have isolated out the {\tt SageInterface::isNOP(SgAsmInstruction*)}. -Note also that sequences of instructions may be semantically equivalent to a -NOP sequence and we also do not attempt to identify these (separate interface -functions in the {\tt SageInterface} namespace have been defined to support this -work; these functions are presently unimplemented. - -\begin{figure}[!h] -{\indent -{ -% \mySmallFontSize -\tiny - -% Do this when processing latex to generate non-html (not using latex2html) -\begin{latexonly} - \lstinputlisting{\TutorialExampleDirectory/binaryAnalysis/nopBinaryTransform.C} -\end{latexonly} - -% Do this when processing latex to build html (using latex2html) -\begin{htmlonly} - \verbatiminput{\TutorialExampleDirectory/binaryAnalysis/nopBinaryTransform.C} -\end{htmlonly} - -% end of scope in font size -} -% End of scope in indentation -} -\caption{Example code showing the transformation of the binary executable.} -\label{Tutorial:exampleTransformBinaryToInsertNOPs} -\end{figure} - -\subsection{Transformations on the NOP sequences in the binary AST} - - Using the results from the previously presented traversal to identify -NOP sequences, we demonstrate the transformation to change these -locations of the binary (in the AST) and then regenerate the executable -to have a different representation. The new representation is a more clear -(obvious within manual binary analysis) and likely more compressed -representation using only the suggested Intel x86 multi-byte NOP. - - - -\subsection{Conclusions} - -\fixme{Not sure if the resulting executable will use the assembler on each -instruction in the generated binary from the unparsing within ROSE. This might -require some more work. So at the moment the AST is transformed and I have -to look into if the binary sees the effect of the transformation in the AST.} - - The identification and transformation have been deomonstrated on the AST -and can be expressed in the binary binary by calling the {\em backend()} -function in ROSE; which will regenerate the executable. The capability to -regenerate the executable will not always result in a properly formed -executable that can be executed, this depends upon the transformations done -and does ROSE does not have specialized support for this beyond regnerating -the binary executable from the AST. In the case of this NOP transformation -we have not changed the size of any part of the binary so any relative offsets -need not be fixed up. Assumeing we have not accedentaly interpreted data that -had values that matched parts of the opcodes that were transformed, then resulting -binary executable should execute without problems. This transformation however -makes clear how critical it is that data not be interpreted as instructions -(which could randomly be interpreted as NOPs in the case of this tutorial example). - diff --git a/docs/Rose/Tutorial/binaryConstruction.tex b/docs/Rose/Tutorial/binaryConstruction.tex deleted file mode 100644 index 351cc90878f..00000000000 --- a/docs/Rose/Tutorial/binaryConstruction.tex +++ /dev/null @@ -1,416 +0,0 @@ -\chapter{Binary Construction} - -ROSE is normally used in such a way that a file (source code or -binary) is parsed to construct an AST, then operations are performed -on the AST, and the modified AST is unparsed to create a new source or -binary file. However, it is also possible to construct an AST -explicitly without parsing and then use that AST to generate the -output. The AST construction interface for binary files was designed -so that working files could be created simply, while still providing -methods to control the finer details of the resulting file. - -The example in this chapter shows how to construct a statically linked -ELF executable containing a small ``.text'' section that simply causes -the process to exit with a specific non-zero value. - -\section{Constructors} - -The AST node constructors are designed to construct the tree from the -root down, and thus generally take the parent node as an -argument. Nodes that refer to other nodes as prerequisites also take -those prerequisites as arguments. For instance, an ELF Relocation -Section is a child of the ELF File Header but also needs an ELF Symbol -Table and therefore takes both objects as constructor arguments. - -\section{Read-Only Data Members} - -When two or more file formats have a similar notion then that notion -is represented in a base class. However, part of the information may -continue to survive in the specialized class. In these situations -modifications to the specilized data will probably be overridden by -the generic values from the base class. For instance, all formats -have a notion of byte order which is represented in the base class -SgAsmGenericHeader as little- or big-endian (an enumeration -constant). The ELF specification provides an 8-bit unsigned field to -store the byte order and therefore has potentially more than two -possibilities. Any value assigned to the ELF-specific byte order will -likely be overwritten by the generic byte order before the AST is -unparsed. - -A similar situation arises with section offsets, sizes, memory -mappings, permissions, etc. The SgAsmGenericSection class represents -ELF Sections, ELF Segments, PE Objects, and other contiguous regions -of a file and has methods for obtaining/setting these values. In -addition, many of the formats have some sort of table that describes -these sections and which also contains similar information (e.g., the -ELF Segment Table, a.k.a., the ELF Program Header Table). As above, -the generic representation of these notions (stored in -SgAsmGenericSection) override the format-specific values (stored in -SgAsmElfSegmentEntry). - -ROSETTA doesn't make a distinction between data members that can be -user-modified and data members that should be modified only by the -parser. Therefore it is up to the user to be aware that certain data -members will have their values computed or copied from other locations -in the AST during the unparsing phase. - -\section{Constructing the Executable File Container} - -All executable files are stored as children of an SgAsmGenericFile -node. The children are file format headers (SgAsmGenericHeader) such -as an ELF File Header (SgAsmElfFileHeader). This design allows a -single executable file to potentially contain more than one executable -and is used by formats like Windows-PE where the file contains a DOS -File Header as well as a PE File Header. - -For the purposes of this example the SgAsmGenericFile node will serve -as the root of the AST and therefore we do not need to specify a -parent in the constructor argument list. - -\begin{verbatim} -SgAsmGenericFile *ef = new SgAsmGenericFile; -\end{verbatim} - -\section{Constructing the ELF File Header} - -The ELF File Header is the first thing in the file, always at offset -zero. File headers are always children of an SgAsmGenericFile which is -specified as the constructor argument. - -The section constructors (a file header is a kind of section) always -create the new section so it begins at the current end-of-file and -contains at least one byte. This ensures that each section has a -unique starting address, which will be important when file memory is -actually allocated and sections need to be moved around--the allocator -needs to know the relative positions of the sections in order to -correctly relocate them. - -If we were parsing an ELF file we would usually use ROSE's frontend() -method. However, one can also parse the file by first constructing the -SgAsmElfFileHeader and then invoking its parse() method, which parses -the ELF File Header and everything that can be reached from that -header. - -We use the typical 0x400000 as the virtual address of the main LOAD -segment, which occupies the first part of the file up through the end -of the ``.text'' section (see below). ELF File Headers don't actually -store a base address, so instead of assigning one to the -SgAsmElfFileHeader we'll leave the header's base address at the -default zero and add base\_va explicitly whenever we need to. - -\begin{verbatim} -SgAsmElfFileHeader *fhdr = new SgAsmElfFileHeader(ef); -fhdr->get_exec_format()->set_word_size(8); /* default is 32-bit; we want 64-bit */ -fhdr->set_isa(SgAsmExecutableFileFormat::ISA_X8664_Family); /* instruction set architecture; default is ISA_IA32_386 */ -rose_addr_t base_va = 0x400000; /* base virtual address */ -\end{verbatim} - -\section{Constructing the ELF Segment Table} - -ELF executable files always have an ELF Segment Table (also called the -ELF Program Header Table), which usually appears immediately after the -ELF File Header. The ELF Segment Table describes contiguous regions of -the file that should be memory mapped by the loader. ELF Segments -don't have names--names are imparted to the segment by virtue of the -segment also being described by the ELF Section Table, which we'll -create later. - -Being a contiguous region of the file, an ELF Segment Table -(SgAsmElfSegmentTable) is derived from SgAsmGenericSection. All -non-header sections have a header as a parent, which we supply as an -argument to the constructor. Since all ELF Segments will be children of -the ELF File Header rather than children of the ELF Segment Table, we -could define the ELF Segment Table at the end rather than here. But -defining it now is an easy way to get it located in its usuall -location immediately after the ELF File Header. - -\begin{verbatim} -SgAsmElfSegmentTable *segtab = new SgAsmElfSegmentTable(fhdr); -\end{verbatim} - -\section{Constructing the .text Section} - -ROSE doesn't treat a ``.text'' section as being anything particularly -special--it's just a regular SgAsmElfSection, which derives from -SgAsmGenericSection. However, in this example, we want to make sure -that our ``.text'' section gets initialized with some -instructions. The easiest way to do that is to specialize -SgAsmElfSection and override or augment a few of the virtual -functions. - -We need to override two functions. First, the calculate\_sizes() -function should return the size we need to store the -instructions. We'll treat the instructions as an array of entries each -entry being one byte of the instruction stream. In other words, each -``entry'' is one byte in length consisting of one required byte and no -optional bytes. - -We need to also override the unparse() method since the base class -will just fill the ``.text'' section with zeros. The -SgAsmGenericSection::write method we use will write the instructions -starting at the first byte of the section. - -Finally, we need to augment the reallocate() method. This method is -reponsible for allocating space in the file for the section and -performing any other necessary pre-unparsing actions. We don't need to -allocate space since the base class's method will take care of that in -conjuction with our version of calculate\_sizes(), but we do need to -set a special ELF flag (SHF\_ALLOC) in the ELF Segment Table entry for -this section. There's a few ways to accomplish this. We do it this way -because the ELF Section Table Entry is not created until later and we -want to demonstrate how to keep all .text-related code in close -proximity. - -\begin{verbatim} -class TextSection : public SgAsmElfSection { -public: - TextSection(SgAsmElfFileHeader *fhdr, size_t ins_size, const unsigned char *ins_bytes) - : SgAsmElfSection(fhdr), ins_size(ins_size), ins_bytes(ins_bytes) - {} - virtual rose_addr_t calculate_sizes(size_t *entsize, size_t *required, size_t *optional, size_t *entcount) const { - if (entsize) *entsize = 1; /* an "entry" is one byte of instruction */ - if (required) *required = 1; /* each "entry" is also stored in one byte of the file */ - if (optional) *optional = 0; /* there is no extra data per instruction byte */ - if (entcount) *entcount = ins_size; /* number of "entries" is the total instruction bytes */ - return ins_size; /* return value is section size required */ - } - virtual bool reallocate() { - bool retval = SgAsmElfSection::reallocate(); /* returns true if size or position of any section changed */ - SgAsmElfSectionTableEntry *ste = get_section_entry(); - ste->set_sh_flags(ste->get_sh_flags() | 0x02); /* set the SHF_ALLOC bit */ - return retval; - } - virtual void unparse(std::ostream &f) const { - write(f, 0, ins_size, ins_bytes); /* Write the instructions at offset zero in section */ - } - size_t ins_size; - const unsigned char *ins_bytes; -}; -\end{verbatim} - -The section constructors and reallocators don't worry about alignment -issues--they always allocate from the next available byte. However, -instructions typically need to satisfy some alignment constraints. We -can easily adjust the file offset chosen by the constructor, but we -also need to tell the reallocator about the alignment constraint. Even -if we didn't ever resize the ``.text'' section the reallocator could -be called for some other section in such a way that it needs to move -the ``.text'' section to a new file offset. - -For the purpose of this tutorial we want to be very picky about the -location of the ELF Segment Table. We want it to immediately follow -the ELF File Header without any intervening bytes of padding. At the -current time, the ELF File Header has a size of one byte and will -eventually be reallocated. When we reallocate the header the -subsequent sections will need to be shifted to higher file -offsets. When this happens, the allocator shifts them all by the same -amount taking care to satisfy all alignment constraints, which means -that an alignment constraint of byte bytes on the ``.text'' section -will induce a similar alignment on the ELF Segment Table. Since we -don't want that, the best practice is to call reallocate() now, before -we create the ``.text'' section. - -\begin{verbatim} -ef->reallocate(); /* Give existing sections a chance to allocate file space */ -static const unsigned char instructions[] = {0xb8, 0x01, 0x00, 0x00, 0x00, 0xbb, 0x56, 0x00, 0x00, 0x00, 0xcd, 0x80}; -SgAsmElfSection *text = new TextSection(fhdr, NELMTS(instructions), instructions); -text->set_purpose(SgAsmGenericSection::SP_PROGRAM); /* Program-supplied text/data/etc. */ -text->set_offset(alignUp(text->get_offset(), 4)); /* Align on an 8-byte boundary */ -text->set_file_alignment(4); /* Tell reallocator about alignment constraint */ -text->set_mapped_alignment(4); /* Alignment constraint for memory mapping */ -text->set_mapped_rva(base_va+text->get_offset()); /* Mapped address is based on file offset */ -text->set_mapped_size(text->get_size()); /* Mapped size is same as file size */ -text->set_mapped_rperm(true); /* Readable */ -text->set_mapped_wperm(false); /* Not writable */ -text->set_mapped_xperm(true); /* Executable */ -\end{verbatim} - -At this point the text section doesn't have a name. We want to name it -``.text'' and we want those characters to eventually be stored in the -ELF file in a string table which we'll provide later. In ELF, section -names are represented by the section's entry in the ELF Section Table -as an offset into an ELF String Table for a NUL-terminated ASCII -string. ROSE manages strings using the SgAsmGenericString class, which -has two subclasses: one for strings that aren't stored in the -executable file (SgAsmBasicString) and one for strings that are stored -in the file (SgAsmStoredString). Both are capable of string an -std::string value and querying its byte offset (although -SgAsmBasicString::get\_offset() will always return -SgAsmGenericString::unallocated). Since we haven't added the -``.text'' section to the ELF Section Table yet the new section has an -SgAsmBasicString name. We can assign a string to the name now and the -string will be allocated in the ELF file when we've provided further -information. - -\begin{verbatim} -text->get_name()->set_string(".text"); -\end{verbatim} - -The ELF File Header needs to know the virtual address at which to -start running the program. In ROSE, virtual addresses can be attached -to a specific section so that if the section is ever moved the address -is automatically updated. Some formats allow more than one entry -address which is why the method is called add\_entry\_rva() rather than -set\_entry\_rva(). ELF, however, only allows one entry address. - -\begin{verbatim} -rose_rva_t entry_rva(text->get_mapped_rva(), text); -fhdr->add_entry_rva(entry_rva); -\end{verbatim} - -\section{Constructing a LOAD Segment} - -ELF Segments define parts of an executable file that should be mapped -into memory by the loader. A program will typically have a LOAD -segment that begins at the first byte of the file and continues -through the last instruction (in our case, the end of the ``.text'' -section) and which is mapped to virtual address 0x400000. - -We've already created the ELF Segment Table, so all we need to do now -is create an ELF Segment and add it to the ELF Segment Table. ELF -Segments, like ELF Sections, are represented by SgAsmElfSection. An -SgAsmElfSection is an ELF Section if it has an entry in the ELF -Section Table, and/or it's an ELF Segment if it has an entry in the -ELF Segment Table. The methods get\_section\_entry() and -get\_segment\_entry() retrieve the actual entries in those tables. - -Recall that the constructor creates new sections located at the -current end-of-file and containing one byte. Our LOAD segment needs to -have a different offset and size. - -\begin{verbatim} -SgAsmElfSection *seg1 = new SgAsmElfSection(fhdr); /* ELF Segments are represented by SgAsmElfSection */ -seg1->get_name()->set_string("LOAD"); /* Segment names aren't saved (but useful for debugging) */ -seg1->set_offset(0); /* Starts at beginning of file */ -seg1->set_size(text->get_offset() + text->get_size()); /* Extends to end of .text section */ -seg1->set_mapped_rva(base_va); /* Typically mapped by loader to this memory address */ -seg1->set_mapped_size(seg1->get_size()); /* Make mapped size match size in the file */ -seg1->set_mapped_rperm(true); /* Readable */ -seg1->set_mapped_wperm(false); /* Not writable */ -seg1->set_mapped_xperm(true); /* Executable */ -segtab->add_section(seg1); /* Add definition to ELF Segment Table */ -\end{verbatim} - -\section{Constructing a PAX Segment} - -This documentation shows how to construct a generic ELF Segment, -giving it a particular file offset and size. ELF Segments don't have -names stored in the file, but we can assign a name to the AST node to -aid in debugging--it just won't be written out. When parsing an ELF -file, segment names are generated based on the type stored in the -entry of the ELF Segment Table. For a PAX segment we want this type to -be PT\_PAX\_FLAGS (the default is PT\_LOAD). - -\begin{verbatim} -SgAsmElfSection *pax = new SgAsmElfSection(fhdr); -pax->get_name()->set_string("PAX Flags"); /* Name just for debugging */ -pax->set_offset(0); /* Override address to be at zero rather than EOF */ -pax->set_size(0); /* Override size to be zero rather than one byte */ -segtab->add_section(pax); /* Add definition to ELF Segment Table */ -pax->get_segment_entry()->set_type(SgAsmElfSegmentTableEntry::PT_PAX_FLAGS); -\end{verbatim} - -\section{Constructing a String Table} - -An ELF String Table always corresponds to a single ELF Section of -class SgAsmElfStringSection and thus you'll often see the term ``ELF -String Section'' used interchangeably with ``ELF String Table'' even -though they're two unique but closely tied classes internally. - -When the ELF String Section is created a corresponding ELF String -Table is also created under the covers. Since string tables manage -their own memory in reponse to the strings they contain, one should -never adjust the size of the ELF String Section (it's actually fine to -enlarge the section and the new space will become free space in the -string table). - -ELF files typically have multiple string tables so that section names -are in a different section than symbol names, etc. In this tutorial -we'll create the section names string table, typically called -``.shstrtab'', but use it for all string storage. - -\begin{verbatim} -SgAsmElfStringSection *shstrtab = new SgAsmElfStringSection(fhdr); -shstrtab->get_name()->set_string(".shstrtab"); -\end{verbatim} - -\section{Constructing an ELF Section Table} - -We do this last because we want the ELF Section Table to appear at the -end of the file and this is the easiest way to achieve that. There's -really not much one needs to do to create the ELF Section Table other -than provide the ELF File Header as a parent and supply a string -table. - -The string table we created above isn't activated until we assign it -to the ELF Section Table. The first SgAsmElfStringSection added to the -SgAsmElfSectionTable becomes the string table for storing section -names. It is permissible to add other sections to the table before -adding the string table. - -\begin{verbatim} -SgAsmElfSectionTable *sectab = new SgAsmElfSectionTable(fhdr); -sectab->add_section(text); /* Add the .text section */ -sectab->add_section(shstrtab); /* Add the string table to store section names. */ -\end{verbatim} - -\section{Allocating Space} - -Prior to calling unparse(), we need to make sure that all sections -have a chance to allocate space for themselves, and perform any other -operations necessary. It's not always possible to determine sizes at -an earlier time, and most constructors would have declared sizes of -only one byte. - -The reallocate() method is defined in the SgAsmGenericFile class since -it operates over the entire collection of sections simultaneously. In -other words, if a section needs to grow then all the sections located -after it in the file need to be shifted to higher file offsets. - -\begin{verbatim} -ef->reallocate(); -\end{verbatim} - -The reallocate() method has a shortcoming (as of 2008-12-19) in that -it might not correctly update memory mappings in the case when the -mapping for a section is inferred from the mapping of a containing -segment. This can happen in our example since the ``.text'' section's -memory mapping is a function of the LOAD Segment mapping. The -work-around is to adjust mappings for these situations and then call -reallocate() one final time. This final reallocate() call won't move -any sections, but should always be the last thing to call before -unparsing() (it gives sections a chance to update data dependencies -which is not possible during unparse() due to its const nature). - -\begin{verbatim} -text->set_mapped_rva(seg1->get_mapped_rva()+(text->get_offset()-seg1->get_offset())); -ef->reallocate(); /*won't resize or move things this time since we didn't modify much since the last call to reallocate()*/ -\end{verbatim} - -\section{Produce a Debugging Dump} - -A debugging dump can be made with the following code. This dump will -not be identical to the one produced by parsing and dumping the -resulting file since we never parsed a file (a dump contains some -information that's parser-specific). - -\begin{verbatim} -ef->dump(stdout); -SgAsmGenericSectionPtrList all = ef->get_sections(true); -for (size_t i=0; idump(stdout, " ", -1); -} -\end{verbatim} - -\section{Produce the Executable File} - -The executable file is produced by unparsing the AST. - -\begin{verbatim} -std::ofstream f("a.out"); -ef->unparse(f); -\end{verbatim} - -Note that the resulting file will not be created with execute -permission--that must be added manually. diff --git a/docs/Rose/Tutorial/dwarfDebugSupport.tex b/docs/Rose/Tutorial/dwarfDebugSupport.tex deleted file mode 100644 index 8a21fc737a1..00000000000 --- a/docs/Rose/Tutorial/dwarfDebugSupport.tex +++ /dev/null @@ -1,179 +0,0 @@ -\chapter{Dwarf Debug Support} - -% Copied from the Dwarf wikipedia page. -DWARF is a widely used, standardized debugging data format. DWARF was originally designed -along with ELF, although it is independent of object file formats. The name is a -pun on "ELF" that has no official meaning but "may be an acronym for 'Debug With -Attributed Record Format'". See Wikipedia for more information about the Dwarf -debug format. - -This chapter presents the support in ROSE for Dwarf 3 debug information; its -representation in the AST and its use in binary analysis tools. This work is part of -general work to support as much information as possible about binaries. - -In the following sections we use a small example (see figure \ref{Tutorial:dwarfAnalysisExampleSourceCode}) -that demonstrates various features of Dwarf. The source code of our binary example is: - -\commentout{ -\begin{figure}[!h] -{\indent -{\mySmallFontSize - -% Do this when processing latex to generate non-html (not using latex2html) -\begin{latexonly} - \lstinputlisting{\TutorialExampleDirectory/dwarfAnalysis.C} -\end{latexonly} - -% Do this when processing latex to build html (using latex2html) -\begin{htmlonly} - \verbatiminput{\TutorialExampleDirectory/dwarfAnalysis.C} -\end{htmlonly} - -% end of scope in font size -} -% End of scope in indentation -} -\caption{Example source code (typical for reading in a binary or source file).} -\label{Tutorial:dwarfAnalysisExampleSourceCode} -\end{figure} -} - -\begin{figure}[!h] -{\indent -{\mySmallFontSize - -% Do this when processing latex to generate non-html (not using latex2html) -\begin{latexonly} - \lstinputlisting{\TutorialExampleDirectory/inputCode_dwarfAnalysis.C} -\end{latexonly} - -% Do this when processing latex to build html (using latex2html) -\begin{htmlonly} - \verbatiminput{\TutorialExampleDirectory/inputCode_dwarfAnalysis.C} -\end{htmlonly} - -% end of scope in font size -} -% End of scope in indentation -} -\caption{Example source code used to generate Dwarf AST for analysis.} -\label{Tutorial:dwarfAnalysisExampleSourceCode} -\end{figure} - - -Much larger binaries can be analyzed, but such larger binary executables are more -difficult to present (in this tutorial). - - -\section{ROSE AST of Dwarf IR nodes} - - ROSE tools process the binary into an AST that is used to represent all the -information in the binary executable. Figure \ref{Tutorial:Dwarf_AST_example} -shows the subset of that AST (which includes the rest of the binary file format -and the disassembled instructions) that is specific to Dwarf. A command line option -({\em -rose:visualize\_dwarf\_only}) is used to restrict the generated dot file -visualization to just the Dwarf information. This option is used in combination with -{\em -rose:read\_executable\_file\_format\_only} to process only the binary file format -(thus skipping the instruction disassembly). - -\begin{figure}[h] -{\indent -{\mySmallFontSize - -% Do this when processing latex to generate non-html (not using latex2html) -\begin{latexonly} -% \includegraphics[scale=0.9]{\TutorialExampleBuildDirectory/inputCode_dwarfAnalysis} - \includegraphics[viewport=5 1 50 500,scale=0.9]{\TutorialExampleBuildDirectory/inputCode_dwarfAnalysis} -\end{latexonly} - -% Do this when processing latex to build html (using latex2html) -\begin{htmlonly} - \includegraphics{\TutorialExampleBuildDirectory/inputCode_dwarfAnalysis} -\end{htmlonly} - -% end of scope in font size -} -% End of scope in indentation -} -\caption{Dwarf AST (subset of ROSE binary AST).} -\label{Tutorial:Dwarf_AST_example} -\end{figure} - - - -\section{Source Position to Instruction Address Mapping} - - One of the valuable parts of Dwarf is the mapping between the -source lines and the instruction addresses at a statement level -(provided in the {\em .debug\_line} section). -Even though Dwarf does not represent all statements in the source -code, the mapping is significantly finer granularity than that -provided at only the function level by the symbol table (which -identifies the functions by instruction address, but not the -source file line numbers; the later requires source code analysis). - -The example code in \ref{Tutorial:dwarfInstructionAddressToSourceLineExampleSourceCode} -shows the mapping between the source code lines and the instruction addresses. - -\fixme{This need to be improved to correctly return sets of lines and sets of addresses in - what might be a second interface.} - -\begin{figure}[!h] -{\indent -{\mySmallFontSize - -% Do this when processing latex to generate non-html (not using latex2html) -\begin{latexonly} - \lstinputlisting{\TutorialExampleDirectory/dwarfInstructionAddressToSourceLineAnalysis.C} -\end{latexonly} - -% Do this when processing latex to build html (using latex2html) -\begin{htmlonly} - \verbatiminput{\TutorialExampleDirectory/dwarfInstructionAddressToSourceLineAnalysis.C} -\end{htmlonly} - -% end of scope in font size -} -% End of scope in indentation -} -\caption{Example source code (typical for reading in a binary or source file).} -\label{Tutorial:dwarfInstructionAddressToSourceLineExampleSourceCode} -\end{figure} - -Output from the compilation of this test code and running it with the example input -results in the output shown in figure \ref{Tutorial:dwarfInstructionAddressToSourceLineExampleOutput}. -This output shows the binary executables instruction address range (binary compiled on -Linux x86 system), the range of lines of source code used by the binary executable, -the mapping of a source code range of line numbers to the instruction addresses, -and the mapping of a range of instruction addresses to the source code line numbers. - -%\fixme{Need to handle case of were each query can return a set of line or set of -% addresses. This may be a different interface for simplicty.} - -\begin{figure}[!h] -{\indent -{\mySmallFontSize - -% Do this when processing latex to generate non-html (not using latex2html) -\begin{latexonly} - \lstinputlisting{\TutorialExampleBuildDirectory/inputCode_dwarfAnalysis.out} -\end{latexonly} - -% Do this when processing latex to build html (using latex2html) -\begin{htmlonly} - \verbatiminput{\TutorialExampleBuildDirectory/inputCode_dwarfAnalysis.out} -\end{htmlonly} - -% end of scope in font size -} -% End of scope in indentation -} -\caption{Example source code (typical for reading in a binary or source file).} -\label{Tutorial:dwarfInstructionAddressToSourceLineExampleOutput} -\end{figure} - - - - - - diff --git a/docs/Rose/Tutorial/roseHPCT.tex b/docs/Rose/Tutorial/roseHPCT.tex deleted file mode 100644 index 2ce177095e7..00000000000 --- a/docs/Rose/Tutorial/roseHPCT.tex +++ /dev/null @@ -1,496 +0,0 @@ -%========================================================================== -\chapter{ROSE-HPCToolKit Interface} -\label{chap:rosehpct} -ROSE-HPCToolKit is designed to read in performance data generated -by HPCToolkit (and recently GNU gprof) and annotate ROSE AST with performance -metrics. -It is included in the ROSE distribution and -enabled by default if an existing installation of the Gnome XML library, libxml2 -(\url{http://xmlsoft.org}) can be detected by ROSE's configure script. -Or it can be enabled explicitly by specifying the \texttt{--enable-rosehpct} option -when running configure. -% and be sure that you have an existing installation of the Gnome XML library, libxml2 (\url{http://xmlsoft.org}). - -The HPCToolkit (\url{http://www.hipersoft.rice.edu/hpctoolkit}) is a -set of tools for analyzing the dynamic performance behavior of -applications. It includes a tool that instruments a program's binary, -in order to observe CPU hardware counters during execution; additional -post-processing tools attribute the observed data to statements in the -original source code. HPCToolkit stores this data and the source -attributions in XML files. In this chapter, we give an overview of -simple interfaces in ROSE that can read this data and attach it to the -AST. - -GNU gprof is a basic but easy to use profiling tool. -It produces an execution profile of applications. -gprof's output is a flat profile for each function by default, which is not -very interesting to us. -We use a line-by-line output with full file path information generated by using -option {\tt -l -L} with gprof. - -\input{\TutorialExampleBuildDirectory/roseHPCT/is-static} - -%========================================================================== -\section{An HPCToolkit Example Run} -\label{chap:rosehpct:run} - -%-------------------------------------------------------------------------- -\begin{figure}[!h] -{\indent -{\mySmallFontSize -% Do this when processing latex to generate non-html (not using latex2html) -\begin{latexonly} - \lstinputlisting[language=C,numbers=left,stepnumber=5]{\TutorialExampleBuildDirectory/roseHPCT/profiled.c.aa} -\end{latexonly} - -% Do this when processing latex to build html (using latex2html) -\begin{htmlonly} - \verbatiminput{\TutorialExampleBuildDirectory/roseHPCT/profiled.c.aa} -\end{htmlonly} - -% end of scope in font size -} -% End of scope in indentation -} -\caption{profiled.c (part 1 of 2): Sample input program, profiled using the HPCToolkit.} -\label{Tutorial:roseHPCT:profiled:aa} -\end{figure} -%-------------------------------------------------------------------------- - -%-------------------------------------------------------------------------- -\begin{figure}[!h] -{\indent -{\mySmallFontSize -% Do this when processing latex to generate non-html (not using latex2html) -\begin{latexonly} - \lstinputlisting[language=C,numbers=left,stepnumber=5,firstnumber=66]{\TutorialExampleBuildDirectory/roseHPCT/profiled.c.ab} -\end{latexonly} - -% Do this when processing latex to build html (using latex2html) -\begin{htmlonly} - \verbatiminput{\TutorialExampleBuildDirectory/roseHPCT/profiled.c.ab} -\end{htmlonly} - -% end of scope in font size -} -% End of scope in indentation -} -\caption{profiled.c (part 2 of 2): Sample input program, profiled using the HPCToolkit.} -\label{Tutorial:roseHPCT:profiled:ab} -\end{figure} -%-------------------------------------------------------------------------- - -Consider the sample source program shown in -Figures~\ref{Tutorial:roseHPCT:profiled:aa}--\ref{Tutorial:roseHPCT:profiled:ab}. -This program takes an integer $n$ on the command line, and has a -number of loops whose flop and memory-operation complexity are either -$\Theta(n)$ or $\Theta(n^2)$. For this example, we would expect the -loop nest at line 56, which has $O(n^2)$ cost, to be the most -expensive loop in the program for large $n$. - -%-------------------------------------------------------------------------- -\begin{figure}[!h] -{\indent -{\mySmallFontSize -% Do this when processing latex to generate non-html (not using latex2html) -\begin{latexonly} - \lstinputlisting[language=XML,numbers=left,stepnumber=5]{\TutorialExampleBuildDirectory/roseHPCT/PAPI_TOT_CYC.xml.aa} -\end{latexonly} - -% Do this when processing latex to build html (using latex2html) -\begin{htmlonly} - \verbatiminput{\TutorialExampleBuildDirectory/roseHPCT/PAPI_TOT_CYC.xml.aa} -\end{htmlonly} - -% end of scope in font size -} -% End of scope in indentation -} -\caption{XML schema for HPCToolkit data files: This schema, prepended -to each of the HPCToolkit-generated XML files, describes the format of -the profiling data. This particular schema was generated by HPCToolkit -1.0.4.} -\label{Tutorial:roseHPCT:xml:schema} -\end{figure} -%-------------------------------------------------------------------------- - -%-------------------------------------------------------------------------- -\begin{figure}[!h] -{\indent -{\mySmallFontSize -% Do this when processing latex to generate non-html (not using latex2html) -\begin{latexonly} - \lstinputlisting[language=XML,numbers=left,stepnumber=5,firstnumber=62]{\TutorialExampleBuildDirectory/roseHPCT/PAPI_TOT_CYC.xml.ab} -\end{latexonly} - -% Do this when processing latex to build html (using latex2html) -\begin{htmlonly} - \verbatiminput{\TutorialExampleBuildDirectory/roseHPCT/PAPI_TOT_CYC.xml.ab} -\end{htmlonly} - -% end of scope in font size -} -% End of scope in indentation -} -\caption{PAPI\_TOT\_CYC.xml: Sample cycle counts observed during -profiling, generated from running the HPCToolkit on profiled.c -(Figures~\ref{Tutorial:roseHPCT:profiled:aa}--\ref{Tutorial:roseHPCT:profiled:ab}.) -These lines would appear after the schema shown in -Figure~\ref{Tutorial:roseHPCT:xml:schema}.} -\label{Tutorial:roseHPCT:xml:cycles} -\end{figure} -%-------------------------------------------------------------------------- - -%-------------------------------------------------------------------------- -\begin{figure}[!h] -{\indent -{\mySmallFontSize -% Do this when processing latex to generate non-html (not using latex2html) -\begin{latexonly} - \lstinputlisting[language=XML,numbers=left,stepnumber=5,firstnumber=62]{\TutorialExampleBuildDirectory/roseHPCT/PAPI_FP_OPS.xml.ab} -\end{latexonly} - -% Do this when processing latex to build html (using latex2html) -\begin{htmlonly} - \verbatiminput{\TutorialExampleBuildDirectory/roseHPCT/PAPI_FP_OPS.xml.ab} -\end{htmlonly} - -% end of scope in font size -} -% End of scope in indentation -} -\caption{PAPI\_FP\_OPS.xml: Sample flop counts observed during -profiling, generated from running the HPCToolkit on profiled.c -(Figures~\ref{Tutorial:roseHPCT:profiled:aa}--\ref{Tutorial:roseHPCT:profiled:ab}.) -These lines would appear after the schema shown in -Figure~\ref{Tutorial:roseHPCT:xml:schema}.} -\label{Tutorial:roseHPCT:xml:flops} -\end{figure} -%-------------------------------------------------------------------------- - -Suppose we use the HPCToolkit to profile this program, collecting -cycle counts and floating-point instructions.\footnote{In this -example, HPCToolkit uses the PAPI to read CPU counters -(\url{http://icl.cs.utk.edu/papi}).} HPCToolkit will generate one XML -file for each metric. - -A schema specifying the format of these XML files appears in -Figure~\ref{Tutorial:roseHPCT:xml:schema}. In essence, this schema -specifies that the XML file will contain a structured, abstract -representation of the program in terms of abstract program entities -such as ``modules,'' ``procedures,'' ``loops,'' and ``statements.'' -Each of these entities may have line number information and a -``metric'' value. (Refer to the HPCToolkit documentation for more -information.) This schema is always the first part of an -HPCToolkit-generated XML profile data file. - -We ran HPCToolkit on the program in -Figures~\ref{Tutorial:roseHPCT:profiled:aa}--\ref{Tutorial:roseHPCT:profiled:ab}, -and collected cycle and flop counter data. The actual XML files -storing this data appear in Figures~\ref{Tutorial:roseHPCT:xml:cycles} -and~\ref{Tutorial:roseHPCT:xml:flops}. By convention, these metrics -are named according to their PAPI symbolic name, as shown on line 67 -in both Figures~\ref{Tutorial:roseHPCT:xml:cycles} -and~\ref{Tutorial:roseHPCT:xml:flops}. According to the cycle data on -line 90 of Figure~\ref{Tutorial:roseHPCT:xml:cycles}, the most -expensive statement in profiled.c is line 62 of -Figure~\ref{Tutorial:roseHPCT:profiled:aa}, as expected. - -%========================================================================== -\clearpage -\section{Attaching HPCToolkit Data to the ROSE AST} -\label{chap:rosehpct:attach} - -To attach the data of Figures~\ref{Tutorial:roseHPCT:xml:cycles} -and~\ref{Tutorial:roseHPCT:xml:flops} to the AST, we augment a basic -ROSE translator with two additional calls, as shown in -Figure~\ref{Tutorial:roseHPCT:attach}, lines 47--48 and 54. We -describe these calls below. - -%-------------------------------------------------------------------------- -\begin{figure}[!h] -{\indent -{\mySmallFontSize - - -% Do this when processing latex to generate non-html (not using latex2html) -\begin{latexonly} - \lstinputlisting[numbers=left,stepnumber=5]{\TutorialExampleDirectory/roseHPCT/attachMetrics.cc} -\end{latexonly} - -% Do this when processing latex to build html (using latex2html) -\begin{htmlonly} - \verbatiminput{\TutorialExampleDirectory/roseHPCT/attachMetrics.cc} -\end{htmlonly} - -% end of scope in font size -} -% End of scope in indentation -} -\caption{attachMetrics.cc: Sample translator to attach HPCToolkit metrics to the AST.} -\label{Tutorial:roseHPCT:attach} -\end{figure} -%-------------------------------------------------------------------------- - -%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -\subsection{Calling ROSE-HPCT} - -We must first include rosehpct/rosehpct.hh, as shown on line 6 of -Figure~\ref{Tutorial:roseHPCT:attach}. All ROSE-HPCT routines and -intermediate data structures reside in the RoseHPCT namespace. - -Next, lines 47--48 of Figure~\ref{Tutorial:roseHPCT:attach} store the -contents of the raw XML file into an intermediate data structure of -type RoseHPCT::ProgramTreeList\_t. The RoseHPCT::loadProfilingFiles() -routine processes command-line arguments, extracting -ROSE-HPCT-specific options that specify the files. We discuss these -options in Section~\ref{sec:rosehpct:cmdlineopts}. - -Line 54 of Figure~\ref{Tutorial:roseHPCT:attach}, attaches the -intermediate profile data structure to the ROSE AST. The -RoseHPCT::attachMetrics() routine creates new persistent attributes -that store the counter data.\footnote{The last parameter to -RoseHPCT::attachMetrics() is a boolean that, when true, enables -verbose (debugging) messages to standard error.} The attributes are -named using the metric name taken from the XML file (see lines 67 of -Figures~\ref{Tutorial:roseHPCT:xml:cycles}--\ref{Tutorial:roseHPCT:xml:flops}); -in this example, the attributes are named PAPI\_TOT\_CYC and -PAPI\_FP\_OPS. Following the conventions of persistent attribute -mechanism as described in Chapter~\ref{chap:traversals}, the -attributes themselves are of type RoseHPCT::MetricAttr, which derives -from the AstAttribute type. - -%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -\subsection{Retrieving the attribute values} - -We retrieve the attribute values as described in -Chapter~\ref{chap:traversals}. In particular, given a located node -with cycle and flop attribute values, the printFlopRate() routine -defined in lines 11--42 of Figure~\ref{Tutorial:roseHPCT:attach} -prints the source position, AST node type, and estimated flops per -cycle. We call printFlopRate() for each expression statement -(SgExpressionStmt), for-initializer (SgForInitStatement), and -for-statement (SgForStatement) in lines 59--66 of -Figure~\ref{Tutorial:roseHPCT:attach}. The output is shown in -Figure~\ref{Tutorial:roseHPCT:profiled:out}. - -Inspecting the output carefully, you may notice seeming discrepancies -between the values shown and the values that appear in the XML files, -or other values which seem unintuitive. We explain how these values -are derived in Section~\ref{sec:rosehpct:metprop}. - -This example dumps the AST as a PDF file, as shown on line 68 of -Figure~\ref{Tutorial:roseHPCT:attach}. You can inspect this file to -confirm where attributes have been attached. We show an example of -such a page in Figure~\ref{Tutorial:roseHPCT:pdf}. This page is the -SgExprStatement node representing the sum-accumulate on line 26 of -Figure~\ref{Tutorial:roseHPCT:profiled:aa}. - -\begin{figure}[!ht] -{\mySmallFontSize - \verbatiminput{\TutorialExampleBuildDirectory/roseHPCT/profiled.out} -} -\caption{Sample output, when running attachMetrics.cc -(Figure~\ref{Tutorial:roseHPCT:attach}) with the XML inputs in -Figures~\ref{Tutorial:roseHPCT:xml:cycles}--\ref{Tutorial:roseHPCT:xml:flops}. Here, -we only show the output sent to standard output (\emph{i.e.}, cout and -not cerr).} -\label{Tutorial:roseHPCT:profiled:out} -\end{figure} - -\begin{figure}[!hb] -\includegraphics[width=6in,trim=0in 7.8in 2in 0in, clip]{\TutorialExampleBuildDirectory/roseHPCT/profiled-p93.pdf} -\caption{Sample PDF showing attributes.} -\label{Tutorial:roseHPCT:pdf} -\end{figure} - -%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -\subsection{Metric propagation} -\label{sec:rosehpct:metprop} - -The example program in Figure~\ref{Tutorial:roseHPCT:attach} dumps -metric values at each expression statement, for-initializer, and -for-statement, but the input XML files in -Figure~\ref{Tutorial:roseHPCT:xml:cycles}--\ref{Tutorial:roseHPCT:xml:flops} -only attribute the profile data to ``statements'' that are not loop -constructs. (The \texttt{} XML tags refer to statements, -intended to be ``simple'' non-scoping executable statements; a -separate \texttt{} tag would refer to a loop.) Since the XML -file specifies statements only by source line number, -RoseHPCT::attachMetrics() attributes measurements to AST nodes in a -heuristic way. - -For example, lines 78--80 of Figure~\ref{Tutorial:roseHPCT:xml:cycles} -indicate that all executions of the ``simple statements'' of line 25 -of the original source (Figure~\ref{Tutorial:roseHPCT:profiled:aa}) -accounted for 65534 observed cycles, and that line 26 accounted for an -additional 65534 cycles. In the AST, there are multiple ``statement'' -and expression nodes that occur on line 25; indeed, -Figure~\ref{Tutorial:roseHPCT:profiled:out} lists 4 such -statements. - -The ROSE-HPCT modules uses a heuristic which only assigns \texttt{} metric values to non-scoping nodes derived from -SgStatement. When multiple SgStatement nodes occur at a particular -source line, -%ROSE-HPCT simply divides the observed metric equally among all the SgStatement nodes on that line. -ROSE-HPCT simply attaches the metric to each of them. -But only one of them will be used for propagating metrics to parent scopes. - -How is the measurement of 65534 cycles attributed to all of the AST -nodes corresponding to line 25 of -Figure~\ref{Tutorial:roseHPCT:profiled:aa}? Indeed, line 25 actually -``contains'' four different SgStatement nodes: an SgForStatement -representing the whole loop on lines 25--26, an SgForInitStatement -(initializer), and two SgExprStatements (one which is a child of the -SgForInitStatement, and another for the for-loop's test -expression). The loop's increment is stored in the SgForStatement node -as an SgExpression, not an SgStatement. The SgForStatement node is a -scoping statement, and so it ``receives'' none of the 65534 -cycles. Since the increment is not a statement and one of the -SgExprStatements is a child of the initializer, this leaves only two -direct descendants of the SgForStatement---the initializer and the -test expression statement---among which to divide the 65534 -cycles. Thus, each receives 32767 cycles. The initializer's -SgExprStatement child gets the same 32767 as its parent, since the two -nodes are equivalent (see first two cases of -Figure~\ref{Tutorial:roseHPCT:profiled:out}). - -For the entire loop on lines 25--26 of -Figure~\ref{Tutorial:roseHPCT:profiled:aa}, the original XML files -attribute 65534 cycles to line 25, and another 65534 cycles to line 26 -(see Figure~\ref{Tutorial:roseHPCT:xml:cycles}). Moreover, the XML -files do not attribute any costs to this loop \emph{via} an explicit -\texttt{} tag. Thus, the best we can infer is that the -entire for-statement's costs is the sum of its immediate child costs; -in this case, 131068 cycles. The RoseHPCT::attachMetrics() routine -will heuristically accumulate and propagate metrics in this way to -assign higher-level scopes approximate costs. - -The RoseHPCT::attachMetrics() routine automatically propagates metric -values through parent scopes. A given metric attribute, -RoseHPCT::MetricAttr* x, is ``derived'' through propagation if -x-$>$isDerived() returns true. In fact, if you call x-$>$toString() to -obtain a string representation of the metric's value, two asterisks -will be appended to the string as a visual indicator that the metric -is derived. We called RoseHPCT::MetricAttr::toString() on lines 27 and -29 of Figure~\ref{Tutorial:roseHPCT:attach}, and all of the -SgForStatement nodes appearing in the output in -Figure~\ref{Tutorial:roseHPCT:profiled:out} are marked as derived. - -Alternatively, you cann call RoseHPCT::attachMetricsRaw(), rather than -calling RoseHPCT::attachMetrics(). The ``raw'' routine takes the same -arguments but only attaches the raw data, \emph{i.e.}, without -attempting to propagate metric values through parent scopes. - -%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -\section{Working with GNU gprof} -ROSE-HPCT can also accept the line-by-line profiling output generated by -GNU gprof. -Currently, we only use the self seconds associated with each line -and attach them to ROSE AST as AST attributes named {\tt WALLCLK}. - -A typical session to generate compatible gprof profiling file for ROSE-HPCT -is given below: -\begin{verbatim} -[liao@codes]$ gcc -g seq-pi.c -pg -[liao@codes]$ ./a.out -[liao@codes]$ gprof -l -L a.out gmon.out &>profile.result -\end{verbatim} - -{\tt -l} tells gprof to output line-by-line profiling information and {\tt --L} causes gprof to output full file path information. - -An excerpt of an output file looks like the following: -{\scriptsize -\begin{verbatim} -Flat profile: - -Each sample counts as 0.01 seconds. - % cumulative self self total - time seconds seconds calls Ts/call Ts/call name - 38.20 8.84 8.84 jacobi (/home/liao6/temp/jacobi.c:193 @ 804899c) - 36.43 17.27 8.43 jacobi (/home/liao6/temp/jacobi.c:196 @ 8048a3f) - 11.00 19.82 2.54 jacobi (/home/liao6/temp/jacobi.c:188 @ 804893e) - 5.66 21.12 1.31 jacobi (/home/liao6/temp/jacobi.c:187 @ 8048968) - 3.93 22.04 0.91 jacobi (/home/liao6/temp/jacobi.c:197 @ 8048a71) - 3.24 22.79 0.75 jacobi (/home/liao6/temp/jacobi.c:191 @ 8048a7f) - 0.95 23.00 0.22 jacobi (/home/liao6/temp/jacobi.c:186 @ 8048976) - 0.50 23.12 0.12 jacobi (/home/liao6/temp/jacobi.c:187 @ 8048935) - 0.09 23.14 0.02 jacobi (/home/liao6/temp/jacobi.c:190 @ 8048a94) - 0.00 23.14 0.00 1 0.00 0.00 driver (/home/liao6/temp/jacobi.c:91 @ 8048660) - 0.00 23.14 0.00 1 0.00 0.00 error_check (/home/liao6/temp/jacobi.c:220 @ 8048b7c) - 0.00 23.14 0.00 1 0.00 0.00 initialize (/home/liao6/temp/jacobi.c:116 @ 8048722) - 0.00 23.14 0.00 1 0.00 0.00 jacobi (/home/liao6/temp/jacobi.c:160 @ 8048892) -\end{verbatim} -} - -%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -\section{Command-line options} -\label{sec:rosehpct:cmdlineopts} - -The call to RoseHPCT::loadProfilingFiles() on line 49 of -Figure~\ref{Tutorial:roseHPCT:attach} processes and extracts -ROSE-HPCT-specific command-line options. To generate the output in -this chapter, we invoked Figure~\ref{Tutorial:roseHPCT:attach} with -the following command-line: - -\verbatiminput{\TutorialExampleBuildDirectory/roseHPCT/command-line} - -The main option is \texttt{-rose:hpct:prof }, which specifies -the HPCToolkit-generated XML file containing metric data. Here, we use -this option twice to specify the names of the cycle and flop data -files -(Figures~\ref{Tutorial:roseHPCT:xml:cycles}--\ref{Tutorial:roseHPCT:xml:flops}). -To accept gprof output file, please use another option \texttt{-rose:gprof:linebyline }. -This option cannot be used with \texttt{-rose:hpct:prof } currently. - -We need the other option, \texttt{-rose:hpct:eqpath =}, to -specify how paths in the HPCToolkit XML files can be mapped to file -paths in the ROSE AST. -This option allows users to generate performance files on one machine and -analyze the results on another machine. -In this example, the XML -files specify the source file as, ``./profiled.c'' (line 73 of -Figures~\ref{Tutorial:roseHPCT:xml:cycles} -and~\ref{Tutorial:roseHPCT:xml:flops}); the ``eqpath'' command-line -option above remaps the relative path ``.'' to an absolute path as it -would appear in the ROSE AST. -Another example is to use the same performance file even after the original source tree is moved to another location. -ROSE-HPCT can still correctly match performance data if the root source paths are given as \texttt{-rose:hpct:eqpath =}. - -Yet another option \texttt{-rose:hpct:enable\_debug} is provided to display runtime debugging information -such as metrics reading, attaching, and propagating. -It also adds performance metrics into the ROSE output source file as source comments as shown below. -Users can examine the source comments to make sure performance metrics are attached and propagated properly. -As we can see, ROSE-HPCT attaches each performance metric to each matching statement. -If there are multiple statements showing in the same line, the same metric will be attached to each of them. -The metric propagation step will only propagate one of them to upper-level language constructs to ensure the correctness. - -{\scriptsize -\begin{verbatim} -/* ROSE-HPCT propagated metrics WALLCLK:18.95[SgForStatement at 0xb7beb218] */ - for ( -/* ROSE-HPCT raw data: Statement WALLCLK:0.02@File jacobi.c 190-0 -> SgForInitStatement 0x94e8d08 at 190 */ -i = 1; -/* ROSE-HPCT raw data: Statement WALLCLK:0.02@File jacobi.c 190-0 -> SgExprStatement 0x94516d8 at 190 */ -i < (n - 1); i++) -/* ROSE-HPCT propagated metrics WALLCLK:18.93[SgForStatement at 0xb7beb29c] */ - for ( -/* ROSE-HPCT raw data: Statement WALLCLK:0.75@File jacobi.c 191-0 -> SgForInitStatement 0x94e8d38 at 191 */ -j = 1; -/* ROSE-HPCT raw data: Statement WALLCLK:0.75@File jacobi.c 191-0 -> SgExprStatement 0x9451728 at 191 */ -j < (m - 1); j++) -/* ROSE-HPCT propagated metrics WALLCLK:18.18[SgBasicBlock at 0x93f60b4] */ -{ -/* ROSE-HPCT raw data: Statement WALLCLK:8.84@File jacobi.c 193-0 -> SgExprStatement 0x9451750 at 193 */ - resid = (((((ax * (((( *uold)[i - 1])[j]) + ((( *uold)[i + 1])[j]))) + (ay * (((( *uold)[i])[j - 1]) - + ((( *uold)[i])[j + 1])))) + (b * ((( *uold)[i])[j]))) - ((( *f)[i])[j])) / b); -/* ROSE-HPCT raw data: Statement WALLCLK:8.43@File jacobi.c 196-0 -> SgExprStatement 0x9451778 at 196 */ - (( *u)[i])[j] = (((( *uold)[i])[j]) - (omega * resid)); -/* ROSE-HPCT raw data: Statement WALLCLK:0.91@File jacobi.c 197-0 -> SgExprStatement 0x94517a0 at 197 */ - error = (error + (resid * resid)); - } -\end{verbatim} -} -% eof diff --git a/docs/Rose/Tutorial/tutorial.tex.in b/docs/Rose/Tutorial/tutorial.tex.in index 23dba4dde73..d781e726f57 100644 --- a/docs/Rose/Tutorial/tutorial.tex.in +++ b/docs/Rose/Tutorial/tutorial.tex.in @@ -331,18 +331,6 @@ debugging.} \input{codeCoverage} \input{bugSeeding} -%----------------------------------------------------------- -% Binary Support -%----------------------------------------------------------- -\part[Binary Support]{ Binary Support \\ -\vspace{1.0in} -\normalsize{Tutorials of using ROSE to handle binary executable files.} -} -\input{instructionSemantics} -\input{binaryAnalysis} -\input{binaryConstruction} -\input{dwarfDebugSupport} - %----------------------------------------------------------- % Interacting with Other Tools %----------------------------------------------------------- @@ -351,8 +339,6 @@ debugging.} \normalsize{How to build interoperable tools using ROSE.} } \input{abstractHandle} -\input{roseHPCT} -\input{tauInstrumentation} %----------------------------------------------------------- % Parallelism diff --git a/docs/Rose/UPCsupport.tex b/docs/Rose/UPCsupport.tex deleted file mode 100644 index 633c18ae9d8..00000000000 --- a/docs/Rose/UPCsupport.tex +++ /dev/null @@ -1,432 +0,0 @@ -\chapter{UPC Support} -\label{chap::upcsupport} - -%------------------------------------------------------------- -%------------------------------------------------------------- -\section{Introduction} -ROSE supports Unified Parallel C (UPC) programs. -UPC~\cite{UPC:Web} is a famous extension of the C99 programming language to support high performance computing using a partitioned global address space (PGAS) memory model. -ROSE leverages the EDG frontend to parse input UPC programs and generate EDG IR with UPC extensions. -It then converts the EDG IR into ROSE's internal AST and provides unparsing support for the AST. -An example UPC-to-C translator is also provided to demonstrate how one can use ROSE to -translate UPC programs into C programs with runtime calls to the Berkeley UPC (BUPC) runtime system V. 2.6.0~\cite{BUPC:Web}. -More information on UPC is availalbe from the language specification at: -\htmladdnormallink{UPC Language Specifications (pdf)}{http://www.gwu.edu/~upc/publications/LBNL-59208.pdf}. - -%------------------------------------------------------------- -%------------------------------------------------------------- -\section{Supported UPC Constructs} -% ROSE currently supports all UPC constructs as defined in UPC 1.1.1. -ROSE currently supports all UPC constructs as defined in UPC 1.2, using -all the standard header files: {\em upc.h}, {\em upc\_relaxed.h}, {\em upc\_strict.h}, -{\em upc\_collective.h}, {\em upc\_io.h}. Additional Non-standard Berkeley -UPC extensions are supported using the UCB {\em bupc\_extensions.h} header file. - -\footnote{ -The supported version is limited by the EDG -frontend, which only supports UPC 1.1.1 (\lstinline{__UPC_VERSION__} string -is defined as 200310L). -ROSE uses EDG 3.3 currently and it originally only supported UPC 1.0. -We merged the UPC 1.1.1 support from EDG 3.10 into our EDG 3.3 frontend. -%It seems like that the latest EDG 4.0 still only supports UPC 1.1.1 but we -%can easily extend it to support UPC 1.2 given the minor language changes from 1.1.1 to 1.2. -We have also added the required wotk to support UPC 1.2. Please let us know if anything is -left out and we will fix it.}. -A list of those UPC constructs and their corresponding ROSE AST representations are given below: -\begin{verbatim} -MYTHREAD SgUpcMythread -THREADS SgUpcThreads -upc_barrier SgUpcBarrierStatement -upc_blocksizeof SgUpcBlocksizeofExpression -upc_elemsizeof SgUpcElemsizeofExpression -upc_fence SgUpcFenceStatement -upc_forall SgUpcForAllStatement -upc_localsizeof SgUpcLocalsizeofExpression -upc_notify SgUpcNotifyStatement -upc_wait SgUpcWaitStatement -strict/relaxed/shared SgUPC_AccessModifier -UPC_MAX_BLOCKSIZE 1073741823 (~1GB) -\end{verbatim} -As we can see, most UPC constructs are represented by their corresponding dedicated ROSE AST nodes. -A few others, such as \lstinline{strict}, \lstinline{relaxed} and -\lstinline{shared}, are represented as instances of \lstinline{SgUPC_AccessModifier}. -\lstinline{UPC_MAX_BLOCKSIZE} is treated as a macro and is expanded to a predefined integer constant value. - -Much of the UPC language is supported via UPC specific language runtime -libraries. These calls are simply normal functions and not represented -as special UPC specific IR nodes. -Such runtime library function calls are, in general, -not a property of the UPC grammar and thus not represented in the AST -as specialized IR nodes. -The function names are those from the -UPC Langauge Specifications and so must be detected based on the function -name. No specialized support in currently present in ROSE to classify -these function or identify them as UPC secific, but such functionality -could be easily written. Such support could be added to the SageInteface. -If users write such specific support they are welcme to contribute it -back to ROSE. - -Alternatively ROSE provides function identification based on header files -where the declarations occured and this would be used to automate the recognition of UPC -specific runtime support functions. See the use of the {\em classifyFileName()} -function in {\em tests/nonsmoke/functional/roseTests/fileLocation\_tests} -directory for examples of how file names can be classified. Alternatively, -just the infomation in the source position reports the file name of the -original declaration and this can be used to identify specific functions as -defined in there associated header files, e.g. {\em upc\_collective.h}, -{\em upc\_io.h}, or {\em bupc\_extensions.h}. - -%------------------------------------------------------------- -%------------------------------------------------------------- -\section{Command Line Options} -ROSE can automatically recognize a source file with a suffix of \textit{.upc} as a UPC input and turn on its UPC support. -For other UPC files without the \textit{.upc} extension, a command line -option (\textit{-rose:UPC\_only or -rose:UPC}) is available to turn on the -UPC support explicitly. -In addition, \textit{-rose:upc\_threads n} can be used to enable ROSE's -support for UPC static threads compilation with n threads. - -%------------------------------------------------------------- -%------------------------------------------------------------- -\section{Example UPC Code Acceptable for ROSE} -We give some output after ROSE's source-to-source translation of some example UPC input. -These UPC input are actually some of ROSE's daily regression test input available from \textit{ROSE/tests/nonsmoke/functional/CompileTests/UPC\_tests}. - -Figure~\ref{Manual:UPC:hello} shows the output of the ROSE -identityTranslator handling a hello program in UPC. -\begin{figure}[!h] -{\indent - {\mySmallFontSize - \begin{latexonly} - \lstinputlisting{\TopBuildDirectory/tests/nonsmoke/functional/CompileTests/UPC_tests/rose_hello.upc} - \end{latexonly} - \begin{htmlonly} - \verbatiminput{\TopBuildDirectory/tests/tests/nonsmoke/functional/CompileTests/UPC_tests/rose_hello.upc} - \end{htmlonly} - } -} -\caption{Output of an UPC hello program} -\label{Manual:UPC:hello} -\end{figure} - -Figure~\ref{Manual:UPC:strict} shows the handling of UPC language -constructs related to memory consistency. -\begin{figure}[!h] -{\indent - {\mySmallFontSize - \begin{latexonly} - \lstinputlisting{\TopBuildDirectory/tests/nonsmoke/functional/CompileTests/UPC_tests/rose_consistency.upc} - \end{latexonly} - \begin{htmlonly} - \verbatiminput{\TopBuildDirectory/tests/tests/nonsmoke/functional/CompileTests/UPC_tests/rose_consistency.upc} - \end{htmlonly} - } -} -\caption{Output for UPC strict} -\label{Manual:UPC:strict} -\end{figure} - - -Figure~\ref{Manual:UPC:forall1} shows the use of \lstinline{upc_forall} -with \lstinline{continue} and Figure~\ref{Manual:UPC:forall2} shows the use -of \lstinline{upc_forall} with \lstinline{affinity}. - -\begin{figure}[!h] -{\indent - {\mySmallFontSize - \begin{latexonly} - \lstinputlisting{\TopBuildDirectory/tests/nonsmoke/functional/CompileTests/UPC_tests/rose_forall_continue.upc} - \end{latexonly} - \begin{htmlonly} - \verbatiminput{\TopBuildDirectory/tests/tests/nonsmoke/functional/CompileTests/UPC_tests/rose_forall_continue.upc} - \end{htmlonly} - } -} -\caption{Output for upc\_forall with continue} -\label{Manual:UPC:forall1} -\end{figure} - -\begin{figure}[!h] -{\indent - {\mySmallFontSize - \begin{latexonly} - \lstinputlisting{\TopBuildDirectory/tests/nonsmoke/functional/CompileTests/UPC_tests/rose_forall_affinity.upc} - \end{latexonly} - \begin{htmlonly} - \verbatiminput{\TopBuildDirectory/tests/tests/nonsmoke/functional/CompileTests/UPC_tests/rose_forall_affinity.upc} - \end{htmlonly} - } -} -\caption{Output for upc\_forall with affinity } -\label{Manual:UPC:forall2} -\end{figure} - -\clearpage -ROSE's support for various uses of \lstinline{shared} and unshared UPC -variables is given in -Figure~\ref{Manual:UPC:sharedaa} and Figure~\ref{Manual:UPC:sharedab}. -All kinds of shared, shared to shared, shared to private, and private to -shared variables can be correctly parsed and unparsed. -\begin{figure}[!h] -{\indent - {\mySmallFontSize - \begin{latexonly} - \lstinputlisting{\TopBuildDirectory/tests/nonsmoke/functional/CompileTests/UPC_tests/rose_shared.upc.aa} - \end{latexonly} - \begin{htmlonly} - \verbatiminput{\TopBuildDirectory/tests/tests/nonsmoke/functional/CompileTests/UPC_tests/rose_shared.upc.aa} - \end{htmlonly} - } -} -\caption{Output for UPC shared: part A} -\label{Manual:UPC:sharedaa} -\end{figure} - -\begin{figure}[!h] -{\indent - {\mySmallFontSize - \begin{latexonly} - \lstinputlisting{\TopBuildDirectory/tests/nonsmoke/functional/CompileTests/UPC_tests/rose_shared.upc.ab} - \end{latexonly} - \begin{htmlonly} - \verbatiminput{\TopBuildDirectory/tests/tests/nonsmoke/functional/CompileTests/UPC_tests/rose_shared.upc.ab} - \end{htmlonly} - } -} -\caption{Output for UPC shared: part B} -\label{Manual:UPC:sharedab} -\end{figure} - -\clearpage -Support for UPC \lstinline{lock}s is demonstrated in -Figure~\ref{Manual:UPC:lock}. -\begin{figure}[!h] -{\indent - {\mySmallFontSize - \begin{latexonly} - \lstinputlisting{\TopBuildDirectory/tests/nonsmoke/functional/CompileTests/UPC_tests/rose_lock.upc} - \end{latexonly} - \begin{htmlonly} - \verbatiminput{\TopBuildDirectory/tests/tests/nonsmoke/functional/CompileTests/UPC_tests/rose_lock.upc} - \end{htmlonly} - } -} -\caption{Output for UPC Locks} -\label{Manual:UPC:lock} -\end{figure} - -%------------------------------------------------------------- -%------------------------------------------------------------- -\clearpage -\section{An Example UPC-to-C Translator Using ROSE} -An example UPC-to-C translator, namely roseupcc, is provided to -demonstrate how one can use ROSE to build a translator translating UPC -programs into C programs with runtime calls to the Berkeley UPC (BUPC) -runtime system V. 2.6.0. -The source files of roseupcc are located in -\textit{ROSE/projects/UpcTranslation}. -%roseupcc follows the BUPC runtime interface specification -%3.10~\cite{BUPC3.10}. -%we don't reiterate details about why the translation is done in a certain way here. -Please be advised that only a subset of UPC (including variable handling) is -translated currently since the translator is meant to be a starting example. -Also variable handling is arguably the most difficult part of a UPC -implementation. - -Translation result for the UPC hello program (shown in -Figure~\ref{Manual:UPC:hello}) is given in Figure~\ref{Manual:UPC:hello-trans}. -Mostly, high level \lstinline{SageInterface} functions are used to -easily translate the ROSE AST. -BUPC-specified preprocessing directives, such as \lstinline{#include "upcr.h"} -and \lstinline{#define UPCR_WANT_MAJOR 3}, are inserted. -The original user main function is rewritten to \lstinline{user_main} with -runtime initialization (\lstinline{UPCR_BEGIN_FUNCTION}) and termination -(\lstinline{UPCR_EXIT_FUNCTION}) functions. -\lstinline{upc_barrier} is simply replaced with a call to its corresponding -runtime function \lstinline{upcr_barrier()}. -\lstinline{UPCRI_ALLOC_filename_xxx()} handles per file UPCRI allocation of -possible shared variables (none here). -\lstinline{UPCRI_INIT_filename_xxx()} function is used for per-file initialization of -shared and unshared (thread local) data. - -\begin{figure}[!h] -{\indent - {\mySmallFontSize - \begin{latexonly} - \lstinputlisting{\TopBuildDirectory/projects/UpcTranslation/tests/rose_hello.c} - \end{latexonly} - \begin{htmlonly} - \verbatiminput{\TopBuildDirectory/projects/UpcTranslation/tests/rose_hello.c} - \end{htmlonly} - } -} -\caption{Translation of upc hello} -\label{Manual:UPC:hello-trans} -\end{figure} - - -%\clearpage -Implementing various UPC variable accesses is complex due to the two level -memory scheme used by the partitioned global memory address space. -The translation has to handle variable declaration, memory allocation, -value initialization, variable access, and so on. - -UPC variables can be roughly categorized as shared and unshared (or thread -local) variables. -For shared variables, they can be divided into two categories: -statically allocated shared variables (including global shared variables -and local static shared variables) and dynamically allocated shared -variables. -%Runtime library routines are sufficient to support dynamically allocated -%shared variables. -We focus on statically allocated shared variables here as -an example. -%But extra compiler translation is needed for -%implementing statically allocated shared variables. -Translation of statically allocated \lstinline{shared} variables is demonstrated in -Figure~\ref{Manual:UPC:shared1-transaa} and -Figure~\ref{Manual:UPC:shared1-transab} for an input code shown in -Figure~\ref{Manual:UPC:shared1}. -\begin{figure}[!h] -{\indent - {\mySmallFontSize - \begin{latexonly} - \lstinputlisting{\TopSourceDirectory/projects/UpcTranslation/tests/shared_1.upc} - \end{latexonly} - \begin{htmlonly} - \verbatiminput{\TopSourceDirectory/projects/UpcTranslation/tests/shared_1.upc} - \end{htmlonly} - } -} -\caption{Example input for shared variables} -\label{Manual:UPC:shared1} -\end{figure} - -\begin{figure}[!h] -{\indent - {\mySmallFontSize - \begin{latexonly} - \lstinputlisting{\TopBuildDirectory/projects/UpcTranslation/tests/rose_shared_1.c.aaf} - \end{latexonly} - \begin{htmlonly} - \verbatiminput{\TopBuildDirectory/projects/UpcTranslation/tests/rose_shared_1.c.aaf} - \end{htmlonly} - } -} -\caption{Translation of UPC shared variables, part A} -\label{Manual:UPC:shared1-transaa} -\end{figure} - -The BUPC runtime distinguishes between phaseless (blocksize ==1 or 0 or -unspecified) and phased (all other cases) shared -pointers for better performance. -So two types of global scoped proxy pointers (\lstinline{upcr_pshared_ptr_t} -and \lstinline{upcr_shared_ptr_t}) are used to represent static shared variables. -Global static shared variables directly use their names as the proxy -pointer names (such as \lstinline{global_counter}). -Local static variables use their mangled name (e.g. \lstinline{_lsscounter3769188422_}) for those pointers to -avoid name collision. -Accesses to shared variables are implemented by a set of runtime library -calls, such as \lstinline{UPCR_GET_SHARED()} and -\lstinline{UPCR_PUT_SHARED_VAL}. -Again, as shown in Figure~\ref{Manual:UPC:shared1-transab}, \lstinline{UPCRI_ALLOC_filename_xxx()} handles per file UPCRI allocation of shared variables and -\lstinline{UPCRI_INIT_filename_xxx()} function is used for per-file -initialization of those data. - -ROSE provides a set of AST interface functions to help developers handle -UPC-specific types and facilitate translation. Those functions include -\lstinline{bool isUpcSharedType()}, -\lstinline{bool isUpcSharedArrayType()}, -\lstinline{bool isUpcPhaseLessSharedType()}, -\lstinline{bool isUpcPrivateToSharedType()}, etc. -A type mangling function (\lstinline{mangleType()}) is also provided -to implement the Itanium C++ ABI specification~\cite{ItaniumCppABI}. - -Unshared variables in UPC (also called Thread local data, or TLD) consists -of local auto variables and global ( and static local) variables. -Local auto variables do not need special translation. -But global and static local variables do. -Implementation details for them vary depending on their scope, internal or -external linkage, if they are scalar or array types, if they point to -shared data, if they have initializers, and so on. -But the basic scheme for variable declaration, allocation/initialization, and -accesses is similar to the handling of shared UPC variables. -Please refer to the BUPC runtime interface specification -3.10~\cite{BUPC3.10} for details. -We only provide a translation example in -Figure~\ref{Manual:UPC:unshared1-transaa} and -Figure~\ref{Manual:UPC:unshared1-transab} for an input code shown in -Figure~\ref{Manual:UPC:unshared1}. - -%No translations are needed for extern global unshared variables unless they -%are pointers to shared data. -%Local static unshared variables are promoted to non-static type at global -%scope using lstinline{UPCR_TLD_DEFINE or UPCR_TLD_DEFINE_TENTATIVE}) -%Unshared pointer to shared data - - -\begin{figure}[!h] -{\indent - {\mySmallFontSize - \begin{latexonly} - \lstinputlisting{\TopBuildDirectory/projects/UpcTranslation/tests/rose_shared_1.c.abf} - \end{latexonly} - \begin{htmlonly} - \verbatiminput{\TopBuildDirectory/projects/UpcTranslation/tests/rose_shared_1.c.abf} - \end{htmlonly} - } -} -\caption{Translation of UPC shared variables, part B} -\label{Manual:UPC:shared1-transab} -\end{figure} - -\begin{figure}[!h] -{\indent - {\mySmallFontSize - \begin{latexonly} - \lstinputlisting{\TopSourceDirectory/projects/UpcTranslation/tests/unshared_1.upc} - \end{latexonly} - \begin{htmlonly} - \verbatiminput{\TopSourceDirectory/projects/UpcTranslation/tests/unshared_1.upc} - \end{htmlonly} - } -} -\caption{Example input for non-shared variables} -\label{Manual:UPC:unshared1} -\end{figure} - -\begin{figure}[!h] -{\indent - {\mySmallFontSize - \begin{latexonly} - \lstinputlisting{\TopBuildDirectory/projects/UpcTranslation/tests/rose_unshared_1.c.aaf} - \end{latexonly} - \begin{htmlonly} - \verbatiminput{\TopBuildDirectory/projects/UpcTranslation/tests/rose_unshared_1.c.aaf} - \end{htmlonly} - } -} -\caption{Translation of UPC unshared variables, part A} -\label{Manual:UPC:unshared1-transaa} -\end{figure} - -\begin{figure}[!h] -{\indent - {\mySmallFontSize - \begin{latexonly} - \lstinputlisting{\TopBuildDirectory/projects/UpcTranslation/tests/rose_unshared_1.c.abf} - \end{latexonly} - \begin{htmlonly} - \verbatiminput{\TopBuildDirectory/projects/UpcTranslation/tests/rose_unshared_1.c.abf} - \end{htmlonly} - } -} -\caption{Translation of UPC unshared variables, part B} -\label{Manual:UPC:unshared1-transab} -\end{figure} - - -%------------------------------------------------------------- -%------------------------------------------------------------- -%\section{Summary} - diff --git a/docs/Rose/binaryAnalysis.tex b/docs/Rose/binaryAnalysis.tex deleted file mode 100644 index e1ed871ba7a..00000000000 --- a/docs/Rose/binaryAnalysis.tex +++ /dev/null @@ -1,486 +0,0 @@ - -\chapter{Binary Analysis: Support for the Analysis of Binary Executables} - -\label{binaryAnalysis::overview} - -\section{Introduction} - - ROSE supports the disassembly and analysis of binary executables for x86, PowerPC, and AMR -instruction sets. ROSE implements this support as part of general research work -to support combining analysis for source code and analysis for binaries and supporting -performance analysis and optimization. Through this support ROSE addresses the -requirements for the analysis and transformation of software in a general context useful -to as wide a group of users as possible. - - ROSE handles a number of binary executable file formats and also reads Dwarf information -into the AST to support additional analysis. - - Recent work in ROSE has added support for dynamic analysis and for mixing of dynamic -and static analysis using the Intel Pin framework. -Intel Pin support in ROSE is presented in section~\ref{intel_pin}. - -\section{The Binary AST} - -\subsection{The Binary Executable Format} - - ROSE handles Linux and Windows binary formats; thus ELF format for Linux and PE, NE, -LE, DOS formats for Windows. The details of each format are represented in IR nodes in -the AST (using structures common to the representation of such low level data). About -60 IR nodes have been added to ROSE to support the binary executable formats; this -support allows the analysis of any Linux, Windows, OS\/2, or DOS binary executable. - - The binary executable file format can be analyzed separately from the instructions -using the command line option: {\tt -rose:read\_executable\_file\_format\_only}. This -allows graphs generated using the ROSE visualization mechanisms (and even some analysis) -to be easily restricted (in size) to the just the IR nodes specific to the binary -executable file format. - -% \fixme{We need an example of the binary executable format AST.} - -\begin{figure} -% \includegraphics[angle=90,scale=0.75,width=5in,height=1in]{\TopSourceDirectory/src/frontend/ExecFormats/BinaryFileFormat} -\includegraphics[angle=90,width=7.5in,height=8.5in]{\TopSourceDirectory/src/frontend/BinaryFormats/BinaryFileFormat} -\caption{The class design of the IR nodes for the binary file format.} - -\label{binaryAnalysis:BinaryExecutableFormatDesign} -\end{figure} - -Figure \ref{binaryAnalysis:BinaryExecutableFormatDesign} shows the class design of the IR -nodes for the binary file format address the -requirements of ELF (Linux, and others), PE (MS Windows), NE (older MS Windows), -LE (OS\/2), and DOS (MS Dos) executable formats. The colors represent different -executable formats, brown classes are used as base classes for more than one -format. Dark colors represent principle IR nodes in the AST, lighter color IR nodes -represent supporting infrastructure in the AST. Arrows are either dark colored or -light colored; dark colors represent class derivation, and light colors represent -member relationships. - -% DQ (10/29/2008): Added documentation for file format (plus examples). -% This figure uses a saved (static) pdf file (not generated during the ``make docs'' rule). -% This was done because it is cropped using predefined pixel values which would not be -% easy to generate for a pdf that might be constantly changed. -\begin{figure} -% \includegraphics[angle=90,scale=0.75,width=5in,height=1in]{\TopSourceDirectory/src/frontend/ExecFormats/BinaryFileFormat} -% \includegraphics[scale=0.50]{\TopSourceDirectory/docs/Rose/asm_code_samples_gcc} -\includegraphics[,viewport=5 1 100 30,scale=2]{\TopSourceDirectory/docs/Rose/asm_code_samples_gcc} -\caption{The AST for a PE (Windows) binary executable (binary file format only), with long - list of symbols (half of which are clipped on the right side of the image).} - -\label{binaryAnalysis:BinaryExecutableFormatAST_1} -\end{figure} - -Figure \ref{binaryAnalysis:BinaryExecutableFormatAST_1} shows the graph of the AST -formed by just the binary file format (sections, symbols, etc.). This figure shows -the different IR nodes used to represent the binary file format (without the disassembled -instructions, in this case) and the large list of symbols within the symbol table (the -long list that is partially truncated on the right edge of the figure). -This graph is quite large and does not fit well on the page, the next figure -\ref{binaryAnalysis:BinaryExecutableFormatAST_2} shows a clipped image with more detail. - - -\begin{figure} -% \includegraphics[angle=90,scale=0.75,width=5in,height=1in]{\TopSourceDirectory/src/frontend/ExecFormats/BinaryFileFormat} -\includegraphics*[angle=90,viewport=5 1 40 30,scale=18]{\TopSourceDirectory/docs/Rose/asm_code_samples_gcc} -\caption{The CROPPED AST for a PE (Windows) binary executable (binary file format only).} - -\label{binaryAnalysis:BinaryExecutableFormatAST_2} -\end{figure} - -Figure \ref{binaryAnalysis:BinaryExecutableFormatAST_2} shows a cropped view of the graph -of the AST formed by just the binary file format (sections, symbols, etc.). This figure -shows two {\em SgAsmInterpretation} IR nodes; this is a Windows PE binary and all windows -PE binaries contain both a 16-bit MS-DOS header (and some 16-bit code) and a 32-bit Windows -PE header (with sections that have 32-bit code); thus there are two SgAsmInterpretation IR -nodes (one for the 16-bit interpretation of the instructions and one for the 32-bit -interpretation of the instructions). Note that ELF format files will have only one -SgAsmInterpretation IR nodes (because there is only a single interpretation possible), but -other file formats can contain many interpretations; formed form a composite of code to -support wide ranges of portability. - -*Note: The actually file used is in these figures is: {\tt ROSE/docs/Rose/asm\_code\_samples\_gcc.pdf}. - -\subsection{Instruction Disassembly} - -See API documentation for Rose::BinaryAnalysis::Disassemble. - -\subsection{Instruction Partitioning} - -See API documentation for Rose::BinaryAnalysis::Partitioner2. - -\subsection{Dwarf Debug Support} -% NOTE: - - ROSE can now read the Dwarf debug information stored into binary executables (ELF only -at this point). This information is represented as Dwarf specific IR nodes in the AST and -thus can be optionally used (when it is available in the binary) as part of any binary -analysis. Only a few sections are supported at present: {\em .debug\_info}, -{\em .debug\_line}, etc. The dwarf support in ROSE uses {\em libdwarf} and is enabled in -ROSE using a configuration option: {\tt (configure --with-dwarf={\em}}. -Note that {\em libdwarf} is optional, must be separately installed by the user, and -thus is obviously not distributed within ROSE. -% The future of the Dwarf support in ROSE is not clear, -We anticipate the Dwarf information in the AST to be useful for performance tools that -operate on the binary executable when the binary executable has been generated to include -Dwarf debug information. - -\section{Binary Analysis} - -See API documentation for Rose::BinaryAnalysis. - -\section{Compass as a Binary Analysis Tool} - - Compass is a tool framework for building software analysis tools using rules (on source -code and alternatively directly on binary executables). Compass -reports violations of the rules in the evaluation of the software. Compass is a -relatively simple application built on top of ROSE. Most of the complexity and code -within Compass is that it includes a large collection to rules, each rule has its -own implementation of an arbitrary test over the source code or the binary. Rules -(checkers) may be defined over the AST or any other graph built within ROSE to store -program analysis information. See the Compass manual for more details on supported -binary analysis. The ability to perform analysis of binary executables using Compass -makes no assumptions that it is compiled with any specific options or that it contains -debug information, symbols, etc. - - -\section{Static Binary Rewriting} - As part of general research on transformations of binaries (separate from analysis) -a number of techniques have been developed to support classes of transformations. -This static rewriting of the binary permits the development of performance tools -that could support the analysis and rewriting of binaries for support of High -Performance Computing (HPC). A principal focus is on IBM BGL and Cray XT support -(DOE Office of Science supercomputers). - -\subsection{Generic Section/Segment Modifications} -%=============================================================================================================================== -%Generic Section/Segment Modifications -%=============================================================================================================================== - -\subsubsection{1a. Section/Segment file address shifting (low-level)} - - The low-level movement of an ELF Section or Segment within the file address space is performed with - SgAsmGenericSection::set\_offset. It changes the location of the section in the file and updates all relative virtual - addresses (RVAs) that were primarily associated with the moved section. - - The main problems with this function are that it doesn't take into account the file locations of other sections, the file - alignment constraints of the moved section, or the memory mapping. Specifically, after calling this function to move {\bf.text} - one byte later in the file: -\begin{itemize} - \item {\bf.text} might not satisfy its file alignment constraint. - - \item The end of {\bf.text} might overlap with the following section. The ELF unparser has undefined behavior when two sections - overlap without storing identical bytes at the overlapping regions. - - \item {\bf.text}, if memory mapped (which it surely is), might not be consistent with the mapping of other adjacent or overlapping - sections. For instance, {\bf.text} is contained in "ELF Load Segment 2" both in the file address space and in the mapped - memory space. The offset from ELF Load Segment 2 to {\bf.text} must be identical in both file and memory. - - \item RVAs that point to instructions in {\bf.text} can be associated with the {\bf.text} section or with ELF Load Segment 2, - depending on how they were parsed. Normally it doesn't matter which since the relationship between file address space and - memory address space is consistent. But if you change the file addresses without changing memory addresses then the byte - to which the RVA points could be ambiguous. -\end{itemize} - - Changes to ELF Section or Segment file addresses are reflected in the ELF Section Table and/or ELF Segment Table. If the - particular SgAsmGenericSection is present in both tables then modifying its file address will result in updates to both - tables. - - NOTE: Do not modify section offsets and sizes by modifying the section table entries. Changes to these values will be - overwritten with actual, current section offsets and sizes when the section table is unparsed: -\begin{itemize} - \item SgAsmElfSectionTableEntry::set\_sh\_offset - \item SgAsmElfSectionTableEntry::set\_sh\_size - \item SgAsmElfSectionTableEntry::set\_sh\_addr -\end{itemize} - - NOTE: Do not modify segment offsets and sizes by modifying the segment table entries. Changes to these values will be - overwritten with actual, current segment offsets and sizes when the segment table is unparsed: -\begin{itemize} - \item SgAsmElfSegmentTableEntry::set\_offset - \item SgAsmElfSegmentTableEntry::set\_filesz - \item SgAsmElfSegmentTableEntry::set\_vaddr - \item SgAsmElfSegmentTableEntry::set\_memsz -\end{itemize} - -\subsubsection{1b. Section/Segment file address shifting (high-level)} - - The SgAsmGenericFile::shift\_extend method is the preferred way to make minor offset and/or size adjustments to an ELF - Section or Segment. It is able to shift a section to a high file and/or memory address and/or extend the segment: -\begin{itemize} - \item It takes into account all sections in the file, adjusting their offsets and/or sizes accordingly. - - \item Sections to the right of the the section in question (Sq) are shifted upward to make room and prevent overlaps. - - \item Sections overlapping with Sq are extended to contain all of what they previously contained. - - \item The shift amounts are adjusted to satisfy alignment constraints of all affected sections. - - \item Unreferenced areas of the file can optionally be utilized as unused address space. - - \item Adjusting file address spaces also adjusts the memory address spaces in a compatible manner. -\end{itemize} - - NOTE: Do not modify section offsets and sizes by modifying the section table entries. Changes to these values will be - overwritten with actual, current section offsets and sizes when the section table is unparsed: -\begin{itemize} - \item SgAsmElfSectionTableEntry::set\_sh\_offset - \item SgAsmElfSectionTableEntry::set\_sh\_size - \item SgAsmElfSectionTableEntry::set\_sh\_addr -\end{itemize} - - NOTE: Do not modify segment offsets and sizes by modifying the segment table entries. Changes to these values will be - overwritten with actual, current segment offsets and sizes when the segment table is unparsed: -\begin{itemize} - \item SgAsmElfSegmentTableEntry::set\_offset - \item SgAsmElfSegmentTableEntry::set\_filesz - \item SgAsmElfSegmentTableEntry::set\_vaddr - \item SgAsmElfSegmentTableEntry::set\_memsz -\end{itemize} - -\subsubsection{2a. Section/Segment resizing (low-level)} - - The size of an ELF Section or Segment can be modified by calling SgAsmGenericSection::set\_size (for file size) and - set\_mapped\_size (for mapped memory). However, this is a low-level interface that doesn't take into account other sections in - the same file. The preferred way to resize a section is with SgAsmGenericFile::shift\_extend. - - NOTE: For many kinds of sections, making the section larger will create an unreferenced area ("internal hole") at the end of - the section. Other sections will automatically do something with the new address space (e.g., SgAsmElfStringSection will - add the new address space to its free list). - -\subsubsection{2b. Section/Segment resizing (high-level)} - - The preferred way to extend a section is to call SgAsmGenericFile::shift\_extend, which extends sections that contain the - resized-section and shifts sections that are right (higher address) of the resized-section. This function also takes into - account alignment constraints, memory address space, and (optionally) holes in the address space. - -\subsection{Modifications to the ELF File Header} -%=============================================================================================================================== -%Modifications to the ELF File Header -%=============================================================================================================================== - -\subsubsection{1. Entry Point RVA} - - The entry RVA stored in the ELF File Header is adjusted whenever the section into which it points is moved in memory. It is - also possible to adjust this address explicitly by modifying the first (and only) entry in SgAsmGenericHeader::entry\_rvas. - - NOTE: An RVA (rose\_rva\_t) is an offset with respect to the beginning of some section. If the section starting memory address - changes then the RVA implicitly changes (RVA's are virtual addresses relative to some format-wide base address). Multiple - sections can be mapped to the same memory (e.g., {\bf.text} and {\bf ELF Load Segment 2} are typically overlap in memory), but - since an RVA is associated with only one section, modifying the other section(s) has no effect on the RVA even if the RVA - happens to be inside the other sections as well. - - NOTE: The binding between an RVA and a section can be modified with rose\_rva\_t::set\_section. In fact, the link can be - completely broken by passing a null section pointer, in which case the RVA is not relative to any section. - -\subsubsection{2. File Format Byte order} - - File byte order can be changed by modifying the SgAsmGenericFormat object pointed to by the file header: - - SgAsmGenericHeader *fhdr = ....; - fhdr->get\_exec\_format()->set\_sex(ORDER\_MSB); - - NOTE: Modifying the byte order affects only those sections that are actually parsed. If the ELF file contains a section - whose purpose we don't recognize then the original section data is written to the new file. - -\fixme{If the byte order is not specified in the ELF header (e\_ident\_data\_encoding other than 1 or 2) then the parser will - make an educated guess and assign a byte order. The unparsed file will differ from the original in this case at the sixth - byte of the file.} - -\subsubsection{3. ELF Word Size} - - File word size can be changed between 4 bytes and 8 bytes by modifying the SgAsmGenericFormat object pointed to by the file - header: - - SgAsmGenericHeader *fhdr = ....; - fhdr->get\_exec\_format()->set\_word\_size(4); - - When changing word sizes, any fields that have values too large to represent in the new word size will cause the unparser - to abort. - - NOTE: Modifying the word size affects only those sections that are actually parsed. If the ELF file contains a section whose - purpose we don't recognize then the original section data is written to the new file. - -\fixme{Increasing word size probably requires allocating more space for many of the sections. Vice versa for decreasing the - word size.} - -\subsubsection{4. ELF Header Magic Number} - - An ELF header has a four-byte magic number, usually 0x7f, 'E', 'L', 'F'. The magic number can be modified by changing the - string from SgAsmGenericHeader::get\_magic. It must be exactly four characters in length. - -\subsubsection{5. ELF File Purpose (lib, executable, core, etc.)} - - The file purpose should be modified by setting two fields, using - -\begin{enumerate} - \item SgAsmElfFileHeader::set\_p\_e\_type - \item SgAsmGenericFormat::set\_purpose -\end{enumerate} - - Both members should be set to compatible values. The former is the value from the ELF specification and the latter is a - constant: PURPOSE\_UNSPECIFIED, PURPOSE\_LIBRARY, PURPOSE\_EXECUTABLE, PURPOSE\_CORE\_DUMP, PURPOSE\_PROC\_SPECIFIC, PURPOSE\_OTHER. - -\fixme{set\_p\_e\_type should probably call set\_purpose, but we can't go the other direction because the mapping is N:1.} - -\subsubsection{6. ELF Version} - - To change the ELF version assign a new value by calling set\_version on the object returned by - SgAsmGenericHeader::get\_exec\_format. This doesn't have any effect on the code generated by the unparser since the parser - only knows about ELF format 1. - -\subsubsection{7. ELF Target Architecture} - - Modify the target architecture by calling two functions: - - SgAsmElfHeader::set\_e\_machine -- sets the ELF specific value - SgAsmGenericHeader::set\_isa -- sets the generic value - - You should call both with consistent values. - -\subsubsection{8. ELF Section or Segment Table location} - - The SgAsmElfFileHeader::set\_e\_shoff and set\_e\_phoff methods have been removed since calling them had no lasting effect - anyway. Instead, if you want to change one of these values for unparsing, then modify the actual SgAsmGenericSection that - holds the table (e.g., calling SgAsmGenericFile::shift\_extend). - -\subsubsection{9. ELF Section or Segment Table size} - - The number of entries in the section or segment table cannot be modified by calling set\_e\_shnum or set\_e\_phnum on the - SgAsmElfFileHeader \fixme{Remove these functions.}. Rather, the sizes are obtained by looking at what sections and segments - are currently defined and writing an entry to the file for each one. - -\subsubsection{10. ELF Section Names} - - Elf section names can be modified. Doing so may cause extensive changes to the executable due to reallocation of the section - holding the string table. - - Do not call SgAsmElfSectionTableEntry::set\_sh\_name since that value will be overwritten based on the actual, current - location of the name in the associated string table. - -\subsubsection{11. ELF Segment Names} - - ELF segment names are often parser-generated based on constants in the ELF Segment Table. However, if the segment - corresponds to an actual ELF Section defined in the ELF Section Table then the segment and section share the same - SgAsmGenericSection object and changing the name causes the ELF Section name to change with no effect on the segment table. - -\subsubsection{12. ELF Section Name Table} - - The section that holds the section names is identified in the ELF File Header (get\_e\_shstrndx). Although it is possible to - change this value, doing so will have no effect on the currently-defined sections: they will continue to use the original - string table for their names. - -\subsection{Modifications to ELF String Tables and their Containing Sections} -%=============================================================================================================================== -%Modifications to ELF String Tables and their Containing Sections -%=============================================================================================================================== - -\subsubsection{1. Move/Extend} - - See SgGenericFile::shift\_extend. When a string table is extended the new address space is added to the table's free list. - -\subsubsection{2. New String} - - A new string can be created by calling the SgAsmStoredString allocator and passing a string table (something derived from - SgAsmGenericStrtab) and the initial string value. The string is not actually allocated space in the file until the new file - is unparsed or until someone calls SgAsmStoredString::get\_offset. - -\subsubsection{3. Value modification} - - A string can be modified by assigning a new value via SgAsmStoredString::set\_string. Storage is not allocated for the new - value until the AST is unparsed or someone calls SgAsmStoredString::get\_offset. The previous value is freed. - -\subsubsection{4. Shared strings} - - Three forms of sharing are supported: - -\begin{enumerate} - \item Two objects (section names, symbol names, etc) share the same string and changing one string causes the other to change - as well. This kind of sharing is not typically encountered in ELF although the underlying string table classes support - it. - - \item Two objects have independent strings that happen to have the same value and point to the same offset in the string - table. In this case, changing one string doesn't change the other. This kind of sharing is often encountered in ELF. - - \item Two objects have independent strings and one is an ending substring of another (e.g., "main" and "domain"). Changing one - string does not affect the other. This kind of sharing is also common in ELF. -\end{enumerate} - -\subsubsection{5. String table internal holes} - - If a sequence of bytes in a string table is not referenced by anything known to the parser, then those bytes are marked as - internal holes and are prevented from moving with respect to the beginning of the string table. Internal holes are not - placed on the string table free list (because something we didn't parse might be pointing to them). The internal holes are - available with SgAsmGenericSection::congeal. - -\subsubsection{6. Reallocation of all strings} - - A string table can be repacked by freeing all it's strings and then reallocating. We can reallocate around the internal - holes or through the internal holes. - - strtab.free\_all\_strings(); /* free\_all\_strings(true) blows away internal holes */ - strtab.reallocate(); - - The ELF allocator will do its best to overlap storage (e.g., "domain" overlaps with "main"). - -\subsubsection{7. Deletion of a string} - - A string is deleted by changing its value to the empty string. - -\subsubsection{8. Stored strings vs. non-stored strings.} - - If a string value has storage space in a file (such as an ELF Section name), then it's an instance of - SgAsmStoredString. Otherwise the string is either an std::string or SgAsmBasicString. SgAsmBasicString and SgAsmStoredString - both derive from SgAsmGenericString. Changing the value of an SgAsmBasicString has no effect on the unparsed file. - -\subsection{Modifications ELF Section Table Entries} -%=============================================================================================================================== -%Modifications ELF Section Table Entries -%=============================================================================================================================== - -Every ELF Section defined by the ELF Section Table is parsed as an SgAsmElfSection, which is derived from SgAsmGenericSection. -The SgAsmElfSection::get\_section\_entry returns a pointer to the ELF Section Table Entry (SgAsmElfSectionTableEntry). Some -members of these objects can be modified and some can't. - -\subsubsection{1. These functions should not be called since their values are overwritten during the unparse phase:} - -\begin{itemize} - \item SgAsmElfSectionTableEntry::set\_sh\_name -- see SgAsmGenericSection::set\_name - \item SgAsmElfSectionTableEntry::set\_sh\_addr -- see SgAsmGenericFile::shift\_extend - \item SgAsmElfSectionTableEntry::set\_sh\_offset -- see SgAsmGenericFile::shift\_extend - \item SgAsmElfSectionTableEntry::set\_sh\_size -- see SgAsmGenericFile::shift\_extend - \item SgAsmElfSectionTableEntry::set\_sh\_link -- don't call (no alternative yet) -\end{itemize} - -\subsubsection{2. Can modify} - -\fixme{What text should go here?} - -\begin{itemize} - \item SgAsmElfSectionTableEntry::set\_sh\_type - \item SgAsmElfSectionTableEntry::set\_sh\_flags, although the Write and Execute bits are ignored - \item SgAsmElfSectionTableEntry::set\_sh\_info \fixme{Is this complete?} - \item SgAsmElfSectionTableEntry::set\_sh\_addralign \fixme{Is this complete?} - \item SgAsmElfSectionTableEntry::set\_sh\_entsize \fixme{Is this complete?} -\end{itemize} - - -\section{Dynamic Analysis Support} -\label{intel_pin} - - Recent work in ROSE has added support for dynamic analysis and for mixing of dynamic -and static analysis using the Intel Pin framework. This optional support in ROSE -requires a configure option ({\tt --with-IntelPin=$}. The {\tt path} in -the configure option is the path to the top level directory of the location of -the Intel Pin distribution. This support for Intel Pin has only been tested -on a 64bit Linux system using the most recent distribution of Intel Pin (version 2.6). - -Note: The dwarf support in ROSE is currently incompatible with the dwarf support in -Intel Pin. A message in the configuration of ROSE will detect if both support for -Dwarf and Intel Pin are both specified and exit with an error message that they -are incompatible options. - - -\section{Usage} - See the ROSE Tutorial for examples. - - - diff --git a/docs/Rose/documents.html b/docs/Rose/documents.html index 49bcd0222a0..951a154ccdd 100644 --- a/docs/Rose/documents.html +++ b/docs/Rose/documents.html @@ -39,11 +39,6 @@
  • Tutorials (pdf)
  • Doxygen Documentation ROSE (html)
    • -
  • Doxygen Documentation for ROSE Qt Widgets (html)
    • -
  • Doxygen Documentation for ROSE Haskell Binding API (html)
    • -
  • Compass Manual (pdf)
    • -
  • Autotuning Tutorials (pdf)
    • -
  • QROSE Manual (pdf)

    •  

     

    diff --git a/docs/Rose/projects.html b/docs/Rose/projects.html deleted file mode 100644 index 8067accd645..00000000000 --- a/docs/Rose/projects.html +++ /dev/null @@ -1,66 +0,0 @@ - - - - -ROSE Projects - - - - - - - - - - - - - - - - - - - -
    - - - -   - - - - -
    -

    ROSE has been used to facilitate a number of projects for exploring program analyses and optimizations, supporting new programming languages, and building correctness and performance tools. Representative examples include: -

    -

      -
    • Compass: a tool for the checking of source code. - Compass is based on the ROSE compiler infrastructure and demonstrates the use of ROSE - to build many simple pattern detectors for analysis of C, C++, and Fortran - source code. See the current Compass Manual for details.
      • -
    • Whole-program empirical optimization: participation in the PERI project. - ROSE is a central component in the PERI project to enable performance portability of DOE applications - through an empirical optimization system, - which incorporates a set of external tools interacting with ROSE to - support the entire life-cycle of automated empirical optimization. - See the current draft autotuning tutorial for details. -
      • -
    • Loop optimizer: support for aggressive loop optimizations such as loop fusion, - fission, unrolling and blocking. An extended dependence analysis algorithm has been implemented to support both perfectly nested loops and irregular loop nests.
      • -
    • OpenMP: a project to support OpenMP using ROSE. ROSE already has a lightweight parser for OpenMP C/C++ pragmas and a translator for OpenMP 2.5 constructs. We are extending it to support Fortran and the new OpenMP 3.0 specification.
      • -
    • UPC: ongoing work to support UPC using ROSE. We are leveraging the existing UPC support available in the EDG frontend to build an environment for program analysis and optimizations for UPC applications.
      • -
    • Haskellport: an interface to ROSE's IR for the Haskell programming language. See the tutorial (a chapter of the ROSE Tutorial) and API documentation for details. -
    • Windows support: We are currently working to support ROSE under Windows using Visual Studio (via CMake generation of the MSVC Solutions file)
      • -

    -
    - -
    - - diff --git a/docs/Rose/rose.cfg.in b/docs/Rose/rose.cfg.in index f71223e73a0..cde451f6382 100644 --- a/docs/Rose/rose.cfg.in +++ b/docs/Rose/rose.cfg.in @@ -1,117 +1,137 @@ -# Doxyfile 1.8.1.1 -# -# This is the minimum doxygen version supported by ROSE. Newer -# versions of doxygen will probably produce warnings about certain -# things in this file. Do not regenerate this file to a newer version -# without prior discussion. [The ROSE Team] - - +# Doxyfile 1.9.1 # This file describes the settings to be used by the documentation system # doxygen (www.doxygen.org) for a project. # -# All text after a hash (#) is considered a comment and will be ignored. +# All text after a double hash (##) is considered a comment and is placed in +# front of the TAG it is preceding. +# +# All text after a single hash (#) is considered a comment and will be ignored. # The format is: -# TAG = value [value, ...] -# For lists items can also be appended using: -# TAG += value [value, ...] -# Values that contain spaces should be placed between quotes (" "). +# TAG = value [value, ...] +# For lists, items can also be appended using: +# TAG += value [value, ...] +# Values that contain spaces should be placed between quotes (\" \"). #--------------------------------------------------------------------------- # Project related configuration options #--------------------------------------------------------------------------- -# This tag specifies the encoding used for all characters in the config file -# that follow. The default is UTF-8 which is also the encoding used for all +# This tag specifies the encoding used for all characters in the configuration +# file that follow. The default is UTF-8 which is also the encoding used for all # text before the first occurrence of this tag. Doxygen uses libiconv (or the # iconv built into libc) for the transcoding. See -# http://www.gnu.org/software/libiconv for the list of possible encodings. +# https://www.gnu.org/software/libiconv/ for the list of possible encodings. +# The default value is: UTF-8. DOXYFILE_ENCODING = UTF-8 -# The PROJECT_NAME tag is a single word (or sequence of words) that should -# identify the project. Note that if you do not use Doxywizard you need -# to put quotes around the project name if it contains spaces. +# The PROJECT_NAME tag is a single word (or a sequence of words surrounded by +# double-quotes, unless you are using Doxywizard) that should identify the +# project for which the documentation is generated. This name is used in the +# title of most generated pages and in a few other places. +# The default value is: My Project. PROJECT_NAME = ROSE -# The PROJECT_NUMBER tag can be used to enter a project or revision number. -# This could be handy for archiving the generated documentation or -# if some version control system is used. +# The PROJECT_NUMBER tag can be used to enter a project or revision number. This +# could be handy for archiving the generated documentation or if some version +# control system is used. PROJECT_NUMBER = @VERSION@ # Using the PROJECT_BRIEF tag one can provide an optional one line description -# for a project that appears at the top of each page and should give viewer -# a quick idea about the purpose of the project. Keep the description short. +# for a project that appears at the top of each page and should give viewer a +# quick idea about the purpose of the project. Keep the description short. PROJECT_BRIEF = -# With the PROJECT_LOGO tag one can specify an logo or icon that is -# included in the documentation. The maximum height of the logo should not -# exceed 55 pixels and the maximum width should not exceed 200 pixels. -# Doxygen will copy the logo to the output directory. +# With the PROJECT_LOGO tag one can specify a logo or an icon that is included +# in the documentation. The maximum height of the logo should not exceed 55 +# pixels and the maximum width should not exceed 200 pixels. Doxygen will copy +# the logo to the output directory. PROJECT_LOGO = -# The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute) -# base path where the generated documentation will be put. -# If a relative path is entered, it will be relative to the location -# where doxygen was started. If left blank the current directory will be used. +# The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute) path +# into which the generated documentation will be written. If a relative path is +# entered, it will be relative to the location where doxygen was started. If +# left blank the current directory will be used. OUTPUT_DIRECTORY = ./ROSE_WebPages -# If the CREATE_SUBDIRS tag is set to YES, then doxygen will create -# 4096 sub-directories (in 2 levels) under the output directory of each output -# format and will distribute the generated files over these directories. -# Enabling this option can be useful when feeding doxygen a huge amount of -# source files, where putting all generated files in the same directory would -# otherwise cause performance problems for the file system. +# If the CREATE_SUBDIRS tag is set to YES then doxygen will create 4096 sub- +# directories (in 2 levels) under the output directory of each output format and +# will distribute the generated files over these directories. Enabling this +# option can be useful when feeding doxygen a huge amount of source files, where +# putting all generated files in the same directory would otherwise causes +# performance problems for the file system. +# The default value is: NO. + +CREATE_SUBDIRS = YES + +# If the ALLOW_UNICODE_NAMES tag is set to YES, doxygen will allow non-ASCII +# characters to appear in the names of generated files. If set to NO, non-ASCII +# characters will be escaped, for example _xE3_x81_x84 will be used for Unicode +# U+3044. +# The default value is: NO. -CREATE_SUBDIRS = NO +ALLOW_UNICODE_NAMES = NO # The OUTPUT_LANGUAGE tag is used to specify the language in which all # documentation generated by doxygen is written. Doxygen will use this # information to generate all constant output in the proper language. -# The default language is English, other supported languages are: -# Afrikaans, Arabic, Brazilian, Catalan, Chinese, Chinese-Traditional, -# Croatian, Czech, Danish, Dutch, Esperanto, Farsi, Finnish, French, German, -# Greek, Hungarian, Italian, Japanese, Japanese-en (Japanese with English -# messages), Korean, Korean-en, Lithuanian, Norwegian, Macedonian, Persian, -# Polish, Portuguese, Romanian, Russian, Serbian, Serbian-Cyrillic, Slovak, -# Slovene, Spanish, Swedish, Ukrainian, and Vietnamese. +# Possible values are: Afrikaans, Arabic, Armenian, Brazilian, Catalan, Chinese, +# Chinese-Traditional, Croatian, Czech, Danish, Dutch, English (United States), +# Esperanto, Farsi (Persian), Finnish, French, German, Greek, Hungarian, +# Indonesian, Italian, Japanese, Japanese-en (Japanese with English messages), +# Korean, Korean-en (Korean with English messages), Latvian, Lithuanian, +# Macedonian, Norwegian, Persian (Farsi), Polish, Portuguese, Romanian, Russian, +# Serbian, Serbian-Cyrillic, Slovak, Slovene, Spanish, Swedish, Turkish, +# Ukrainian and Vietnamese. +# The default value is: English. OUTPUT_LANGUAGE = English -# If the BRIEF_MEMBER_DESC tag is set to YES (the default) Doxygen will -# include brief member descriptions after the members that are listed in -# the file and class documentation (similar to JavaDoc). -# Set to NO to disable this. +# The OUTPUT_TEXT_DIRECTION tag is used to specify the direction in which all +# documentation generated by doxygen is written. Doxygen will use this +# information to generate all generated output in the proper direction. +# Possible values are: None, LTR, RTL and Context. +# The default value is: None. + +OUTPUT_TEXT_DIRECTION = None + +# If the BRIEF_MEMBER_DESC tag is set to YES, doxygen will include brief member +# descriptions after the members that are listed in the file and class +# documentation (similar to Javadoc). Set to NO to disable this. +# The default value is: YES. BRIEF_MEMBER_DESC = YES -# If the REPEAT_BRIEF tag is set to YES (the default) Doxygen will prepend -# the brief description of a member or function before the detailed description. -# Note: if both HIDE_UNDOC_MEMBERS and BRIEF_MEMBER_DESC are set to NO, the +# If the REPEAT_BRIEF tag is set to YES, doxygen will prepend the brief +# description of a member or function before the detailed description +# +# Note: If both HIDE_UNDOC_MEMBERS and BRIEF_MEMBER_DESC are set to NO, the # brief descriptions will be completely suppressed. +# The default value is: YES. REPEAT_BRIEF = YES -# This tag implements a quasi-intelligent brief description abbreviator -# that is used to form the text in various listings. Each string -# in this list, if found as the leading text of the brief description, will be -# stripped from the text and the result after processing the whole list, is -# used as the annotated text. Otherwise, the brief description is used as-is. -# If left blank, the following values are used ("$name" is automatically -# replaced with the name of the entity): "The $name class" "The $name widget" -# "The $name file" "is" "provides" "specifies" "contains" -# "represents" "a" "an" "the" +# This tag implements a quasi-intelligent brief description abbreviator that is +# used to form the text in various listings. Each string in this list, if found +# as the leading text of the brief description, will be stripped from the text +# and the result, after processing the whole list, is used as the annotated +# text. Otherwise, the brief description is used as-is. If left blank, the +# following values are used ($name is automatically replaced with the name of +# the entity):The $name class, The $name widget, The $name file, is, provides, +# specifies, contains, represents, a, an and the. ABBREVIATE_BRIEF = # If the ALWAYS_DETAILED_SEC and REPEAT_BRIEF tags are both set to YES then -# Doxygen will generate a detailed section even if there is only a brief +# doxygen will generate a detailed section even if there is only a brief # description. +# The default value is: NO. ALWAYS_DETAILED_SEC = NO @@ -119,581 +139,754 @@ ALWAYS_DETAILED_SEC = NO # inherited members of a class in the documentation of that class as if those # members were ordinary class members. Constructors, destructors and assignment # operators of the base classes will not be shown. +# The default value is: NO. INLINE_INHERITED_MEMB = NO -# If the FULL_PATH_NAMES tag is set to YES then Doxygen will prepend the full -# path before files name in the file list and in the header files. If set -# to NO the shortest path that makes the file name unique will be used. +# If the FULL_PATH_NAMES tag is set to YES, doxygen will prepend the full path +# before files name in the file list and in the header files. If set to NO the +# shortest path that makes the file name unique will be used +# The default value is: YES. FULL_PATH_NAMES = NO -# If the FULL_PATH_NAMES tag is set to YES then the STRIP_FROM_PATH tag -# can be used to strip a user-defined part of the path. Stripping is -# only done if one of the specified strings matches the left-hand part of -# the path. The tag can be used to show relative paths in the file list. -# If left blank the directory from which doxygen is run is used as the -# path to strip. +# The STRIP_FROM_PATH tag can be used to strip a user-defined part of the path. +# Stripping is only done if one of the specified strings matches the left-hand +# part of the path. The tag can be used to show relative paths in the file list. +# If left blank the directory from which doxygen is run is used as the path to +# strip. +# +# Note that you can specify absolute paths here, but also relative paths, which +# will be relative from the directory where doxygen is started. +# This tag requires that the tag FULL_PATH_NAMES is set to YES. STRIP_FROM_PATH = -# The STRIP_FROM_INC_PATH tag can be used to strip a user-defined part of -# the path mentioned in the documentation of a class, which tells -# the reader which header file to include in order to use a class. -# If left blank only the name of the header file containing the class -# definition is used. Otherwise one should specify the include paths that -# are normally passed to the compiler using the -I flag. +# The STRIP_FROM_INC_PATH tag can be used to strip a user-defined part of the +# path mentioned in the documentation of a class, which tells the reader which +# header file to include in order to use a class. If left blank only the name of +# the header file containing the class definition is used. Otherwise one should +# specify the list of include paths that are normally passed to the compiler +# using the -I flag. STRIP_FROM_INC_PATH = -# If the SHORT_NAMES tag is set to YES, doxygen will generate much shorter -# (but less readable) file names. This can be useful if your file system -# doesn't support long names like on DOS, Mac, or CD-ROM. +# If the SHORT_NAMES tag is set to YES, doxygen will generate much shorter (but +# less readable) file names. This can be useful is your file systems doesn't +# support long names like on DOS, Mac, or CD-ROM. +# The default value is: NO. SHORT_NAMES = NO -# If the JAVADOC_AUTOBRIEF tag is set to YES then Doxygen -# will interpret the first line (until the first dot) of a JavaDoc-style -# comment as the brief description. If set to NO, the JavaDoc -# comments will behave just like regular Qt-style comments -# (thus requiring an explicit @brief command for a brief description.) +# If the JAVADOC_AUTOBRIEF tag is set to YES then doxygen will interpret the +# first line (until the first dot) of a Javadoc-style comment as the brief +# description. If set to NO, the Javadoc-style will behave just like regular Qt- +# style comments (thus requiring an explicit @brief command for a brief +# description.) +# The default value is: NO. JAVADOC_AUTOBRIEF = YES -# If the QT_AUTOBRIEF tag is set to YES then Doxygen will -# interpret the first line (until the first dot) of a Qt-style -# comment as the brief description. If set to NO, the comments -# will behave just like regular Qt-style comments (thus requiring -# an explicit \brief command for a brief description.) +# If the JAVADOC_BANNER tag is set to YES then doxygen will interpret a line +# such as +# /*************** +# as being the beginning of a Javadoc-style comment "banner". If set to NO, the +# Javadoc-style will behave just like regular comments and it will not be +# interpreted by doxygen. +# The default value is: NO. + +JAVADOC_BANNER = NO + +# If the QT_AUTOBRIEF tag is set to YES then doxygen will interpret the first +# line (until the first dot) of a Qt-style comment as the brief description. If +# set to NO, the Qt-style will behave just like regular Qt-style comments (thus +# requiring an explicit \brief command for a brief description.) +# The default value is: NO. QT_AUTOBRIEF = NO -# The MULTILINE_CPP_IS_BRIEF tag can be set to YES to make Doxygen -# treat a multi-line C++ special comment block (i.e. a block of //! or /// -# comments) as a brief description. This used to be the default behaviour. -# The new default is to treat a multi-line C++ comment block as a detailed -# description. Set this tag to YES if you prefer the old behaviour instead. +# The MULTILINE_CPP_IS_BRIEF tag can be set to YES to make doxygen treat a +# multi-line C++ special comment block (i.e. a block of //! or /// comments) as +# a brief description. This used to be the default behavior. The new default is +# to treat a multi-line C++ comment block as a detailed description. Set this +# tag to YES if you prefer the old behavior instead. +# +# Note that setting this tag to YES also means that rational rose comments are +# not recognized any more. +# The default value is: NO. MULTILINE_CPP_IS_BRIEF = NO -# If the INHERIT_DOCS tag is set to YES (the default) then an undocumented -# member inherits the documentation from any documented member that it -# re-implements. +# By default Python docstrings are displayed as preformatted text and doxygen's +# special commands cannot be used. By setting PYTHON_DOCSTRING to NO the +# doxygen's special commands can be used and the contents of the docstring +# documentation blocks is shown as doxygen documentation. +# The default value is: YES. + +PYTHON_DOCSTRING = YES + +# If the INHERIT_DOCS tag is set to YES then an undocumented member inherits the +# documentation from any documented member that it re-implements. +# The default value is: YES. INHERIT_DOCS = YES -# If the SEPARATE_MEMBER_PAGES tag is set to YES, then doxygen will produce -# a new page for each member. If set to NO, the documentation of a member will -# be part of the file/class/namespace that contains it. +# If the SEPARATE_MEMBER_PAGES tag is set to YES then doxygen will produce a new +# page for each member. If set to NO, the documentation of a member will be part +# of the file/class/namespace that contains it. +# The default value is: NO. SEPARATE_MEMBER_PAGES = NO -# The TAB_SIZE tag can be used to set the number of spaces in a tab. -# Doxygen uses this value to replace tabs by spaces in code fragments. +# The TAB_SIZE tag can be used to set the number of spaces in a tab. Doxygen +# uses this value to replace tabs by spaces in code fragments. +# Minimum value: 1, maximum value: 16, default value: 4. TAB_SIZE = 8 -# This tag can be used to specify a number of aliases that acts -# as commands in the documentation. An alias has the form "name=value". -# For example adding "sideeffect=\par Side Effects:\n" will allow you to -# put the command \sideeffect (or @sideeffect) in the documentation, which -# will result in a user-defined paragraph with heading "Side Effects:". -# You can put \n's in the value part of an alias to insert newlines. +# This tag can be used to specify a number of aliases that act as commands in +# the documentation. An alias has the form: +# name=value +# For example adding +# "sideeffect=@par Side Effects:\n" +# will allow you to put the command \sideeffect (or @sideeffect) in the +# documentation, which will result in a user-defined paragraph with heading +# "Side Effects:". You can put \n's in the value part of an alias to insert +# newlines (in the resulting output). You can put ^^ in the value part of an +# alias to insert a newline as if a physical newline was in the original file. +# When you need a literal { or } or , in the value part of an alias you have to +# escape them by means of a backslash (\), this can lead to conflicts with the +# commands \{ and \} for these it is advised to use the version @{ and @} or use +# a double escape (\\{ and \\}) ALIASES = -# This tag can be used to specify a number of word-keyword mappings (TCL only). -# A mapping has the form "name=value". For example adding -# "class=itcl::class" will allow you to use the command class in the -# itcl::class meaning. - -TCL_SUBST = - -# Set the OPTIMIZE_OUTPUT_FOR_C tag to YES if your project consists of C -# sources only. Doxygen will then generate output that is more tailored for C. -# For instance, some of the names that are used will be different. The list -# of all members will be omitted, etc. +# Set the OPTIMIZE_OUTPUT_FOR_C tag to YES if your project consists of C sources +# only. Doxygen will then generate output that is more tailored for C. For +# instance, some of the names that are used will be different. The list of all +# members will be omitted, etc. +# The default value is: NO. OPTIMIZE_OUTPUT_FOR_C = NO -# Set the OPTIMIZE_OUTPUT_JAVA tag to YES if your project consists of Java -# sources only. Doxygen will then generate output that is more tailored for -# Java. For instance, namespaces will be presented as packages, qualified -# scopes will look different, etc. +# Set the OPTIMIZE_OUTPUT_JAVA tag to YES if your project consists of Java or +# Python sources only. Doxygen will then generate output that is more tailored +# for that language. For instance, namespaces will be presented as packages, +# qualified scopes will look different, etc. +# The default value is: NO. OPTIMIZE_OUTPUT_JAVA = NO # Set the OPTIMIZE_FOR_FORTRAN tag to YES if your project consists of Fortran -# sources only. Doxygen will then generate output that is more tailored for -# Fortran. +# sources. Doxygen will then generate output that is tailored for Fortran. +# The default value is: NO. OPTIMIZE_FOR_FORTRAN = NO # Set the OPTIMIZE_OUTPUT_VHDL tag to YES if your project consists of VHDL -# sources. Doxygen will then generate output that is tailored for -# VHDL. +# sources. Doxygen will then generate output that is tailored for VHDL. +# The default value is: NO. OPTIMIZE_OUTPUT_VHDL = NO +# Set the OPTIMIZE_OUTPUT_SLICE tag to YES if your project consists of Slice +# sources only. Doxygen will then generate output that is more tailored for that +# language. For instance, namespaces will be presented as modules, types will be +# separated into more groups, etc. +# The default value is: NO. + +OPTIMIZE_OUTPUT_SLICE = NO + # Doxygen selects the parser to use depending on the extension of the files it -# parses. With this tag you can assign which parser to use for a given extension. -# Doxygen has a built-in mapping, but you can override or extend it using this -# tag. The format is ext=language, where ext is a file extension, and language -# is one of the parsers supported by doxygen: IDL, Java, Javascript, CSharp, C, -# C++, D, PHP, Objective-C, Python, Fortran, VHDL, C, C++. For instance to make -# doxygen treat .inc files as Fortran files (default is PHP), and .f files as C -# (default is Fortran), use: inc=Fortran f=C. Note that for custom extensions -# you also need to set FILE_PATTERNS otherwise the files are not read by doxygen. +# parses. With this tag you can assign which parser to use for a given +# extension. Doxygen has a built-in mapping, but you can override or extend it +# using this tag. The format is ext=language, where ext is a file extension, and +# language is one of the parsers supported by doxygen: IDL, Java, JavaScript, +# Csharp (C#), C, C++, D, PHP, md (Markdown), Objective-C, Python, Slice, VHDL, +# Fortran (fixed format Fortran: FortranFixed, free formatted Fortran: +# FortranFree, unknown formatted Fortran: Fortran. In the later case the parser +# tries to guess whether the code is fixed or free formatted code, this is the +# default for Fortran type files). For instance to make doxygen treat .inc files +# as Fortran files (default is PHP), and .f files as C (default is Fortran), +# use: inc=Fortran f=C. +# +# Note: For files without extension you can use no_extension as a placeholder. +# +# Note that for custom extensions you also need to set FILE_PATTERNS otherwise +# the files are not read by doxygen. When specifying no_extension you should add +# * to the FILE_PATTERNS. +# +# Note see also the list of default file extension mappings. EXTENSION_MAPPING = -# If MARKDOWN_SUPPORT is enabled (the default) then doxygen pre-processes all -# comments according to the Markdown format, which allows for more readable -# documentation. See http://daringfireball.net/projects/markdown/ for details. -# The output of markdown processing is further processed by doxygen, so you -# can mix doxygen, HTML, and XML commands with Markdown formatting. -# Disable only in case of backward compatibilities issues. +# If the MARKDOWN_SUPPORT tag is enabled then doxygen pre-processes all comments +# according to the Markdown format, which allows for more readable +# documentation. See https://daringfireball.net/projects/markdown/ for details. +# The output of markdown processing is further processed by doxygen, so you can +# mix doxygen, HTML, and XML commands with Markdown formatting. Disable only in +# case of backward compatibilities issues. +# The default value is: YES. MARKDOWN_SUPPORT = YES +# When the TOC_INCLUDE_HEADINGS tag is set to a non-zero value, all headings up +# to that level are automatically included in the table of contents, even if +# they do not have an id attribute. +# Note: This feature currently applies only to Markdown headings. +# Minimum value: 0, maximum value: 99, default value: 5. +# This tag requires that the tag MARKDOWN_SUPPORT is set to YES. + +TOC_INCLUDE_HEADINGS = 5 + +# When enabled doxygen tries to link words that correspond to documented +# classes, or namespaces to their corresponding documentation. Such a link can +# be prevented in individual cases by putting a % sign in front of the word or +# globally by setting AUTOLINK_SUPPORT to NO. +# The default value is: YES. + +AUTOLINK_SUPPORT = YES + # If you use STL classes (i.e. std::string, std::vector, etc.) but do not want -# to include (a tag file for) the STL sources as input, then you should -# set this tag to YES in order to let doxygen match functions declarations and -# definitions whose arguments contain STL classes (e.g. func(std::string); v.s. -# func(std::string) {}). This also makes the inheritance and collaboration +# to include (a tag file for) the STL sources as input, then you should set this +# tag to YES in order to let doxygen match functions declarations and +# definitions whose arguments contain STL classes (e.g. func(std::string); +# versus func(std::string) {}). This also make the inheritance and collaboration # diagrams that involve STL classes more complete and accurate. +# The default value is: NO. BUILTIN_STL_SUPPORT = YES # If you use Microsoft's C++/CLI language, you should set this option to YES to # enable parsing support. +# The default value is: NO. CPP_CLI_SUPPORT = NO -# Set the SIP_SUPPORT tag to YES if your project consists of sip sources only. -# Doxygen will parse them like normal C++ but will assume all classes use public -# instead of private inheritance when no explicit protection keyword is present. +# Set the SIP_SUPPORT tag to YES if your project consists of sip (see: +# https://www.riverbankcomputing.com/software/sip/intro) sources only. Doxygen +# will parse them like normal C++ but will assume all classes use public instead +# of private inheritance when no explicit protection keyword is present. +# The default value is: NO. SIP_SUPPORT = NO -# For Microsoft's IDL there are propget and propput attributes to indicate getter -# and setter methods for a property. Setting this option to YES (the default) -# will make doxygen replace the get and set methods by a property in the -# documentation. This will only work if the methods are indeed getting or -# setting a simple type. If this is not the case, or you want to show the -# methods anyway, you should set this option to NO. +# For Microsoft's IDL there are propget and propput attributes to indicate +# getter and setter methods for a property. Setting this option to YES will make +# doxygen to replace the get and set methods by a property in the documentation. +# This will only work if the methods are indeed getting or setting a simple +# type. If this is not the case, or you want to show the methods anyway, you +# should set this option to NO. +# The default value is: YES. IDL_PROPERTY_SUPPORT = YES # If member grouping is used in the documentation and the DISTRIBUTE_GROUP_DOC -# tag is set to YES, then doxygen will reuse the documentation of the first +# tag is set to YES then doxygen will reuse the documentation of the first # member in the group (if any) for the other members of the group. By default # all members of a group must be documented explicitly. +# The default value is: NO. DISTRIBUTE_GROUP_DOC = YES -# Set the SUBGROUPING tag to YES (the default) to allow class member groups of -# the same type (for instance a group of public functions) to be put as a -# subgroup of that type (e.g. under the Public Functions section). Set it to -# NO to prevent subgrouping. Alternatively, this can be done per class using -# the \nosubgrouping command. +# If one adds a struct or class to a group and this option is enabled, then also +# any nested class or struct is added to the same group. By default this option +# is disabled and one has to add nested compounds explicitly via \ingroup. +# The default value is: NO. + +GROUP_NESTED_COMPOUNDS = NO + +# Set the SUBGROUPING tag to YES to allow class member groups of the same type +# (for instance a group of public functions) to be put as a subgroup of that +# type (e.g. under the Public Functions section). Set it to NO to prevent +# subgrouping. Alternatively, this can be done per class using the +# \nosubgrouping command. +# The default value is: YES. SUBGROUPING = YES -# When the INLINE_GROUPED_CLASSES tag is set to YES, classes, structs and -# unions are shown inside the group in which they are included (e.g. using -# @ingroup) instead of on a separate page (for HTML and Man pages) or -# section (for LaTeX and RTF). +# When the INLINE_GROUPED_CLASSES tag is set to YES, classes, structs and unions +# are shown inside the group in which they are included (e.g. using \ingroup) +# instead of on a separate page (for HTML and Man pages) or section (for LaTeX +# and RTF). +# +# Note that this feature does not work in combination with +# SEPARATE_MEMBER_PAGES. +# The default value is: NO. INLINE_GROUPED_CLASSES = NO -# When the INLINE_SIMPLE_STRUCTS tag is set to YES, structs, classes, and -# unions with only public data fields will be shown inline in the documentation -# of the scope in which they are defined (i.e. file, namespace, or group -# documentation), provided this scope is documented. If set to NO (the default), -# structs, classes, and unions are shown on a separate page (for HTML and Man -# pages) or section (for LaTeX and RTF). +# When the INLINE_SIMPLE_STRUCTS tag is set to YES, structs, classes, and unions +# with only public data fields or simple typedef fields will be shown inline in +# the documentation of the scope in which they are defined (i.e. file, +# namespace, or group documentation), provided this scope is documented. If set +# to NO, structs, classes, and unions are shown on a separate page (for HTML and +# Man pages) or section (for LaTeX and RTF). +# The default value is: NO. INLINE_SIMPLE_STRUCTS = NO -# When TYPEDEF_HIDES_STRUCT is enabled, a typedef of a struct, union, or enum -# is documented as struct, union, or enum with the name of the typedef. So +# When TYPEDEF_HIDES_STRUCT tag is enabled, a typedef of a struct, union, or +# enum is documented as struct, union, or enum with the name of the typedef. So # typedef struct TypeS {} TypeT, will appear in the documentation as a struct # with name TypeT. When disabled the typedef will appear as a member of a file, -# namespace, or class. And the struct will be named TypeS. This can typically -# be useful for C code in case the coding convention dictates that all compound +# namespace, or class. And the struct will be named TypeS. This can typically be +# useful for C code in case the coding convention dictates that all compound # types are typedef'ed and only the typedef is referenced, never the tag name. +# The default value is: NO. TYPEDEF_HIDES_STRUCT = NO -# The SYMBOL_CACHE_SIZE determines the size of the internal cache use to -# determine which symbols to keep in memory and which to flush to disk. -# When the cache is full, less often used symbols will be written to disk. -# For small to medium size projects (<1000 input files) the default value is -# probably good enough. For larger projects a too small cache size can cause -# doxygen to be busy swapping symbols to and from disk most of the time -# causing a significant performance penalty. -# If the system has enough physical memory increasing the cache will improve the -# performance by keeping more symbols in memory. Note that the value works on -# a logarithmic scale so increasing the size by one will roughly double the -# memory usage. The cache size is given by this formula: -# 2^(16+SYMBOL_CACHE_SIZE). The valid range is 0..9, the default is 0, -# corresponding to a cache size of 2^16 = 65536 symbols. - -# DQ (12/19/2015): This is no longer used (reported as a warning by doxygen). -# SYMBOL_CACHE_SIZE = 0 - -# Similar to the SYMBOL_CACHE_SIZE the size of the symbol lookup cache can be -# set using LOOKUP_CACHE_SIZE. This cache is used to resolve symbols given -# their name and scope. Since this can be an expensive process and often the -# same symbol appear multiple times in the code, doxygen keeps a cache of -# pre-resolved symbols. If the cache is too small doxygen will become slower. -# If the cache is too large, memory is wasted. The cache size is given by this -# formula: 2^(16+LOOKUP_CACHE_SIZE). The valid range is 0..9, the default is 0, -# corresponding to a cache size of 2^16 = 65536 symbols. +# The size of the symbol lookup cache can be set using LOOKUP_CACHE_SIZE. This +# cache is used to resolve symbols given their name and scope. Since this can be +# an expensive process and often the same symbol appears multiple times in the +# code, doxygen keeps a cache of pre-resolved symbols. If the cache is too small +# doxygen will become slower. If the cache is too large, memory is wasted. The +# cache size is given by this formula: 2^(16+LOOKUP_CACHE_SIZE). The valid range +# is 0..9, the default is 0, corresponding to a cache size of 2^16=65536 +# symbols. At the end of a run doxygen will report the cache usage and suggest +# the optimal cache size from a speed point of view. +# Minimum value: 0, maximum value: 9, default value: 0. LOOKUP_CACHE_SIZE = 0 +# The NUM_PROC_THREADS specifies the number threads doxygen is allowed to use +# during processing. When set to 0 doxygen will based this on the number of +# cores available in the system. You can set it explicitly to a value larger +# than 0 to get more control over the balance between CPU load and processing +# speed. At this moment only the input processing can be done using multiple +# threads. Since this is still an experimental feature the default is set to 1, +# which efficively disables parallel processing. Please report any issues you +# encounter. Generating dot graphs in parallel is controlled by the +# DOT_NUM_THREADS setting. +# Minimum value: 0, maximum value: 32, default value: 1. + +NUM_PROC_THREADS = 1 + #--------------------------------------------------------------------------- # Build related configuration options #--------------------------------------------------------------------------- -# If the EXTRACT_ALL tag is set to YES doxygen will assume all entities in -# documentation are documented, even if no documentation was available. -# Private class members and static file members will be hidden unless -# the EXTRACT_PRIVATE and EXTRACT_STATIC tags are set to YES +# If the EXTRACT_ALL tag is set to YES, doxygen will assume all entities in +# documentation are documented, even if no documentation was available. Private +# class members and static file members will be hidden unless the +# EXTRACT_PRIVATE respectively EXTRACT_STATIC tags are set to YES. +# Note: This will also disable the warnings about undocumented members that are +# normally produced when WARNINGS is set to YES. +# The default value is: NO. EXTRACT_ALL = @DOXYGEN_EXTRACT_ALL@ -# If the EXTRACT_PRIVATE tag is set to YES all private members of a class -# will be included in the documentation. +# If the EXTRACT_PRIVATE tag is set to YES, all private members of a class will +# be included in the documentation. +# The default value is: NO. EXTRACT_PRIVATE = @DOXYGEN_EXTRACT_PRIVATE@ -# If the EXTRACT_PACKAGE tag is set to YES all members with package or internal scope will be included in the documentation. +# If the EXTRACT_PRIV_VIRTUAL tag is set to YES, documented private virtual +# methods of a class will be included in the documentation. +# The default value is: NO. + +EXTRACT_PRIV_VIRTUAL = NO + +# If the EXTRACT_PACKAGE tag is set to YES, all members with package or internal +# scope will be included in the documentation. +# The default value is: NO. EXTRACT_PACKAGE = NO -# If the EXTRACT_STATIC tag is set to YES all static members of a file -# will be included in the documentation. +# If the EXTRACT_STATIC tag is set to YES, all static members of a file will be +# included in the documentation. +# The default value is: NO. EXTRACT_STATIC = @DOXYGEN_EXTRACT_STATIC@ -# If the EXTRACT_LOCAL_CLASSES tag is set to YES classes (and structs) -# defined locally in source files will be included in the documentation. -# If set to NO only classes defined in header files are included. +# If the EXTRACT_LOCAL_CLASSES tag is set to YES, classes (and structs) defined +# locally in source files will be included in the documentation. If set to NO, +# only classes defined in header files are included. Does not have any effect +# for Java sources. +# The default value is: YES. EXTRACT_LOCAL_CLASSES = YES -# This flag is only useful for Objective-C code. When set to YES local -# methods, which are defined in the implementation section but not in -# the interface are included in the documentation. -# If set to NO (the default) only methods in the interface are included. +# This flag is only useful for Objective-C code. If set to YES, local methods, +# which are defined in the implementation section but not in the interface are +# included in the documentation. If set to NO, only methods in the interface are +# included. +# The default value is: NO. EXTRACT_LOCAL_METHODS = NO # If this flag is set to YES, the members of anonymous namespaces will be # extracted and appear in the documentation as a namespace called -# 'anonymous_namespace{file}', where file will be replaced with the base -# name of the file that contains the anonymous namespace. By default -# anonymous namespaces are hidden. +# 'anonymous_namespace{file}', where file will be replaced with the base name of +# the file that contains the anonymous namespace. By default anonymous namespace +# are hidden. +# The default value is: NO. EXTRACT_ANON_NSPACES = NO -# If the HIDE_UNDOC_MEMBERS tag is set to YES, Doxygen will hide all -# undocumented members of documented classes, files or namespaces. -# If set to NO (the default) these members will be included in the -# various overviews, but no documentation section is generated. -# This option has no effect if EXTRACT_ALL is enabled. +# If this flag is set to YES, the name of an unnamed parameter in a declaration +# will be determined by the corresponding definition. By default unnamed +# parameters remain unnamed in the output. +# The default value is: YES. + +RESOLVE_UNNAMED_PARAMS = YES + +# If the HIDE_UNDOC_MEMBERS tag is set to YES, doxygen will hide all +# undocumented members inside documented classes or files. If set to NO these +# members will be included in the various overviews, but no documentation +# section is generated. This option has no effect if EXTRACT_ALL is enabled. +# The default value is: NO. HIDE_UNDOC_MEMBERS = @DOXYGEN_HIDE_UNDOC_MEMBERS@ -# If the HIDE_UNDOC_CLASSES tag is set to YES, Doxygen will hide all -# undocumented classes that are normally visible in the class hierarchy. -# If set to NO (the default) these classes will be included in the various -# overviews. This option has no effect if EXTRACT_ALL is enabled. +# If the HIDE_UNDOC_CLASSES tag is set to YES, doxygen will hide all +# undocumented classes that are normally visible in the class hierarchy. If set +# to NO, these classes will be included in the various overviews. This option +# has no effect if EXTRACT_ALL is enabled. +# The default value is: NO. HIDE_UNDOC_CLASSES = @DOXYGEN_HIDE_UNDOC_CLASSES@ -# If the HIDE_FRIEND_COMPOUNDS tag is set to YES, Doxygen will hide all -# friend (class|struct|union) declarations. -# If set to NO (the default) these declarations will be included in the +# If the HIDE_FRIEND_COMPOUNDS tag is set to YES, doxygen will hide all friend +# declarations. If set to NO, these declarations will be included in the # documentation. +# The default value is: NO. HIDE_FRIEND_COMPOUNDS = @DOXYGEN_HIDE_FRIEND_COMPOUNDS@ -# If the HIDE_IN_BODY_DOCS tag is set to YES, Doxygen will hide any -# documentation blocks found inside the body of a function. -# If set to NO (the default) these blocks will be appended to the -# function's detailed documentation block. +# If the HIDE_IN_BODY_DOCS tag is set to YES, doxygen will hide any +# documentation blocks found inside the body of a function. If set to NO, these +# blocks will be appended to the function's detailed documentation block. +# The default value is: NO. HIDE_IN_BODY_DOCS = NO -# The INTERNAL_DOCS tag determines if documentation -# that is typed after a \internal command is included. If the tag is set -# to NO (the default) then the documentation will be excluded. -# Set it to YES to include the internal documentation. +# The INTERNAL_DOCS tag determines if documentation that is typed after a +# \internal command is included. If the tag is set to NO then the documentation +# will be excluded. Set it to YES to include the internal documentation. +# The default value is: NO. INTERNAL_DOCS = @DOXYGEN_INTERNAL_DOCS@ -# If the CASE_SENSE_NAMES tag is set to NO then Doxygen will only generate -# file names in lower-case letters. If set to YES upper-case letters are also -# allowed. This is useful if you have classes or files whose names only differ -# in case and if your file system supports case sensitive file names. Windows -# and Mac users are advised to set this option to NO. +# With the correct setting of option CASE_SENSE_NAMES doxygen will better be +# able to match the capabilities of the underlying filesystem. In case the +# filesystem is case sensitive (i.e. it supports files in the same directory +# whose names only differ in casing), the option must be set to YES to properly +# deal with such files in case they appear in the input. For filesystems that +# are not case sensitive the option should be be set to NO to properly deal with +# output files written for symbols that only differ in casing, such as for two +# classes, one named CLASS and the other named Class, and to also support +# references to files without having to specify the exact matching casing. On +# Windows (including Cygwin) and MacOS, users should typically set this option +# to NO, whereas on Linux or other Unix flavors it should typically be set to +# YES. +# The default value is: system dependent. CASE_SENSE_NAMES = YES -# If the HIDE_SCOPE_NAMES tag is set to NO (the default) then Doxygen -# will show members with their full class and namespace scopes in the -# documentation. If set to YES the scope will be hidden. +# If the HIDE_SCOPE_NAMES tag is set to NO then doxygen will show members with +# their full class and namespace scopes in the documentation. If set to YES, the +# scope will be hidden. +# The default value is: NO. HIDE_SCOPE_NAMES = NO -# If the SHOW_INCLUDE_FILES tag is set to YES (the default) then Doxygen -# will put a list of the files that are included by a file in the documentation -# of that file. +# If the HIDE_COMPOUND_REFERENCE tag is set to NO (default) then doxygen will +# append additional text to a page's title, such as Class Reference. If set to +# YES the compound reference will be hidden. +# The default value is: NO. + +HIDE_COMPOUND_REFERENCE= NO + +# If the SHOW_INCLUDE_FILES tag is set to YES then doxygen will put a list of +# the files that are included by a file in the documentation of that file. +# The default value is: YES. SHOW_INCLUDE_FILES = YES -# If the FORCE_LOCAL_INCLUDES tag is set to YES then Doxygen -# will list include files with double quotes in the documentation -# rather than with sharp brackets. +# If the SHOW_GROUPED_MEMB_INC tag is set to YES then Doxygen will add for each +# grouped member an include statement to the documentation, telling the reader +# which file to include in order to use the member. +# The default value is: NO. + +SHOW_GROUPED_MEMB_INC = NO + +# If the FORCE_LOCAL_INCLUDES tag is set to YES then doxygen will list include +# files with double quotes in the documentation rather than with sharp brackets. +# The default value is: NO. FORCE_LOCAL_INCLUDES = NO -# If the INLINE_INFO tag is set to YES (the default) then a tag [inline] -# is inserted in the documentation for inline members. +# If the INLINE_INFO tag is set to YES then a tag [inline] is inserted in the +# documentation for inline members. +# The default value is: YES. INLINE_INFO = YES -# If the SORT_MEMBER_DOCS tag is set to YES (the default) then doxygen -# will sort the (detailed) documentation of file and class members -# alphabetically by member name. If set to NO the members will appear in -# declaration order. +# If the SORT_MEMBER_DOCS tag is set to YES then doxygen will sort the +# (detailed) documentation of file and class members alphabetically by member +# name. If set to NO, the members will appear in declaration order. +# The default value is: YES. SORT_MEMBER_DOCS = NO -# If the SORT_BRIEF_DOCS tag is set to YES then doxygen will sort the -# brief documentation of file, namespace and class members alphabetically -# by member name. If set to NO (the default) the members will appear in -# declaration order. +# If the SORT_BRIEF_DOCS tag is set to YES then doxygen will sort the brief +# descriptions of file, namespace and class members alphabetically by member +# name. If set to NO, the members will appear in declaration order. Note that +# this will also influence the order of the classes in the class list. +# The default value is: NO. SORT_BRIEF_DOCS = NO -# If the SORT_MEMBERS_CTORS_1ST tag is set to YES then doxygen -# will sort the (brief and detailed) documentation of class members so that -# constructors and destructors are listed first. If set to NO (the default) -# the constructors will appear in the respective orders defined by -# SORT_MEMBER_DOCS and SORT_BRIEF_DOCS. -# This tag will be ignored for brief docs if SORT_BRIEF_DOCS is set to NO -# and ignored for detailed docs if SORT_MEMBER_DOCS is set to NO. +# If the SORT_MEMBERS_CTORS_1ST tag is set to YES then doxygen will sort the +# (brief and detailed) documentation of class members so that constructors and +# destructors are listed first. If set to NO the constructors will appear in the +# respective orders defined by SORT_BRIEF_DOCS and SORT_MEMBER_DOCS. +# Note: If SORT_BRIEF_DOCS is set to NO this option is ignored for sorting brief +# member documentation. +# Note: If SORT_MEMBER_DOCS is set to NO this option is ignored for sorting +# detailed member documentation. +# The default value is: NO. SORT_MEMBERS_CTORS_1ST = YES -# If the SORT_GROUP_NAMES tag is set to YES then doxygen will sort the -# hierarchy of group names into alphabetical order. If set to NO (the default) -# the group names will appear in their defined order. +# If the SORT_GROUP_NAMES tag is set to YES then doxygen will sort the hierarchy +# of group names into alphabetical order. If set to NO the group names will +# appear in their defined order. +# The default value is: NO. SORT_GROUP_NAMES = NO -# If the SORT_BY_SCOPE_NAME tag is set to YES, the class list will be -# sorted by fully-qualified names, including namespaces. If set to -# NO (the default), the class list will be sorted only by class name, -# not including the namespace part. +# If the SORT_BY_SCOPE_NAME tag is set to YES, the class list will be sorted by +# fully-qualified names, including namespaces. If set to NO, the class list will +# be sorted only by class name, not including the namespace part. # Note: This option is not very useful if HIDE_SCOPE_NAMES is set to YES. -# Note: This option applies only to the class list, not to the -# alphabetical list. +# Note: This option applies only to the class list, not to the alphabetical +# list. +# The default value is: NO. SORT_BY_SCOPE_NAME = NO -# If the STRICT_PROTO_MATCHING option is enabled and doxygen fails to -# do proper type resolution of all parameters of a function it will reject a -# match between the prototype and the implementation of a member function even -# if there is only one candidate or it is obvious which candidate to choose -# by doing a simple string match. By disabling STRICT_PROTO_MATCHING doxygen -# will still accept a match between prototype and implementation in such cases. +# If the STRICT_PROTO_MATCHING option is enabled and doxygen fails to do proper +# type resolution of all parameters of a function it will reject a match between +# the prototype and the implementation of a member function even if there is +# only one candidate or it is obvious which candidate to choose by doing a +# simple string match. By disabling STRICT_PROTO_MATCHING doxygen will still +# accept a match between prototype and implementation in such cases. +# The default value is: NO. STRICT_PROTO_MATCHING = NO -# The GENERATE_TODOLIST tag can be used to enable (YES) or -# disable (NO) the todo list. This list is created by putting \todo -# commands in the documentation. +# The GENERATE_TODOLIST tag can be used to enable (YES) or disable (NO) the todo +# list. This list is created by putting \todo commands in the documentation. +# The default value is: YES. GENERATE_TODOLIST = NO -# The GENERATE_TESTLIST tag can be used to enable (YES) or -# disable (NO) the test list. This list is created by putting \test -# commands in the documentation. +# The GENERATE_TESTLIST tag can be used to enable (YES) or disable (NO) the test +# list. This list is created by putting \test commands in the documentation. +# The default value is: YES. GENERATE_TESTLIST = NO -# The GENERATE_BUGLIST tag can be used to enable (YES) or -# disable (NO) the bug list. This list is created by putting \bug -# commands in the documentation. +# The GENERATE_BUGLIST tag can be used to enable (YES) or disable (NO) the bug +# list. This list is created by putting \bug commands in the documentation. +# The default value is: YES. GENERATE_BUGLIST = NO -# The GENERATE_DEPRECATEDLIST tag can be used to enable (YES) or -# disable (NO) the deprecated list. This list is created by putting -# \deprecated commands in the documentation. +# The GENERATE_DEPRECATEDLIST tag can be used to enable (YES) or disable (NO) +# the deprecated list. This list is created by putting \deprecated commands in +# the documentation. +# The default value is: YES. GENERATE_DEPRECATEDLIST= NO -# The ENABLED_SECTIONS tag can be used to enable conditional -# documentation sections, marked by \if sectionname ... \endif. +# The ENABLED_SECTIONS tag can be used to enable conditional documentation +# sections, marked by \if ... \endif and \cond +# ... \endcond blocks. ENABLED_SECTIONS = @DOXYGEN_ENABLED_SECTIONS@ -# The MAX_INITIALIZER_LINES tag determines the maximum number of lines -# the initial value of a variable or macro consists of for it to appear in -# the documentation. If the initializer consists of more lines than specified -# here it will be hidden. Use a value of 0 to hide initializers completely. -# The appearance of the initializer of individual variables and macros in the -# documentation can be controlled using \showinitializer or \hideinitializer -# command in the documentation regardless of this setting. +# The MAX_INITIALIZER_LINES tag determines the maximum number of lines that the +# initial value of a variable or macro / define can have for it to appear in the +# documentation. If the initializer consists of more lines than specified here +# it will be hidden. Use a value of 0 to hide initializers completely. The +# appearance of the value of individual variables and macros / defines can be +# controlled using \showinitializer or \hideinitializer command in the +# documentation regardless of this setting. +# Minimum value: 0, maximum value: 10000, default value: 30. MAX_INITIALIZER_LINES = 30 -# Set the SHOW_USED_FILES tag to NO to disable the list of files generated -# at the bottom of the documentation of classes and structs. If set to YES the +# Set the SHOW_USED_FILES tag to NO to disable the list of files generated at +# the bottom of the documentation of classes and structs. If set to YES, the # list will mention the files that were used to generate the documentation. +# The default value is: YES. SHOW_USED_FILES = YES -# Set the SHOW_FILES tag to NO to disable the generation of the Files page. -# This will remove the Files entry from the Quick Index and from the -# Folder Tree View (if specified). The default is YES. +# Set the SHOW_FILES tag to NO to disable the generation of the Files page. This +# will remove the Files entry from the Quick Index and from the Folder Tree View +# (if specified). +# The default value is: YES. SHOW_FILES = YES -# Set the SHOW_NAMESPACES tag to NO to disable the generation of the -# Namespaces page. -# This will remove the Namespaces entry from the Quick Index -# and from the Folder Tree View (if specified). The default is YES. +# Set the SHOW_NAMESPACES tag to NO to disable the generation of the Namespaces +# page. This will remove the Namespaces entry from the Quick Index and from the +# Folder Tree View (if specified). +# The default value is: YES. SHOW_NAMESPACES = YES # The FILE_VERSION_FILTER tag can be used to specify a program or script that # doxygen should invoke to get the current version for each file (typically from # the version control system). Doxygen will invoke the program by executing (via -# popen()) the command , where is the value of -# the FILE_VERSION_FILTER tag, and is the name of an input file -# provided by doxygen. Whatever the program writes to standard output -# is used as the file version. See the manual for examples. +# popen()) the command command input-file, where command is the value of the +# FILE_VERSION_FILTER tag, and input-file is the name of an input file provided +# by doxygen. Whatever the program writes to standard output is used as the file +# version. For an example see the documentation. FILE_VERSION_FILTER = # The LAYOUT_FILE tag can be used to specify a layout file which will be parsed # by doxygen. The layout file controls the global structure of the generated # output files in an output format independent way. To create the layout file -# that represents doxygen's defaults, run doxygen with the -l option. -# You can optionally specify a file name after the option, if omitted -# DoxygenLayout.xml will be used as the name of the layout file. +# that represents doxygen's defaults, run doxygen with the -l option. You can +# optionally specify a file name after the option, if omitted DoxygenLayout.xml +# will be used as the name of the layout file. +# +# Note that if you run doxygen from a directory containing a file called +# DoxygenLayout.xml, doxygen will parse it automatically even if the LAYOUT_FILE +# tag is left empty. LAYOUT_FILE = @top_srcdir@/docs/Rose/roseDoxygenLayout.xml -# The CITE_BIB_FILES tag can be used to specify one or more bib files -# containing the references data. This must be a list of .bib files. The -# .bib extension is automatically appended if omitted. Using this command -# requires the bibtex tool to be installed. See also -# http://en.wikipedia.org/wiki/BibTeX for more info. For LaTeX the style -# of the bibliography can be controlled using LATEX_BIB_STYLE. To use this -# feature you need bibtex and perl available in the search path. +# The CITE_BIB_FILES tag can be used to specify one or more bib files containing +# the reference definitions. This must be a list of .bib files. The .bib +# extension is automatically appended if omitted. This requires the bibtex tool +# to be installed. See also https://en.wikipedia.org/wiki/BibTeX for more info. +# For LaTeX the style of the bibliography can be controlled using +# LATEX_BIB_STYLE. To use this feature you need bibtex and perl available in the +# search path. See also \cite for info how to create references. CITE_BIB_FILES = #--------------------------------------------------------------------------- -# configuration options related to warning and progress messages +# Configuration options related to warning and progress messages #--------------------------------------------------------------------------- -# The QUIET tag can be used to turn on/off the messages that are generated -# by doxygen. Possible values are YES and NO. If left blank NO is used. +# The QUIET tag can be used to turn on/off the messages that are generated to +# standard output by doxygen. If QUIET is set to YES this implies that the +# messages are off. +# The default value is: NO. QUIET = YES # The WARNINGS tag can be used to turn on/off the warning messages that are -# generated by doxygen. Possible values are YES and NO. If left blank -# NO is used. +# generated to standard error (stderr) by doxygen. If WARNINGS is set to YES +# this implies that the warnings are on. +# +# Tip: Turn warnings on while writing the documentation. +# The default value is: YES. WARNINGS = YES -# If WARN_IF_UNDOCUMENTED is set to YES, then doxygen will generate warnings -# for undocumented members. If EXTRACT_ALL is set to YES then this flag will -# automatically be disabled. +# If the WARN_IF_UNDOCUMENTED tag is set to YES then doxygen will generate +# warnings for undocumented members. If EXTRACT_ALL is set to YES then this flag +# will automatically be disabled. +# The default value is: YES. WARN_IF_UNDOCUMENTED = YES -# If WARN_IF_DOC_ERROR is set to YES, doxygen will generate warnings for -# potential errors in the documentation, such as not documenting some -# parameters in a documented function, or documenting parameters that -# don't exist or using markup commands wrongly. +# If the WARN_IF_DOC_ERROR tag is set to YES, doxygen will generate warnings for +# potential errors in the documentation, such as not documenting some parameters +# in a documented function, or documenting parameters that don't exist or using +# markup commands wrongly. +# The default value is: YES. WARN_IF_DOC_ERROR = YES -# The WARN_NO_PARAMDOC option can be enabled to get warnings for -# functions that are documented, but have no documentation for their parameters -# or return value. If set to NO (the default) doxygen will only warn about -# wrong or incomplete parameter documentation, but not about the absence of -# documentation. +# This WARN_NO_PARAMDOC option can be enabled to get warnings for functions that +# are documented, but have no documentation for their parameters or return +# value. If set to NO, doxygen will only warn about wrong or incomplete +# parameter documentation, but not about the absence of documentation. If +# EXTRACT_ALL is set to YES then this flag will automatically be disabled. +# The default value is: NO. WARN_NO_PARAMDOC = NO -# The WARN_FORMAT tag determines the format of the warning messages that -# doxygen can produce. The string should contain the $file, $line, and $text -# tags, which will be replaced by the file and line number from which the -# warning originated and the warning text. Optionally the format may contain -# $version, which will be replaced by the version of the file (if it could -# be obtained via FILE_VERSION_FILTER) +# If the WARN_AS_ERROR tag is set to YES then doxygen will immediately stop when +# a warning is encountered. If the WARN_AS_ERROR tag is set to FAIL_ON_WARNINGS +# then doxygen will continue running as if WARN_AS_ERROR tag is set to NO, but +# at the end of the doxygen process doxygen will return with a non-zero status. +# Possible values are: NO, YES and FAIL_ON_WARNINGS. +# The default value is: NO. + +WARN_AS_ERROR = NO + +# The WARN_FORMAT tag determines the format of the warning messages that doxygen +# can produce. The string should contain the $file, $line, and $text tags, which +# will be replaced by the file and line number from which the warning originated +# and the warning text. Optionally the format may contain $version, which will +# be replaced by the version of the file (if it could be obtained via +# FILE_VERSION_FILTER) +# The default value is: $file:$line: $text. WARN_FORMAT = "$file:$line: $text" -# The WARN_LOGFILE tag can be used to specify a file to which warning -# and error messages should be written. If left blank the output is written -# to stderr. +# The WARN_LOGFILE tag can be used to specify a file to which warning and error +# messages should be written. If left blank the output is written to standard +# error (stderr). WARN_LOGFILE = #--------------------------------------------------------------------------- -# configuration options related to the input files +# Configuration options related to the input files #--------------------------------------------------------------------------- -# The INPUT tag can be used to specify the files and/or directories that contain -# documented source files. You may enter file names like "myfile.cpp" or -# directories like "/usr/src/myproject". Separate the files or directories -# with spaces. - -# NOTE: If your file isn't being picked up by doxygen, then perhaps it's listed -# in the EXCLUDE variable below. - -# NOTE: Do not add EDG source files to this list or else source code may leak -# into the documentation. - -# NOTE: The order of the files/directories listed here is generally the same order -# they'll appear in the documentation except when some other sort order -# prevails (e.g., alphabetical or source-order). +# The INPUT tag is used to specify the files and/or directories that contain +# documented source files. You may enter file names like myfile.cpp or +# directories like /usr/src/myproject. Separate the files or directories with +# spaces. See also FILE_PATTERNS and EXTENSION_MAPPING +# Note: If this tag is empty the current directory is searched. INPUT = @top_srcdir@/docs/Rose/MainPage.dox \ - @top_srcdir@/docs/Rose/ToolDevelopment \ - @top_srcdir@/docs/Rose/LibraryGeneralPrinciples.dox \ - @top_srcdir@/docs/Rose/BinaryTutorial.dox \ - @top_srcdir@/docs/Rose/Developers.dox \ + @top_srcdir@/docs/Rose/ToolDevelopment \ + @top_srcdir@/docs/Rose/LibraryGeneralPrinciples.dox \ + @top_srcdir@/docs/Rose/Developers.dox \ @top_srcdir@/docs/Rose \ @top_pwd@/src/frontend/SageIII \ @top_srcdir@/src/frontend/frontend.docs \ @top_srcdir@/docs/testDoxygen \ - @top_srcdir@/src/Rose \ - @top_srcdir@/src/Rose/CommandLine \ - @top_srcdir@/src/Rose/StringUtility \ - @top_srcdir@/src/Rose/AST \ + @top_srcdir@/src/frontend/CxxFrontend/EDG/edgRose \ + @top_srcdir@/src/frontend/OpenFortranParser_SAGE_Connection \ @top_srcdir@/src/frontend/SageIII/ \ + @top_srcdir@/src/frontend/SageIII/sage.docs \ @top_srcdir@/src/frontend/SageIII/docs \ - @top_srcdir@/src/frontend/SageIII/astPostProcessing/checkIsModifiedFlag.C \ + @top_srcdir@/src/frontend/SageIII/astFixup \ + @top_srcdir@/src/frontend/SageIII/astHiddenTypeAndDeclarationLists \ + @top_srcdir@/src/frontend/SageIII/astPostProcessing \ + @top_srcdir@/src/frontend/SageIII/astTokenStream \ + @top_srcdir@/src/frontend/SageIII/includeDirectivesProcessing \ + @top_srcdir@/src/frontend/SageIII/sage_support \ @top_srcdir@/src/frontend/SageIII/sageInterface \ @top_srcdir@/src/frontend/SageIII/virtualCFG \ @top_srcdir@/src/midend/programTransformation/ompLowering \ @top_srcdir@/src/midend/midend.docs \ + @top_srcdir@/src/midend/abstractLayer \ + @top_srcdir@/src/midend/astDiagnostics \ @top_srcdir@/src/midend/astDiagnostics/AstDiagnostics.docs \ + @top_srcdir@/src/midend/astDump \ + @top_srcdir@/src/midend/astDump/MSTL.docs \ + @top_srcdir@/src/midend/astProcessing \ + @top_srcdir@/src/midend/astProcessing/AstProcessing.docs \ + @top_srcdir@/src/midend/astQuery \ + @top_srcdir@/src/midend/astQuery/QueryLib.docs \ + @top_srcdir@/src/midend/astUtil \ @top_srcdir@/src/midend/programAnalysis/CallGraphAnalysis \ @top_srcdir@/src/midend/programAnalysis/genericDataflow \ @top_srcdir@/src/midend/programAnalysis/genericDataflow/analysis \ @@ -707,8 +900,6 @@ INPUT = @top_srcdir@/docs/Rose/MainPage.dox \ @top_srcdir@/src/midend/programTransformation/documentation.docs \ @top_srcdir@/src/midend/programTransformation/extractFunctionArgumentsNormalization \ @top_srcdir@/src/midend/programTransformation/ompLowering/omp_lowering.h \ - @top_srcdir@/src/midend/astProcessing \ - @top_srcdir@/src/midend/astQuery/QueryLib.docs \ @top_srcdir@/src/backend/backend.docs \ @top_srcdir@/src/backend/unparser/unparser.docs \ @top_srcdir@/src/backend/unparser/languageIndependenceSupport/documentation.docs \ @@ -716,57 +907,60 @@ INPUT = @top_srcdir@/docs/Rose/MainPage.dox \ @top_srcdir@/src/backend/unparser/FortranCodeGeneration/documentation.docs \ @top_srcdir@/src/util \ @top_srcdir@/src/util/utilDocumentation.docs \ - @top_srcdir@/src/util/stringSupport/stringSupportDocumentation.docs \ - @top_srcdir@/src/util/stringSupport/ \ @top_srcdir@/src/util/commandlineProcessing \ + @top_srcdir@/src/util/graphs \ + @top_srcdir@/src/util/StringUtility/stringSupportDocumentation.docs \ + @top_srcdir@/src/util/StringUtility \ + @top_srcdir@/src/util/support \ @top_srcdir@/src/3rdPartyLibraries/3rdPartyLibraries.docs \ - @top_srcdir@/src/3rdPartyLibraries/MSTL/MSTL.docs \ @top_srcdir@/src/extra.docs # This tag can be used to specify the character encoding of the source files -# that doxygen parses. Internally doxygen uses the UTF-8 encoding, which is -# also the default input encoding. Doxygen uses libiconv (or the iconv built -# into libc) for the transcoding. See http://www.gnu.org/software/libiconv for -# the list of possible encodings. +# that doxygen parses. Internally doxygen uses the UTF-8 encoding. Doxygen uses +# libiconv (or the iconv built into libc) for the transcoding. See the libiconv +# documentation (see: +# https://www.gnu.org/software/libiconv/) for the list of possible encodings. +# The default value is: UTF-8. INPUT_ENCODING = UTF-8 # If the value of the INPUT tag contains directories, you can use the -# FILE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp -# and *.h) to filter out the source-files in the directories. If left -# blank the following patterns are tested: -# *.c *.cc *.cxx *.cpp *.c++ *.d *.java *.ii *.ixx *.ipp *.i++ *.inl *.h *.hh -# *.hxx *.hpp *.h++ *.idl *.odl *.cs *.php *.php3 *.inc *.m *.mm *.dox *.py -# *.f90 *.f *.for *.vhd *.vhdl +# FILE_PATTERNS tag to specify one or more wildcard patterns (like *.cpp and +# *.h) to filter out the source-files in the directories. +# +# Note that for custom extensions or not directly supported extensions you also +# need to set EXTENSION_MAPPING for the extension otherwise the files are not +# read by doxygen. +# +# Note the list of default checked file patterns might differ from the list of +# default file extension mappings. +# +# If left blank the following patterns are tested:*.c, *.cc, *.cxx, *.cpp, +# *.c++, *.java, *.ii, *.ixx, *.ipp, *.i++, *.inl, *.idl, *.ddl, *.odl, *.h, +# *.hh, *.hxx, *.hpp, *.h++, *.cs, *.d, *.php, *.php4, *.php5, *.phtml, *.inc, +# *.m, *.markdown, *.md, *.mm, *.dox (to be provided as doxygen C comment), +# *.py, *.pyw, *.f90, *.f95, *.f03, *.f08, *.f18, *.f, *.for, *.vhd, *.vhdl, +# *.ucf, *.qsf and *.ice. FILE_PATTERNS = *.h \ *.docs \ *.dox \ *.hh -# The RECURSIVE tag can be used to turn specify whether or not subdirectories -# should be searched for input files as well. Possible values are YES and NO. -# If left blank NO is used. +# The RECURSIVE tag can be used to specify whether or not subdirectories should +# be searched for input files as well. +# The default value is: NO. RECURSIVE = NO # The EXCLUDE tag can be used to specify files and/or directories that should be # excluded from the INPUT source files. This way you can easily exclude a # subdirectory from a directory tree whose root is specified with the INPUT tag. +# # Note that relative paths are relative to the directory from which doxygen is # run. -# Use this to "comment out" whole files that are deprecated. [Robb Matzke, 2015-10-01] - EXCLUDE = @top_srcdir@/src/frontend/CxxFrontend/EDG \ - @top_srcdir@/AST_RewriteMechanism/testRewrite.h \ - @top_srcdir@/AST_RewriteMechanism/testRewrite.C \ - @top_srcdir@/AST_RewriteMechanism/testNewRewrite.h \ - @top_srcdir@/AST_RewriteMechanism/testNewRewrite.C \ - @top_srcdir@/AST_RewriteMechanism/testRewritePermutations.C \ - @top_srcdir@/AST_RewriteMechanism/testRewriteReplacementPermutations.C \ - @top_srcdir@/AST_RewriteMechanism/test1.C \ - @top_srcdir@/AST_RewriteMechanism/inputProgram1.C \ @top_srcdir@/src/frontend/SageIII/sageInterface/highLevelInterface.h \ @top_srcdir@/src/midend/ompLowering/libgomp_g.h \ @top_srcdir@/util/testStrings.C \ @@ -779,14 +973,16 @@ EXCLUDE = @top_srcdir@/src/frontend/CxxFrontend/EDG \ # The EXCLUDE_SYMLINKS tag can be used to select whether or not files or # directories that are symbolic links (a Unix file system feature) are excluded # from the input. +# The default value is: NO. EXCLUDE_SYMLINKS = NO # If the value of the INPUT tag contains directories, you can use the # EXCLUDE_PATTERNS tag to specify one or more wildcard patterns to exclude -# certain files from those directories. Note that the wildcards are matched -# against the file with absolute path, so to exclude all test directories -# for example use the pattern */test/* +# certain files from those directories. +# +# Note that the wildcards are matched against the file with absolute path, so to +# exclude all test directories for example use the pattern */test/* EXCLUDE_PATTERNS = @@ -795,761 +991,1226 @@ EXCLUDE_PATTERNS = # output. The symbol name can be a fully qualified name, a word, or if the # wildcard * is used, a substring. Examples: ANamespace, AClass, # AClass::ANamespace, ANamespace::*Test +# +# Note that the wildcards are matched against the file with absolute path, so to +# exclude all test directories use the pattern */test/* EXCLUDE_SYMBOLS = -# The EXAMPLE_PATH tag can be used to specify one or more files or -# directories that contain example code fragments that are included (see -# the \include command). +# The EXAMPLE_PATH tag can be used to specify one or more files or directories +# that contain example code fragments that are included (see the \include +# command). EXAMPLE_PATH = @top_srcdir@ \ - @top_srcdir@/tutorial \ - @top_srcdir@/src/util/Sawyer/docs/examples + @top_srcdir@/tutorial # If the value of the EXAMPLE_PATH tag contains directories, you can use the -# EXAMPLE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp -# and *.h) to filter out the source-files in the directories. If left -# blank all files are included. +# EXAMPLE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp and +# *.h) to filter out the source-files in the directories. If left blank all +# files are included. EXAMPLE_PATTERNS = # If the EXAMPLE_RECURSIVE tag is set to YES then subdirectories will be -# searched for input files to be used with the \include or \dontinclude -# commands irrespective of the value of the RECURSIVE tag. -# Possible values are YES and NO. If left blank NO is used. +# searched for input files to be used with the \include or \dontinclude commands +# irrespective of the value of the RECURSIVE tag. +# The default value is: NO. EXAMPLE_RECURSIVE = NO -# The IMAGE_PATH tag can be used to specify one or more files or -# directories that contain image that are included in the documentation (see -# the \image command). +# The IMAGE_PATH tag can be used to specify one or more files or directories +# that contain images that are to be included in the documentation (see the +# \image command). IMAGE_PATH = @top_srcdir@/docs/Rose # The INPUT_FILTER tag can be used to specify a program that doxygen should # invoke to filter for each input file. Doxygen will invoke the filter program -# by executing (via popen()) the command , where -# is the value of the INPUT_FILTER tag, and is the name of an -# input file. Doxygen will then use the output that the filter program writes -# to standard output. -# If FILTER_PATTERNS is specified, this tag will be -# ignored. +# by executing (via popen()) the command: +# +# +# +# where is the value of the INPUT_FILTER tag, and is the +# name of an input file. Doxygen will then use the output that the filter +# program writes to standard output. If FILTER_PATTERNS is specified, this tag +# will be ignored. +# +# Note that the filter must not add or remove lines; it is applied before the +# code is scanned, but not when the output code is generated. If lines are added +# or removed, the anchors will not be placed correctly. +# +# Note that for custom extensions or not directly supported extensions you also +# need to set EXTENSION_MAPPING for the extension otherwise the files are not +# properly processed by doxygen. INPUT_FILTER = # The FILTER_PATTERNS tag can be used to specify filters on a per file pattern -# basis. -# Doxygen will compare the file name with each pattern and apply the -# filter if there is a match. -# The filters are a list of the form: -# pattern=filter (like *.cpp=my_cpp_filter). See INPUT_FILTER for further -# info on how filters are used. If FILTER_PATTERNS is empty or if -# non of the patterns match the file name, INPUT_FILTER is applied. +# basis. Doxygen will compare the file name with each pattern and apply the +# filter if there is a match. The filters are a list of the form: pattern=filter +# (like *.cpp=my_cpp_filter). See INPUT_FILTER for further information on how +# filters are used. If the FILTER_PATTERNS tag is empty or if none of the +# patterns match the file name, INPUT_FILTER is applied. +# +# Note that for custom extensions or not directly supported extensions you also +# need to set EXTENSION_MAPPING for the extension otherwise the files are not +# properly processed by doxygen. FILTER_PATTERNS = # If the FILTER_SOURCE_FILES tag is set to YES, the input filter (if set using -# INPUT_FILTER) will be used to filter the input files when producing source -# files to browse (i.e. when SOURCE_BROWSER is set to YES). +# INPUT_FILTER) will also be used to filter the input files that are used for +# producing the source files to browse (i.e. when SOURCE_BROWSER is set to YES). +# The default value is: NO. FILTER_SOURCE_FILES = NO # The FILTER_SOURCE_PATTERNS tag can be used to specify source filters per file -# pattern. A pattern will override the setting for FILTER_PATTERN (if any) -# and it is also possible to disable source filtering for a specific pattern -# using *.ext= (so without naming a filter). This option only has effect when -# FILTER_SOURCE_FILES is enabled. +# pattern. A pattern will override the setting for FILTER_PATTERN (if any) and +# it is also possible to disable source filtering for a specific pattern using +# *.ext= (so without naming a filter). +# This tag requires that the tag FILTER_SOURCE_FILES is set to YES. FILTER_SOURCE_PATTERNS = +# If the USE_MDFILE_AS_MAINPAGE tag refers to the name of a markdown file that +# is part of the input, its contents will be placed on the main page +# (index.html). This can be useful if you have a project on for instance GitHub +# and want to reuse the introduction page also for the doxygen output. + +USE_MDFILE_AS_MAINPAGE = + #--------------------------------------------------------------------------- -# configuration options related to source browsing +# Configuration options related to source browsing #--------------------------------------------------------------------------- -# If the SOURCE_BROWSER tag is set to YES then a list of source files will -# be generated. Documented entities will be cross-referenced with these sources. -# Note: To get rid of all source code in the generated output, make sure also -# VERBATIM_HEADERS is set to NO. +# If the SOURCE_BROWSER tag is set to YES then a list of source files will be +# generated. Documented entities will be cross-referenced with these sources. +# +# Note: To get rid of all source code in the generated output, make sure that +# also VERBATIM_HEADERS is set to NO. +# The default value is: NO. SOURCE_BROWSER = YES -# Setting the INLINE_SOURCES tag to YES will include the body -# of functions and classes directly in the documentation. +# Setting the INLINE_SOURCES tag to YES will include the body of functions, +# classes and enums directly into the documentation. +# The default value is: NO. INLINE_SOURCES = NO -# Setting the STRIP_CODE_COMMENTS tag to YES (the default) will instruct -# doxygen to hide any special comment blocks from generated source code -# fragments. Normal C, C++ and Fortran comments will always remain visible. +# Setting the STRIP_CODE_COMMENTS tag to YES will instruct doxygen to hide any +# special comment blocks from generated source code fragments. Normal C, C++ and +# Fortran comments will always remain visible. +# The default value is: YES. STRIP_CODE_COMMENTS = YES -# If the REFERENCED_BY_RELATION tag is set to YES -# then for each documented function all documented -# functions referencing it will be listed. +# If the REFERENCED_BY_RELATION tag is set to YES then for each documented +# entity all documented functions referencing it will be listed. +# The default value is: NO. REFERENCED_BY_RELATION = YES -# If the REFERENCES_RELATION tag is set to YES -# then for each documented function all documented entities -# called/used by that function will be listed. +# If the REFERENCES_RELATION tag is set to YES then for each documented function +# all documented entities called/used by that function will be listed. +# The default value is: NO. REFERENCES_RELATION = YES -# If the REFERENCES_LINK_SOURCE tag is set to YES (the default) -# and SOURCE_BROWSER tag is set to YES, then the hyperlinks from -# functions in REFERENCES_RELATION and REFERENCED_BY_RELATION lists will -# link to the source code. -# Otherwise they will link to the documentation. +# If the REFERENCES_LINK_SOURCE tag is set to YES and SOURCE_BROWSER tag is set +# to YES then the hyperlinks from functions in REFERENCES_RELATION and +# REFERENCED_BY_RELATION lists will link to the source code. Otherwise they will +# link to the documentation. +# The default value is: YES. REFERENCES_LINK_SOURCE = YES -# If the USE_HTAGS tag is set to YES then the references to source code -# will point to the HTML generated by the htags(1) tool instead of doxygen -# built-in source browser. The htags tool is part of GNU's global source -# tagging system (see http://www.gnu.org/software/global/global.html). You -# will need version 4.8.6 or higher. +# If SOURCE_TOOLTIPS is enabled (the default) then hovering a hyperlink in the +# source code will show a tooltip with additional information such as prototype, +# brief description and links to the definition and documentation. Since this +# will make the HTML file larger and loading of large files a bit slower, you +# can opt to disable this feature. +# The default value is: YES. +# This tag requires that the tag SOURCE_BROWSER is set to YES. + +SOURCE_TOOLTIPS = YES + +# If the USE_HTAGS tag is set to YES then the references to source code will +# point to the HTML generated by the htags(1) tool instead of doxygen built-in +# source browser. The htags tool is part of GNU's global source tagging system +# (see https://www.gnu.org/software/global/global.html). You will need version +# 4.8.6 or higher. +# +# To use it do the following: +# - Install the latest version of global +# - Enable SOURCE_BROWSER and USE_HTAGS in the configuration file +# - Make sure the INPUT points to the root of the source tree +# - Run doxygen as normal +# +# Doxygen will invoke htags (and that will in turn invoke gtags), so these +# tools must be available from the command line (i.e. in the search path). +# +# The result: instead of the source browser generated by doxygen, the links to +# source code will now point to the output of htags. +# The default value is: NO. +# This tag requires that the tag SOURCE_BROWSER is set to YES. USE_HTAGS = NO -# If the VERBATIM_HEADERS tag is set to YES (the default) then Doxygen -# will generate a verbatim copy of the header file for each class for -# which an include is specified. Set to NO to disable this. +# If the VERBATIM_HEADERS tag is set the YES then doxygen will generate a +# verbatim copy of the header file for each class for which an include is +# specified. Set to NO to disable this. +# See also: Section \class. +# The default value is: YES. VERBATIM_HEADERS = YES +# If the CLANG_ASSISTED_PARSING tag is set to YES then doxygen will use the +# clang parser (see: +# http://clang.llvm.org/) for more accurate parsing at the cost of reduced +# performance. This can be particularly helpful with template rich C++ code for +# which doxygen's built-in parser lacks the necessary type information. +# Note: The availability of this option depends on whether or not doxygen was +# generated with the -Duse_libclang=ON option for CMake. +# The default value is: NO. + +CLANG_ASSISTED_PARSING = NO + +# If clang assisted parsing is enabled and the CLANG_ADD_INC_PATHS tag is set to +# YES then doxygen will add the directory of each input to the include path. +# The default value is: YES. + +CLANG_ADD_INC_PATHS = YES + +# If clang assisted parsing is enabled you can provide the compiler with command +# line options that you would normally use when invoking the compiler. Note that +# the include paths will already be set by doxygen for the files and directories +# specified with INPUT and INCLUDE_PATH. +# This tag requires that the tag CLANG_ASSISTED_PARSING is set to YES. + +CLANG_OPTIONS = + +# If clang assisted parsing is enabled you can provide the clang parser with the +# path to the directory containing a file called compile_commands.json. This +# file is the compilation database (see: +# http://clang.llvm.org/docs/HowToSetupToolingForLLVM.html) containing the +# options used when the source files were built. This is equivalent to +# specifying the -p option to a clang tool, such as clang-check. These options +# will then be passed to the parser. Any options specified with CLANG_OPTIONS +# will be added as well. +# Note: The availability of this option depends on whether or not doxygen was +# generated with the -Duse_libclang=ON option for CMake. + +CLANG_DATABASE_PATH = + #--------------------------------------------------------------------------- -# configuration options related to the alphabetical class index +# Configuration options related to the alphabetical class index #--------------------------------------------------------------------------- -# If the ALPHABETICAL_INDEX tag is set to YES, an alphabetical index -# of all compounds will be generated. Enable this if the project -# contains a lot of classes, structs, unions or interfaces. +# If the ALPHABETICAL_INDEX tag is set to YES, an alphabetical index of all +# compounds will be generated. Enable this if the project contains a lot of +# classes, structs, unions or interfaces. +# The default value is: YES. ALPHABETICAL_INDEX = YES -# If the alphabetical index is enabled (see ALPHABETICAL_INDEX) then -# the COLS_IN_ALPHA_INDEX tag can be used to specify the number of columns -# in which this list will be split (can be a number in the range [1..20]) - -COLS_IN_ALPHA_INDEX = 5 - -# In case all classes in a project start with a common prefix, all -# classes will be put under the same header in the alphabetical index. -# The IGNORE_PREFIX tag can be used to specify one or more prefixes that -# should be ignored while generating the index headers. +# In case all classes in a project start with a common prefix, all classes will +# be put under the same header in the alphabetical index. The IGNORE_PREFIX tag +# can be used to specify a prefix (or a list of prefixes) that should be ignored +# while generating the index headers. +# This tag requires that the tag ALPHABETICAL_INDEX is set to YES. IGNORE_PREFIX = #--------------------------------------------------------------------------- -# configuration options related to the HTML output +# Configuration options related to the HTML output #--------------------------------------------------------------------------- -# If the GENERATE_HTML tag is set to YES (the default) Doxygen will -# generate HTML output. +# If the GENERATE_HTML tag is set to YES, doxygen will generate HTML output +# The default value is: YES. GENERATE_HTML = YES -# The HTML_OUTPUT tag is used to specify where the HTML docs will be put. -# If a relative path is entered the value of OUTPUT_DIRECTORY will be -# put in front of it. If left blank `html' will be used as the default path. +# The HTML_OUTPUT tag is used to specify where the HTML docs will be put. If a +# relative path is entered the value of OUTPUT_DIRECTORY will be put in front of +# it. +# The default directory is: html. +# This tag requires that the tag GENERATE_HTML is set to YES. HTML_OUTPUT = ROSE_HTML_Reference -# The HTML_FILE_EXTENSION tag can be used to specify the file extension for -# each generated HTML page (for example: .htm,.php,.asp). If it is left blank -# doxygen will generate files with .html extension. +# The HTML_FILE_EXTENSION tag can be used to specify the file extension for each +# generated HTML page (for example: .htm, .php, .asp). +# The default value is: .html. +# This tag requires that the tag GENERATE_HTML is set to YES. HTML_FILE_EXTENSION = .html -# The HTML_HEADER tag can be used to specify a personal HTML header for -# each generated HTML page. If it is left blank doxygen will generate a -# standard header. Note that when using a custom header you are responsible -# for the proper inclusion of any scripts and style sheets that doxygen -# needs, which is dependent on the configuration options used. -# It is advised to generate a default header using "doxygen -w html -# header.html footer.html stylesheet.css YourConfigFile" and then modify -# that header. Note that the header is subject to change so you typically -# have to redo this when upgrading to a newer version of doxygen or when -# changing the value of configuration settings such as GENERATE_TREEVIEW! +# The HTML_HEADER tag can be used to specify a user-defined HTML header file for +# each generated HTML page. If the tag is left blank doxygen will generate a +# standard header. +# +# To get valid HTML the header file that includes any scripts and style sheets +# that doxygen needs, which is dependent on the configuration options used (e.g. +# the setting GENERATE_TREEVIEW). It is highly recommended to start with a +# default header using +# doxygen -w html new_header.html new_footer.html new_stylesheet.css +# YourConfigFile +# and then modify the file new_header.html. See also section "Doxygen usage" +# for information on how to generate the default header that doxygen normally +# uses. +# Note: The header is subject to change so you typically have to regenerate the +# default header when upgrading to a newer version of doxygen. For a description +# of the possible markers and block names see the documentation. +# This tag requires that the tag GENERATE_HTML is set to YES. HTML_HEADER = -# The HTML_FOOTER tag can be used to specify a personal HTML footer for -# each generated HTML page. If it is left blank doxygen will generate a -# standard footer. +# The HTML_FOOTER tag can be used to specify a user-defined HTML footer for each +# generated HTML page. If the tag is left blank doxygen will generate a standard +# footer. See HTML_HEADER for more information on how to generate a default +# footer and what special commands can be used inside the footer. See also +# section "Doxygen usage" for information on how to generate the default footer +# that doxygen normally uses. +# This tag requires that the tag GENERATE_HTML is set to YES. HTML_FOOTER = -# The HTML_STYLESHEET tag can be used to specify a user-defined cascading -# style sheet that is used by each HTML page. It can be used to -# fine-tune the look of the HTML output. If the tag is left blank doxygen -# will generate a default style sheet. Note that doxygen will try to copy -# the style sheet file to the HTML output directory, so don't put your own -# style sheet in the HTML output directory as well, or it will be erased! +# The HTML_STYLESHEET tag can be used to specify a user-defined cascading style +# sheet that is used by each HTML page. It can be used to fine-tune the look of +# the HTML output. If left blank doxygen will generate a default style sheet. +# See also section "Doxygen usage" for information on how to generate the style +# sheet that doxygen normally uses. +# Note: It is recommended to use HTML_EXTRA_STYLESHEET instead of this tag, as +# it is more robust and this tag (HTML_STYLESHEET) will in the future become +# obsolete. +# This tag requires that the tag GENERATE_HTML is set to YES. HTML_STYLESHEET = @top_srcdir@/docs/Rose/roseDoxygen.css +# The HTML_EXTRA_STYLESHEET tag can be used to specify additional user-defined +# cascading style sheets that are included after the standard style sheets +# created by doxygen. Using this option one can overrule certain style aspects. +# This is preferred over using HTML_STYLESHEET since it does not replace the +# standard style sheet and is therefore more robust against future updates. +# Doxygen will copy the style sheet files to the output directory. +# Note: The order of the extra style sheet files is of importance (e.g. the last +# style sheet in the list overrules the setting of the previous ones in the +# list). For an example see the documentation. +# This tag requires that the tag GENERATE_HTML is set to YES. + +HTML_EXTRA_STYLESHEET = + # The HTML_EXTRA_FILES tag can be used to specify one or more extra images or # other source files which should be copied to the HTML output directory. Note # that these files will be copied to the base HTML output directory. Use the -# $relpath$ marker in the HTML_HEADER and/or HTML_FOOTER files to load these -# files. In the HTML_STYLESHEET file, use the file name only. Also note that -# the files will be copied as-is; there are no commands or markers available. +# $relpath^ marker in the HTML_HEADER and/or HTML_FOOTER files to load these +# files. In the HTML_STYLESHEET file, use the file name only. Also note that the +# files will be copied as-is; there are no commands or markers available. +# This tag requires that the tag GENERATE_HTML is set to YES. HTML_EXTRA_FILES = -# The HTML_COLORSTYLE_HUE tag controls the color of the HTML output. -# Doxygen will adjust the colors in the style sheet and background images -# according to this color. Hue is specified as an angle on a colorwheel, -# see http://en.wikipedia.org/wiki/Hue for more information. -# For instance the value 0 represents red, 60 is yellow, 120 is green, -# 180 is cyan, 240 is blue, 300 purple, and 360 is red again. -# The allowed range is 0 to 359. +# The HTML_COLORSTYLE_HUE tag controls the color of the HTML output. Doxygen +# will adjust the colors in the style sheet and background images according to +# this color. Hue is specified as an angle on a colorwheel, see +# https://en.wikipedia.org/wiki/Hue for more information. For instance the value +# 0 represents red, 60 is yellow, 120 is green, 180 is cyan, 240 is blue, 300 +# purple, and 360 is red again. +# Minimum value: 0, maximum value: 359, default value: 220. +# This tag requires that the tag GENERATE_HTML is set to YES. HTML_COLORSTYLE_HUE = 220 -# The HTML_COLORSTYLE_SAT tag controls the purity (or saturation) of -# the colors in the HTML output. For a value of 0 the output will use -# grayscales only. A value of 255 will produce the most vivid colors. +# The HTML_COLORSTYLE_SAT tag controls the purity (or saturation) of the colors +# in the HTML output. For a value of 0 the output will use grayscales only. A +# value of 255 will produce the most vivid colors. +# Minimum value: 0, maximum value: 255, default value: 100. +# This tag requires that the tag GENERATE_HTML is set to YES. HTML_COLORSTYLE_SAT = 100 -# The HTML_COLORSTYLE_GAMMA tag controls the gamma correction applied to -# the luminance component of the colors in the HTML output. Values below -# 100 gradually make the output lighter, whereas values above 100 make -# the output darker. The value divided by 100 is the actual gamma applied, -# so 80 represents a gamma of 0.8, The value 220 represents a gamma of 2.2, -# and 100 does not change the gamma. +# The HTML_COLORSTYLE_GAMMA tag controls the gamma correction applied to the +# luminance component of the colors in the HTML output. Values below 100 +# gradually make the output lighter, whereas values above 100 make the output +# darker. The value divided by 100 is the actual gamma applied, so 80 represents +# a gamma of 0.8, The value 220 represents a gamma of 2.2, and 100 does not +# change the gamma. +# Minimum value: 40, maximum value: 240, default value: 80. +# This tag requires that the tag GENERATE_HTML is set to YES. HTML_COLORSTYLE_GAMMA = 80 # If the HTML_TIMESTAMP tag is set to YES then the footer of each generated HTML -# page will contain the date and time when the page was generated. Setting -# this to NO can help when comparing the output of multiple runs. +# page will contain the date and time when the page was generated. Setting this +# to YES can help to show when doxygen was last run and thus if the +# documentation is up to date. +# The default value is: NO. +# This tag requires that the tag GENERATE_HTML is set to YES. HTML_TIMESTAMP = YES +# If the HTML_DYNAMIC_MENUS tag is set to YES then the generated HTML +# documentation will contain a main index with vertical navigation menus that +# are dynamically created via JavaScript. If disabled, the navigation index will +# consists of multiple levels of tabs that are statically embedded in every HTML +# page. Disable this option to support browsers that do not have JavaScript, +# like the Qt help browser. +# The default value is: YES. +# This tag requires that the tag GENERATE_HTML is set to YES. + +HTML_DYNAMIC_MENUS = YES + # If the HTML_DYNAMIC_SECTIONS tag is set to YES then the generated HTML # documentation will contain sections that can be hidden and shown after the # page has loaded. +# The default value is: NO. +# This tag requires that the tag GENERATE_HTML is set to YES. HTML_DYNAMIC_SECTIONS = NO -# With HTML_INDEX_NUM_ENTRIES one can control the preferred number of -# entries shown in the various tree structured indices initially; the user -# can expand and collapse entries dynamically later on. Doxygen will expand -# the tree to such a level that at most the specified number of entries are -# visible (unless a fully collapsed tree already exceeds this amount). -# So setting the number of entries 1 will produce a full collapsed tree by -# default. 0 is a special value representing an infinite number of entries -# and will result in a full expanded tree by default. +# With HTML_INDEX_NUM_ENTRIES one can control the preferred number of entries +# shown in the various tree structured indices initially; the user can expand +# and collapse entries dynamically later on. Doxygen will expand the tree to +# such a level that at most the specified number of entries are visible (unless +# a fully collapsed tree already exceeds this amount). So setting the number of +# entries 1 will produce a full collapsed tree by default. 0 is a special value +# representing an infinite number of entries and will result in a full expanded +# tree by default. +# Minimum value: 0, maximum value: 9999, default value: 100. +# This tag requires that the tag GENERATE_HTML is set to YES. HTML_INDEX_NUM_ENTRIES = 100 -# If the GENERATE_DOCSET tag is set to YES, additional index files -# will be generated that can be used as input for Apple's Xcode 3 -# integrated development environment, introduced with OSX 10.5 (Leopard). -# To create a documentation set, doxygen will generate a Makefile in the -# HTML output directory. Running make will produce the docset in that -# directory and running "make install" will install the docset in -# ~/Library/Developer/Shared/Documentation/DocSets so that Xcode will find -# it at startup. -# See http://developer.apple.com/tools/creatingdocsetswithdoxygen.html -# for more information. +# If the GENERATE_DOCSET tag is set to YES, additional index files will be +# generated that can be used as input for Apple's Xcode 3 integrated development +# environment (see: +# https://developer.apple.com/xcode/), introduced with OSX 10.5 (Leopard). To +# create a documentation set, doxygen will generate a Makefile in the HTML +# output directory. Running make will produce the docset in that directory and +# running make install will install the docset in +# ~/Library/Developer/Shared/Documentation/DocSets so that Xcode will find it at +# startup. See https://developer.apple.com/library/archive/featuredarticles/Doxy +# genXcode/_index.html for more information. +# The default value is: NO. +# This tag requires that the tag GENERATE_HTML is set to YES. GENERATE_DOCSET = NO -# When GENERATE_DOCSET tag is set to YES, this tag determines the name of the -# feed. A documentation feed provides an umbrella under which multiple -# documentation sets from a single provider (such as a company or product suite) -# can be grouped. +# This tag determines the name of the docset feed. A documentation feed provides +# an umbrella under which multiple documentation sets from a single provider +# (such as a company or product suite) can be grouped. +# The default value is: Doxygen generated docs. +# This tag requires that the tag GENERATE_DOCSET is set to YES. DOCSET_FEEDNAME = "Doxygen generated docs" -# When GENERATE_DOCSET tag is set to YES, this tag specifies a string that -# should uniquely identify the documentation set bundle. This should be a -# reverse domain-name style string, e.g. com.mycompany.MyDocSet. Doxygen -# will append .docset to the name. +# This tag specifies a string that should uniquely identify the documentation +# set bundle. This should be a reverse domain-name style string, e.g. +# com.mycompany.MyDocSet. Doxygen will append .docset to the name. +# The default value is: org.doxygen.Project. +# This tag requires that the tag GENERATE_DOCSET is set to YES. DOCSET_BUNDLE_ID = org.doxygen.Project -# When GENERATE_PUBLISHER_ID tag specifies a string that should uniquely identify +# The DOCSET_PUBLISHER_ID tag specifies a string that should uniquely identify # the documentation publisher. This should be a reverse domain-name style # string, e.g. com.mycompany.MyDocSet.documentation. +# The default value is: org.doxygen.Publisher. +# This tag requires that the tag GENERATE_DOCSET is set to YES. DOCSET_PUBLISHER_ID = org.doxygen.Publisher -# The GENERATE_PUBLISHER_NAME tag identifies the documentation publisher. +# The DOCSET_PUBLISHER_NAME tag identifies the documentation publisher. +# The default value is: Publisher. +# This tag requires that the tag GENERATE_DOCSET is set to YES. DOCSET_PUBLISHER_NAME = Publisher -# If the GENERATE_HTMLHELP tag is set to YES, additional index files -# will be generated that can be used as input for tools like the -# Microsoft HTML help workshop to generate a compiled HTML help file (.chm) -# of the generated HTML documentation. +# If the GENERATE_HTMLHELP tag is set to YES then doxygen generates three +# additional HTML index files: index.hhp, index.hhc, and index.hhk. The +# index.hhp is a project file that can be read by Microsoft's HTML Help Workshop +# (see: +# https://www.microsoft.com/en-us/download/details.aspx?id=21138) on Windows. +# +# The HTML Help Workshop contains a compiler that can convert all HTML output +# generated by doxygen into a single compiled HTML file (.chm). Compiled HTML +# files are now used as the Windows 98 help format, and will replace the old +# Windows help format (.hlp) on all Windows platforms in the future. Compressed +# HTML files also contain an index, a table of contents, and you can search for +# words in the documentation. The HTML workshop also contains a viewer for +# compressed HTML files. +# The default value is: NO. +# This tag requires that the tag GENERATE_HTML is set to YES. GENERATE_HTMLHELP = NO -# If the GENERATE_HTMLHELP tag is set to YES, the CHM_FILE tag can -# be used to specify the file name of the resulting .chm file. You -# can add a path in front of the file if the result should not be +# The CHM_FILE tag can be used to specify the file name of the resulting .chm +# file. You can add a path in front of the file if the result should not be # written to the html output directory. +# This tag requires that the tag GENERATE_HTMLHELP is set to YES. CHM_FILE = -# If the GENERATE_HTMLHELP tag is set to YES, the HHC_LOCATION tag can -# be used to specify the location (absolute path including file name) of -# the HTML help compiler (hhc.exe). If non-empty doxygen will try to run -# the HTML help compiler on the generated index.hhp. +# The HHC_LOCATION tag can be used to specify the location (absolute path +# including file name) of the HTML help compiler (hhc.exe). If non-empty, +# doxygen will try to run the HTML help compiler on the generated index.hhp. +# The file has to be specified with full path. +# This tag requires that the tag GENERATE_HTMLHELP is set to YES. HHC_LOCATION = -# If the GENERATE_HTMLHELP tag is set to YES, the GENERATE_CHI flag -# controls if a separate .chi index file is generated (YES) or that -# it should be included in the master .chm file (NO). +# The GENERATE_CHI flag controls if a separate .chi index file is generated +# (YES) or that it should be included in the main .chm file (NO). +# The default value is: NO. +# This tag requires that the tag GENERATE_HTMLHELP is set to YES. GENERATE_CHI = NO -# If the GENERATE_HTMLHELP tag is set to YES, the CHM_INDEX_ENCODING -# is used to encode HtmlHelp index (hhk), content (hhc) and project file -# content. +# The CHM_INDEX_ENCODING is used to encode HtmlHelp index (hhk), content (hhc) +# and project file content. +# This tag requires that the tag GENERATE_HTMLHELP is set to YES. CHM_INDEX_ENCODING = -# If the GENERATE_HTMLHELP tag is set to YES, the BINARY_TOC flag -# controls whether a binary table of contents is generated (YES) or a -# normal table of contents (NO) in the .chm file. +# The BINARY_TOC flag controls whether a binary table of contents is generated +# (YES) or a normal table of contents (NO) in the .chm file. Furthermore it +# enables the Previous and Next buttons. +# The default value is: NO. +# This tag requires that the tag GENERATE_HTMLHELP is set to YES. BINARY_TOC = NO -# The TOC_EXPAND flag can be set to YES to add extra items for group members -# to the contents of the HTML help documentation and to the tree view. +# The TOC_EXPAND flag can be set to YES to add extra items for group members to +# the table of contents of the HTML help documentation and to the tree view. +# The default value is: NO. +# This tag requires that the tag GENERATE_HTMLHELP is set to YES. TOC_EXPAND = NO # If the GENERATE_QHP tag is set to YES and both QHP_NAMESPACE and -# QHP_VIRTUAL_FOLDER are set, an additional index file will be generated -# that can be used as input for Qt's qhelpgenerator to generate a -# Qt Compressed Help (.qch) of the generated HTML documentation. +# QHP_VIRTUAL_FOLDER are set, an additional index file will be generated that +# can be used as input for Qt's qhelpgenerator to generate a Qt Compressed Help +# (.qch) of the generated HTML documentation. +# The default value is: NO. +# This tag requires that the tag GENERATE_HTML is set to YES. GENERATE_QHP = NO -# If the QHG_LOCATION tag is specified, the QCH_FILE tag can -# be used to specify the file name of the resulting .qch file. -# The path specified is relative to the HTML output folder. +# If the QHG_LOCATION tag is specified, the QCH_FILE tag can be used to specify +# the file name of the resulting .qch file. The path specified is relative to +# the HTML output folder. +# This tag requires that the tag GENERATE_QHP is set to YES. QCH_FILE = -# The QHP_NAMESPACE tag specifies the namespace to use when generating -# Qt Help Project output. For more information please see -# http://doc.trolltech.com/qthelpproject.html#namespace +# The QHP_NAMESPACE tag specifies the namespace to use when generating Qt Help +# Project output. For more information please see Qt Help Project / Namespace +# (see: +# https://doc.qt.io/archives/qt-4.8/qthelpproject.html#namespace). +# The default value is: org.doxygen.Project. +# This tag requires that the tag GENERATE_QHP is set to YES. QHP_NAMESPACE = org.doxygen.Project -# The QHP_VIRTUAL_FOLDER tag specifies the namespace to use when generating -# Qt Help Project output. For more information please see -# http://doc.trolltech.com/qthelpproject.html#virtual-folders +# The QHP_VIRTUAL_FOLDER tag specifies the namespace to use when generating Qt +# Help Project output. For more information please see Qt Help Project / Virtual +# Folders (see: +# https://doc.qt.io/archives/qt-4.8/qthelpproject.html#virtual-folders). +# The default value is: doc. +# This tag requires that the tag GENERATE_QHP is set to YES. QHP_VIRTUAL_FOLDER = doc -# If QHP_CUST_FILTER_NAME is set, it specifies the name of a custom filter to -# add. For more information please see -# http://doc.trolltech.com/qthelpproject.html#custom-filters +# If the QHP_CUST_FILTER_NAME tag is set, it specifies the name of a custom +# filter to add. For more information please see Qt Help Project / Custom +# Filters (see: +# https://doc.qt.io/archives/qt-4.8/qthelpproject.html#custom-filters). +# This tag requires that the tag GENERATE_QHP is set to YES. QHP_CUST_FILTER_NAME = -# The QHP_CUST_FILT_ATTRS tag specifies the list of the attributes of the -# custom filter to add. For more information please see -# -# Qt Help Project / Custom Filters. +# The QHP_CUST_FILTER_ATTRS tag specifies the list of the attributes of the +# custom filter to add. For more information please see Qt Help Project / Custom +# Filters (see: +# https://doc.qt.io/archives/qt-4.8/qthelpproject.html#custom-filters). +# This tag requires that the tag GENERATE_QHP is set to YES. QHP_CUST_FILTER_ATTRS = # The QHP_SECT_FILTER_ATTRS tag specifies the list of the attributes this -# project's -# filter section matches. -# -# Qt Help Project / Filter Attributes. +# project's filter section matches. Qt Help Project / Filter Attributes (see: +# https://doc.qt.io/archives/qt-4.8/qthelpproject.html#filter-attributes). +# This tag requires that the tag GENERATE_QHP is set to YES. QHP_SECT_FILTER_ATTRS = -# If the GENERATE_QHP tag is set to YES, the QHG_LOCATION tag can -# be used to specify the location of Qt's qhelpgenerator. -# If non-empty doxygen will try to run qhelpgenerator on the generated -# .qhp file. +# The QHG_LOCATION tag can be used to specify the location (absolute path +# including file name) of Qt's qhelpgenerator. If non-empty doxygen will try to +# run qhelpgenerator on the generated .qhp file. +# This tag requires that the tag GENERATE_QHP is set to YES. QHG_LOCATION = -# If the GENERATE_ECLIPSEHELP tag is set to YES, additional index files -# will be generated, which together with the HTML files, form an Eclipse help -# plugin. To install this plugin and make it available under the help contents -# menu in Eclipse, the contents of the directory containing the HTML and XML -# files needs to be copied into the plugins directory of eclipse. The name of -# the directory within the plugins directory should be the same as -# the ECLIPSE_DOC_ID value. After copying Eclipse needs to be restarted before -# the help appears. +# If the GENERATE_ECLIPSEHELP tag is set to YES, additional index files will be +# generated, together with the HTML files, they form an Eclipse help plugin. To +# install this plugin and make it available under the help contents menu in +# Eclipse, the contents of the directory containing the HTML and XML files needs +# to be copied into the plugins directory of eclipse. The name of the directory +# within the plugins directory should be the same as the ECLIPSE_DOC_ID value. +# After copying Eclipse needs to be restarted before the help appears. +# The default value is: NO. +# This tag requires that the tag GENERATE_HTML is set to YES. GENERATE_ECLIPSEHELP = NO -# A unique identifier for the eclipse help plugin. When installing the plugin -# the directory name containing the HTML and XML files should also have -# this name. +# A unique identifier for the Eclipse help plugin. When installing the plugin +# the directory name containing the HTML and XML files should also have this +# name. Each documentation set should have its own identifier. +# The default value is: org.doxygen.Project. +# This tag requires that the tag GENERATE_ECLIPSEHELP is set to YES. ECLIPSE_DOC_ID = org.doxygen.Project -# The DISABLE_INDEX tag can be used to turn on/off the condensed index (tabs) -# at top of each HTML page. The value NO (the default) enables the index and -# the value YES disables it. Since the tabs have the same information as the -# navigation tree you can set this option to NO if you already set -# GENERATE_TREEVIEW to YES. +# If you want full control over the layout of the generated HTML pages it might +# be necessary to disable the index and replace it with your own. The +# DISABLE_INDEX tag can be used to turn on/off the condensed index (tabs) at top +# of each HTML page. A value of NO enables the index and the value YES disables +# it. Since the tabs in the index contain the same information as the navigation +# tree, you can set this option to YES if you also set GENERATE_TREEVIEW to YES. +# The default value is: NO. +# This tag requires that the tag GENERATE_HTML is set to YES. DISABLE_INDEX = NO # The GENERATE_TREEVIEW tag is used to specify whether a tree-like index -# structure should be generated to display hierarchical information. -# If the tag value is set to YES, a side panel will be generated -# containing a tree-like index structure (just like the one that -# is generated for HTML Help). For this to work a browser that supports -# JavaScript, DHTML, CSS and frames is required (i.e. any modern browser). -# Windows users are probably better off using the HTML help feature. -# Since the tree basically has the same information as the tab index you -# could consider to set DISABLE_INDEX to NO when enabling this option. +# structure should be generated to display hierarchical information. If the tag +# value is set to YES, a side panel will be generated containing a tree-like +# index structure (just like the one that is generated for HTML Help). For this +# to work a browser that supports JavaScript, DHTML, CSS and frames is required +# (i.e. any modern browser). Windows users are probably better off using the +# HTML help feature. Via custom style sheets (see HTML_EXTRA_STYLESHEET) one can +# further fine-tune the look of the index. As an example, the default style +# sheet generated by doxygen has an example that shows how to put an image at +# the root of the tree instead of the PROJECT_NAME. Since the tree basically has +# the same information as the tab index, you could consider setting +# DISABLE_INDEX to YES when enabling this option. +# The default value is: NO. +# This tag requires that the tag GENERATE_HTML is set to YES. GENERATE_TREEVIEW = NO -# The ENUM_VALUES_PER_LINE tag can be used to set the number of enum values -# (range [0,1..20]) that doxygen will group on one line in the generated HTML -# documentation. Note that a value of 0 will completely suppress the enum -# values from appearing in the overview section. +# The ENUM_VALUES_PER_LINE tag can be used to set the number of enum values that +# doxygen will group on one line in the generated HTML documentation. +# +# Note that a value of 0 will completely suppress the enum values from appearing +# in the overview section. +# Minimum value: 0, maximum value: 20, default value: 4. +# This tag requires that the tag GENERATE_HTML is set to YES. ENUM_VALUES_PER_LINE = 1 -# If the treeview is enabled (see GENERATE_TREEVIEW) then this tag can be -# used to set the initial width (in pixels) of the frame in which the tree -# is shown. +# If the treeview is enabled (see GENERATE_TREEVIEW) then this tag can be used +# to set the initial width (in pixels) of the frame in which the tree is shown. +# Minimum value: 0, maximum value: 1500, default value: 250. +# This tag requires that the tag GENERATE_HTML is set to YES. TREEVIEW_WIDTH = 250 -# When the EXT_LINKS_IN_WINDOW option is set to YES doxygen will open -# links to external symbols imported via tag files in a separate window. +# If the EXT_LINKS_IN_WINDOW option is set to YES, doxygen will open links to +# external symbols imported via tag files in a separate window. +# The default value is: NO. +# This tag requires that the tag GENERATE_HTML is set to YES. EXT_LINKS_IN_WINDOW = NO -# Use this tag to change the font size of Latex formulas included -# as images in the HTML documentation. The default is 10. Note that -# when you change the font size after a successful doxygen run you need -# to manually remove any form_*.png images from the HTML output directory -# to force them to be regenerated. +# If the HTML_FORMULA_FORMAT option is set to svg, doxygen will use the pdf2svg +# tool (see https://github.com/dawbarton/pdf2svg) or inkscape (see +# https://inkscape.org) to generate formulas as SVG images instead of PNGs for +# the HTML output. These images will generally look nicer at scaled resolutions. +# Possible values are: png (the default) and svg (looks nicer but requires the +# pdf2svg or inkscape tool). +# The default value is: png. +# This tag requires that the tag GENERATE_HTML is set to YES. + +HTML_FORMULA_FORMAT = png + +# Use this tag to change the font size of LaTeX formulas included as images in +# the HTML documentation. When you change the font size after a successful +# doxygen run you need to manually remove any form_*.png images from the HTML +# output directory to force them to be regenerated. +# Minimum value: 8, maximum value: 50, default value: 10. +# This tag requires that the tag GENERATE_HTML is set to YES. FORMULA_FONTSIZE = 10 -# Use the FORMULA_TRANPARENT tag to determine whether or not the images -# generated for formulas are transparent PNGs. Transparent PNGs are -# not supported properly for IE 6.0, but are supported on all modern browsers. -# Note that when changing this option you need to delete any form_*.png files -# in the HTML output before the changes have effect. +# Use the FORMULA_TRANSPARENT tag to determine whether or not the images +# generated for formulas are transparent PNGs. Transparent PNGs are not +# supported properly for IE 6.0, but are supported on all modern browsers. +# +# Note that when changing this option you need to delete any form_*.png files in +# the HTML output directory before the changes have effect. +# The default value is: YES. +# This tag requires that the tag GENERATE_HTML is set to YES. FORMULA_TRANSPARENT = YES -# Enable the USE_MATHJAX option to render LaTeX formulas using MathJax -# (see http://www.mathjax.org) which uses client side Javascript for the -# rendering instead of using prerendered bitmaps. Use this if you do not -# have LaTeX installed or if you want to formulas look prettier in the HTML -# output. When enabled you may also need to install MathJax separately and -# configure the path to it using the MATHJAX_RELPATH option. +# The FORMULA_MACROFILE can contain LaTeX \newcommand and \renewcommand commands +# to create new LaTeX commands to be used in formulas as building blocks. See +# the section "Including formulas" for details. + +FORMULA_MACROFILE = + +# Enable the USE_MATHJAX option to render LaTeX formulas using MathJax (see +# https://www.mathjax.org) which uses client side JavaScript for the rendering +# instead of using pre-rendered bitmaps. Use this if you do not have LaTeX +# installed or if you want to formulas look prettier in the HTML output. When +# enabled you may also need to install MathJax separately and configure the path +# to it using the MATHJAX_RELPATH option. +# The default value is: NO. +# This tag requires that the tag GENERATE_HTML is set to YES. USE_MATHJAX = NO -# When MathJax is enabled you need to specify the location relative to the -# HTML output directory using the MATHJAX_RELPATH option. The destination -# directory should contain the MathJax.js script. For instance, if the mathjax -# directory is located at the same level as the HTML output directory, then -# MATHJAX_RELPATH should be ../mathjax. The default value points to -# the MathJax Content Delivery Network so you can quickly see the result without -# installing MathJax. -# However, it is strongly recommended to install a local -# copy of MathJax from http://www.mathjax.org before deployment. +# When MathJax is enabled you can set the default output format to be used for +# the MathJax output. See the MathJax site (see: +# http://docs.mathjax.org/en/v2.7-latest/output.html) for more details. +# Possible values are: HTML-CSS (which is slower, but has the best +# compatibility), NativeMML (i.e. MathML) and SVG. +# The default value is: HTML-CSS. +# This tag requires that the tag USE_MATHJAX is set to YES. + +MATHJAX_FORMAT = HTML-CSS + +# When MathJax is enabled you need to specify the location relative to the HTML +# output directory using the MATHJAX_RELPATH option. The destination directory +# should contain the MathJax.js script. For instance, if the mathjax directory +# is located at the same level as the HTML output directory, then +# MATHJAX_RELPATH should be ../mathjax. The default value points to the MathJax +# Content Delivery Network so you can quickly see the result without installing +# MathJax. However, it is strongly recommended to install a local copy of +# MathJax from https://www.mathjax.org before deployment. +# The default value is: https://cdn.jsdelivr.net/npm/mathjax@2. +# This tag requires that the tag USE_MATHJAX is set to YES. MATHJAX_RELPATH = http://cdn.mathjax.org/mathjax/latest -# The MATHJAX_EXTENSIONS tag can be used to specify one or MathJax extension -# names that should be enabled during MathJax rendering. +# The MATHJAX_EXTENSIONS tag can be used to specify one or more MathJax +# extension names that should be enabled during MathJax rendering. For example +# MATHJAX_EXTENSIONS = TeX/AMSmath TeX/AMSsymbols +# This tag requires that the tag USE_MATHJAX is set to YES. MATHJAX_EXTENSIONS = -# When the SEARCHENGINE tag is enabled doxygen will generate a search box -# for the HTML output. The underlying search engine uses javascript -# and DHTML and should work on any modern browser. Note that when using -# HTML help (GENERATE_HTMLHELP), Qt help (GENERATE_QHP), or docsets -# (GENERATE_DOCSET) there is already a search function so this one should -# typically be disabled. For large projects the javascript based search engine -# can be slow, then enabling SERVER_BASED_SEARCH may provide a better solution. +# The MATHJAX_CODEFILE tag can be used to specify a file with javascript pieces +# of code that will be used on startup of the MathJax code. See the MathJax site +# (see: +# http://docs.mathjax.org/en/v2.7-latest/output.html) for more details. For an +# example see the documentation. +# This tag requires that the tag USE_MATHJAX is set to YES. + +MATHJAX_CODEFILE = + +# When the SEARCHENGINE tag is enabled doxygen will generate a search box for +# the HTML output. The underlying search engine uses javascript and DHTML and +# should work on any modern browser. Note that when using HTML help +# (GENERATE_HTMLHELP), Qt help (GENERATE_QHP), or docsets (GENERATE_DOCSET) +# there is already a search function so this one should typically be disabled. +# For large projects the javascript based search engine can be slow, then +# enabling SERVER_BASED_SEARCH may provide a better solution. It is possible to +# search using the keyboard; to jump to the search box use + S +# (what the is depends on the OS and browser, but it is typically +# , /
  • User Manual (pdf)