From b476f29d6d37d3422dcfbf932397803f66106dec Mon Sep 17 00:00:00 2001 From: Alan Conway Date: Wed, 14 Mar 2007 18:27:17 +0000 Subject: Merged revisions 507729 via svnmerge from https://svn.apache.org/repos/asf/incubator/qpid/trunk/qpid ........ r507729 | aconway | 2007-02-14 17:43:06 -0500 (Wed, 14 Feb 2007) | 8 lines Applied QPID-351 patch 1 with the following mods: - Moved "source distro" instructions in front of "subversion checkout" instructions. - Added instructions on using qpid-autotools-install - Added general blurb with links at top - renamed to README, removed other README-* files. - Updated makefiles (spec file was already OK.) ........ git-svn-id: https://svn.apache.org/repos/asf/incubator/qpid/branches/qpid.0-9@518256 13f79535-47bb-0310-9956-ffa450edef68 --- cpp/Makefile.am | 2 +- cpp/README | 274 ++++++++++++++++++++++++++++++++++++++++++++++++++----- cpp/README-build | 223 -------------------------------------------- cpp/README-dev | 208 ----------------------------------------- cpp/README.rhel3 | 23 ----- cpp/bootstrap | 3 +- 6 files changed, 254 insertions(+), 479 deletions(-) delete mode 100644 cpp/README-build delete mode 100644 cpp/README-dev delete mode 100644 cpp/README.rhel3 diff --git a/cpp/Makefile.am b/cpp/Makefile.am index 5b13233fa6..112cd5dd59 100644 --- a/cpp/Makefile.am +++ b/cpp/Makefile.am @@ -2,7 +2,7 @@ AUTOMAKE_OPTIONS = 1.9.2 foreign ACLOCAL_AMFLAGS = -I m4 EXTRA_DIST = \ - README-dev DESIGN LICENSE NOTICE README.rhel3 README \ + LICENSE NOTICE README \ etc/qpidd \ $(PACKAGE).spec \ $(PACKAGE).spec.in diff --git a/cpp/README b/cpp/README index d1cbed6c18..83e9d6ed5e 100644 --- a/cpp/README +++ b/cpp/README @@ -1,13 +1,7 @@ = Qpid C++ = -Qpid C++ is a C++ implementation of the AMQP protcol described at -http://amqp.org/ - -For instructions on using the Qpid broker daemon see man qpidd(1) - -For information on the C++ client API see ./html/index.html - -Note the daemon and client API can be installed separately. +Qpid C++ is a C++ implementation of the AMQP protcol described at + http://amqp.org/ The Qpid project also provides Java, Ruby and Python implementations. @@ -15,32 +9,266 @@ For additional software or information on the Qpid project go to: http://incubator.apache.org/qpid/index.html -= Building from a source distribution = +Available documentation: + qpidd(1) man page - how to run the broker daemon. + html/index.html - C++ client API. + +Note the daemon and client API can be installed separately. + +This README describes how to build the Qpid C++ broker and client, either +from a checkout of the source or from a source distribution. == Prerequisites == - * Apache Portable Runtime 1.2.2: http://apr.apache.org - * boost 1.33.1: http://www.boost.org +We prefer to avoid spending time accommodating older versions of these +packages, so please make sure that you have the latest stable versions. +Known version numbers for a succesfull build are given in brackets, take +these as a recommended minimum version. Older unix versions, for example, +Redhat Linux 3, will almost certainly require some packages to be upgraded. + +Qpid can be built using the gcc compiler: + + # gcc (3.2.3) + +Qpid is compiled against libraries: + + * apr (1.2.7) + * boost (1.33.1) + * cppunit (1.11.4) + +Using tools: + + * boost-jam (3.1.13) + * GNU make (3.8.0) + * autoconf (2.61) + * automake (1.9.6) + * help2man (1.36.4) + * libtool (1.5.22) + * pkgconfig (0.21) + * doxygen (1.5.1) + * graphviz (2.12) + * JDK 5.0 (1.5.0.11) + +=== Optional tools === + +Building from a source distribution does not require: + + * autoconf + * automake + * JDK 5.0 + +Building without testing does not require: + + * cppunit + +Building without documentaion does not require: -Optional: if you want to run the qpid unit tests: - * CppUnit 1.11.4: http://cppunit.sourceforge.net - Note: Ensure cppunit-config is in your PATH. - -If you use yum to install packages you can do: + * help2man + * doxygen + * graphviz + +=== Installing as root === + +On linux most packages can be installed using your distribution's package +management tool. For example on Fedora: # yum install apr apr-devel boost boost-devel cppunit cppunit-devel + # yum install pkgconfig doxygen graphviz help2man + + +Follow the manual installation instruction below for any packages not +available through yum. + +=== Building and installing packages manually or as non-root user === + +Required dependencies can be installed and built from source distributions. +It is recommended that you create a directory to install them to, for example, +~/qpid-tools. To build and install the dependency pakcages: + + 1. Unzip and untar them and cd to the untared directory. + 2. do: + # ./configure --prefix=~/qpid-tools + # make install + + The exceptions to this are boost and JDK 5.0. + To build the boost library: + + 1. Unpack boost-jam. + 2. Add bjam in the unpacked directory to your path. + 3. Unpack boost and cd to the boost untarred directory. + 4. do: + + # bjam -sTOOLS=gcc --prefix=~/qpid-tools + +To install JDK 5.0 download and run its install script, or whatever +alternative instructions may be on the sun website. + +Ensure that all the build tools are available on your path, when they are +manually installed to non-standard locations. For example: + + # export PATH=~/qpid-tools/bin:$PATH + +Ensure that pkg-config is set up correctly. For example: + + # export PKG_CONFIG_PATH=~/qpid-tools/lib/pkgconfig:/usr/local/pkgconfig + # export PKG_CONFIG=~/qpid-tools/bin/pkg-config + +Ensure that the boost libraries are made available on the gcc library path. +For example: + + # export CXXFLAGS=-I~/qpid-tools/include/boost-1_33_1 + +Ensure that JDK 5.0 has its home location set up correctly and is added to +the path. For example: -== Building == + # export PATH=~/jdk1.5.0_11/bin:$PATH -If you install boost to a non-standard location then you'll need define CXXFLAGS prior -to doing ./configure: - - export CXXFLAGS=-I${boost_prefix}/include/boost-1_33_1 +== Building from a source distribution. == -e.g. export CXXFLAGS=-I$HOME/local/boost-1.33.1/include/boost-1_33_1 +In the distribution directory Build and install with: - # ./configure + + # ./configure --prefix= # make all # make install +To build and test everything: + + # make + # make check + +This builds in the source tree. You can have multiple builds in the +same working copy with different configuration. For example you can do +the following to build twice, once for debug, the other with +optimization: + + # make distclean + # mkdir .build-dbg .build-opt + # (cd .build-opt ../configure --prefix=/tmp/x && make && make check) + # (cd .build-dbg ../configure CXXFLAGS=-g --prefix=/tmp/x \ + && make && make check) + + +== For Qpid developers: building a repository working copy == + +=== Installing the latest autotools === + +If you don't have sufficiently up-to-date autotools you can get the +latest by running run the script qpid-autotools-install. + +1. Decide where you would like to install the tools. It should be in a + local directory so that you do not need root privileges. (Suggest + $HOME/qpid-tools.) Create an empty directory. +2. Modify your environment variable PATH to ensure that the bin directory + within this directory comes first in the PATH string: + PATH=$HOME/qpid-tools/bin:$PATH +3. Set PKG_CONFIG_PATH=$HOME/qpid-tools/lib/pkgconfig:/usr/lib/pkgconfig + (or if it already exists, make sure that the above path to your + qpid-tools directory is first). +4. Run the install utility from the cpp directory: + ./qpid-autotools-install --prefix=$HOME/qpid-tools --skip-check + (Note that --prefix will only accept an absolute path, so don't use + ~/qpid-tools.) The utility will download, compile and install the + required tools into the qpid-tools directory (this may take a little + time). Watch for any notices about paths at the end of the install - + this means that your environment is not correct - see steps 2 and 3 + above. + NOTE: If you omit the --skip-check option, the check of the build + can add up to an hour to what is normally a few minutes of install + time. +5. Perform a check: from the command-line run "which automake" and + ensure that it finds the automake in your qpid-tools directory. If not, + check that the build completed normally and your environment. +6. (Optional) If having the build artifacts lying around bothers you, delete + the (hidden) build directory cpp/.build-auto-tools. + +To see help, run ./qpid-autotools-install --help. + +=== Building a checkout === +To get the source code from the subversion repository (trunk) do: + + # svn checkout https://svn.apache.org/repos/asf/incubator/qpid/trunk/ . + +To build a fresh checkout: + +Cd to qpid/cpp subdirectory. Before running make on a fresh checkout do: + + # ./bootstrap + +This generates config, makefiles and the like - check the script for +details. You only need to do this once, "make" will keep everything up +to date thereafter (including re-generating configuration & Makefiles +if the automake templates change etc.) + +If you are developing code yourself, or if you want to help +us keep the code as tight and robust as possible, consider enabling +the use of valgrind. If you configure like this: + + # ./configure --enable-valgrind + +That will arrange (assuming you have valgrind installed) for "make check" +to run tests via valgrind. That makes the tests run more slowly, but +helps detect certain types of bugs, as well as memory leaks. If you run +"make check" and valgrind detects a leak that is not listed as being +"ignorable-for-now", the test script in question will fail. However, +recording whether a leak is ignorable is not easy, when the stack +signature, libraries, compiler, O/S, architecture, etc., may all vary, +so if you see a new leak, try to figure out if it's one you can fix +before adding it to the list. + +Now follow instruction for building from a source distribution. + +=== Portability === + +All system calls are abstracted by classes under lib/common/sys. This +provides an object-oriented C++ API and contains platform-specific +code. + +These wrappers are mainly inline by-value classes so they impose no +run-time penalty compared do direct system calls. + +Initially we will have a full linux implementation and a portable +implementation sufficient for the client using the APR portability +library. The implementations may change in future but the interface +for qpid code outside the qpid/sys namespace should remain stable. + +=== Unit tests === + +Unit tests are built as .so files containing CppUnit plugins. + +DllPlugInTester is provided as part of cppunit. You can use it to run +any subset of the unit tests. See Makefile for examples. + +NOTE: If foobar.so is a test plugin in the current directory then +surprisingly this will fail with "can't load plugin": + # DllPluginTester foobar.so + +Instead you need to say: + # DllPluginTester ./foobar.so + +Reason: DllPluginTester uses dlopen() which only searches for shlibs +in the standard places unless the filename contains a "/". In that +case it just tries to open the filename. + +=== System tests === + +The Python test suite ../python/run_tests is the main set of broker +system tests. + +There are some C++ client test executables built under client/test. + +== Doxygen == + +Doxygen generates documentation in several formats from source code +using special comments. You can use javadoc style comments if you know +javadoc, if you don't or want to know the fully story on doxygen +markup see http://www.stack.nl/~dimitri/doxygen/ + +Even even if the code is completely uncommented, doxygen generates +UML-esque dependency diagrams that are ''extremely'' useful in navigating +around the code, especially for newcomers. + +To try it out "make doxygen" then open doxygen/html/index.html +This README describes how to build the Qpid C++ broker and client, either +from a checkout of the source or from a source distribution. diff --git a/cpp/README-build b/cpp/README-build deleted file mode 100644 index d9e141d555..0000000000 --- a/cpp/README-build +++ /dev/null @@ -1,223 +0,0 @@ -This README describes how to build the Qpid C++ broker and client, either -from a checkout of the source or from a source distribution. - -== Prerequisites == - -We prefer to avoid spending time accommodating older versions of these -packages, so please make sure that you have the latest stable versions. -Known version numbers for a succesfull build are given in brackets, take -these as a recommended minimum version. Older unix versions, for example, -Redhat Linux 3, will almost certainly require some packages to be upgraded. - -Qpid can be built using the gcc compiler: - - * gcc (3.2.3) - -Qpid is compiled against libraries: - - * apr (1.2.7) - * boost (1.33.1) - * cppunit (1.11.4) - -Using tools: - - * boost-jam (3.1.13) - * GNU make (3.8.0) - * autoconf (2.61) - * automake (1.9.6) - * help2man (1.36.4) - * libtool (1.5.22) - * pkgconfig (0.21) - * doxygen (1.5.1) - * graphviz (2.12) - * JDK 5.0 (1.5.0.11) - -Building from a source distribution: - - You do not require: - - * autoconf - * automake - * JDK 5.0 - -Building without testing: - - You do not require: - - * cppunit - -Building without documentaion: - - You do not require: - - * help2man - * doxygen - * graphviz - -Installing as root: - - Many of these packages can be installed using the yum tool. For example: - - # yum install apr apr-devel boost boost-devel cppunit cppunit-devel - # yum install pkgconfig doxygen graphviz help2man - - Follow the manual installation instruction below for any packages not available - through yum. - -Installing and building packages not as root: - - Required dependencies can be installed and built from source distributions. - It is recommended that you create a directory to install them to, for example, - ~/qpid-tools. To build and install the dependency pakcages: - - 1. Unzip and untar them and cd to the untared directory. - 2. do: - - # ./configure --prefix=~/qpid-tools - # make install - - The exceptions to this are boost and JDK 5.0. - To build the boost library: - - 1. Unpack boost-jam. - 2. Add bjam in the unpacked directory to your path. - 3. Unpack boost and cd to the boost untarred directory. - 4. do: - - # bjam -sTOOLS=gcc --prefix=~/qpid-tools - - To install JDK 5.0 download and run its install script, or whatever alternative - instructions may be on the sun website. - - Ensure that all the build tools are available on your path, when they are - manually installed to non-standard locations. For example: - - # export PATH=~/qpid-tools/bin:$PATH - - Ensure that pkg-config is set up correctly. For example: - - # export PKG_CONFIG_PATH=~/qpid-tools/lib/pkgconfig:/usr/local/pkgconfig - # export PKG_CONFIG=~/qpid-tools/bin/pkg-config - - Ensure that the boost libraries are made available on the gcc library path. - For example: - - # export CXXFLAGS=-I~/qpid-tools/include/boost-1_33_1 - - Ensure that JDK 5.0 has its home location set up correctly and is added to - the path. For example: - - # export PATH=~/jdk1.5.0_11/bin:$PATH - # export JAVA_HOME=~/jdk1.5.0_11/ - -== Obtaining a source code checkout from subversion. == - -Skip this step if you have a source distribution to build from. To get the -code from the subversion repository (trunk) do: - - # svn checkout https://svn.apache.org/repos/asf/incubator/qpid/trunk/ . - -== Building from a fresh checkout (Developers). == - -Cd to the qpid/cpp subdriectory. Before running make on a fresh checkout do: - - # ./bootstrap - -This generates config, makefiles and the like - check the script for -details. You only need to do this once, "make" will keep everything up -to date thereafter (including re-generating configuration & Makefiles -if the automake templates change etc.) - -If you are developing code yourself, or if you want to help -us keep the code as tight and robust as possible, consider enabling -the use of valgrind. If you configure like this: - - # ./configure --enable-valgrind - -That will arrange (assuming you have valgrind installed) for "make check" -to run tests via valgrind. That makes the tests run more slowly, but -helps detect certain types of bugs, as well as memory leaks. If you run -"make check" and valgrind detects a leak that is not listed as being -"ignorable-for-now", the test script in question will fail. However, -recording whether a leak is ignorable is not easy, when the stack -signature, libraries, compiler, O/S, architecture, etc., may all vary, -so if you see a new leak, try to figure out if it's one you can fix -before adding it to the list. - -Now follow instruction for building from a source distribution. - -== Building from a source distribution. == - -Build and install with: - - # ./configure - # make all - # make install - -To build and test everything: - - # make - # make check - -This builds in the source tree. You can have multiple builds in the -same working copy with different configuration. For example you can do -the following to build twice, once for debug, the other with -optimization: - - # make distclean - # mkdir .build-dbg .build-opt - # (cd .build-opt ../configure --prefix=/tmp/x && make && make check) - # (cd .build-dbg ../configure CXXFLAGS=-g --prefix=/tmp/x \ - && make && make check) - -=== Portability === - -All system calls are abstracted by classes under lib/common/sys. This -provides an object-oriented C++ API and contains platform-specific -code. - -These wrappers are mainly inline by-value classes so they impose no -run-time penalty compared do direct system calls. - -Initially we will have a full linux implementation and a portable -implementation sufficient for the client using the APR portability -library. The implementations may change in future but the interface -for qpid code outside the qpid/sys namespace should remain stable. - -=== Unit tests === - -Unit tests are built as .so files containing CppUnit plugins. - -DllPlugInTester is provided as part of cppunit. You can use it to run -any subset of the unit tests. See Makefile for examples. - -NOTE: If foobar.so is a test plugin in the current directory then -surprisingly this will fail with "can't load plugin": - # DllPluginTester foobar.so - -Instead you need to say: - # DllPluginTester ./foobar.so - -Reason: DllPluginTester uses dlopen() which searches for shlibs -in the standard places unless the filename contains a "/". In -that case it just tries to open the filename. - -=== System tests === - -The Python test suite ../python/run_tests is the main set of broker -system tests. - -There are some C++ client test executables built under client/test. - -== Doxygen == - -Doxygen generates documentation in several formats from source code -using special comments. You can use javadoc style comments if you know -javadoc, if you don't or want to know the fully story on doxygen -markup see http://www.stack.nl/~dimitri/doxygen/ - -Even even if the code is completely uncommented, doxygen generates -UML-esque dependency diagrams that are ''extremely'' useful in navigating -around the code, especially for newcomers. - -To try it out "make doxygen" then open doxygen/html/index.html diff --git a/cpp/README-dev b/cpp/README-dev deleted file mode 100644 index 2a1e6f16c7..0000000000 --- a/cpp/README-dev +++ /dev/null @@ -1,208 +0,0 @@ -= Developer guide to C++ codebase = - -== Extra stuff == -sudo cp /usr/share/aclocal/pkg.m4 `aclocal --print-ac-dir` - -== Prerequisites == - -If you have taken the sources from SVN you will need the following -packages (or later) - -We prefer to avoid spending time accommodating older versions of these -packages, so please make sure that you have the latest stable version. - - * All the prerequisites listed in README-dist. - * GNU make - * autoconf - * automake - * cppunit - * help2man - * libtool - * pkgconfig (aka pkg-config) - -Note: Ensure cppunit-config and apr-1-config are in your PATH. - -Optional: to re-generated generated code from the XML specification: - - * java 5 - -Optional: to generate documentation you need: - - * doxygen - * graphviz - * help2man - -== Setting up on Fedora 6 == - -# yum install apr apr-devel boost boost-devel cppunit cppunit-devel -# yum install pkgconfig doxygen graphviz help2man - -To get the latest versions of autoconf, automake, libtools and other -dependencies, run the script qpid-autotools-install: - -1. Decide where you would like to install the tools. It should be in a - local directory so that you do not need root privileges. (Suggest - $HOME/qpid-tools.) Create an empty directory. -2. Modify your environment variable PATH to ensure that the bin directory - within this directory comes first in the PATH string: - PATH=$HOME/qpid-tools/bin:$PATH -3. Set PKG_CONFIG_PATH=$HOME/qpid-tools/lib/pkgconfig:/usr/lib/pkgconfig - (or if it already exists, make sure that the above path to your - qpid-tools directory is first). -4. Run the install utility from the cpp directory: - ./qpid-autotools-install --prefix=$HOME/qpid-tools --skip-check - (Note that --prefix will only accept an absolute path, so don't use - ~/qpid-tools.) The utility will download, compile and install the - required tools into the qpid-tools directory (this may take a little - time). Watch for any notices about paths at the end of the install - - this means that your environment is not correct - see steps 2 and 3 - above. - NOTE: If you omit the --skip-check option, the check of the build - can add up to an hour to what is normally a few minutes of install - time. -5. Perform a check: from the command-line run "which automake" and - ensure that it finds the automake in your qpid-tools directory. If not, - check that the build completed normally and your environment. -6. (Optional) If having the build artifacts lying around bothers you, delete - the (hidden) build directory cpp/.build-auto-tools. - -To see help, run ./qpid-autotools-install --help. - -== Recent changes == - -There have been two major changes on the C++ hierarchy: - - adds autoconf, automake, libtool support - - makes the hierarchy flatter and renames a few files (e.g., Queue.h, - Queue.cpp) that appeared twice, once under client/ and again under broker/. - -In the process, I've changed many #include directives, mostly -to remove a qpid/ or qpid/framing/ prefix from the file name argument. -Although most changes were to .cpp and .h files under qpid/cpp/, there -were also several to template files under qpid/gentools, and even one -to CppGenerator.java. - -Nearly all files are moved to a new position in the hierarchy. -The new hierarchy looks like this: - - src # this is the new home of qpidd.cpp - tests # all tests are here. See Makefile.am. - gen # As before, all generated files go here. - lib # This is just a container for the 3 lib dirs: - lib/client - lib/broker - lib/common - lib/common/framing - lib/common/sys - lib/common/sys/posix - lib/common/sys/apr - build-aux - m4 - -== Building == - -As we smooth off the rough edges with the new build setup the steps -for the most common development tasks will be scripted and/or -simplified and this README will be updated accordingly. - -Before building a fresh checkout do: - - ./bootstrap - ./configure - -This generates config, makefiles and the like - check the script for -details. You only need to do this once, "make" will keep everything up -to date thereafter (including re-generating configuration & Makefiles -if the automake templates change etc.) - -If you are developing code yourself, or if you want to help -us keep the code as tight and robust as possible, consider enabling -the use of valgrind. If you configure like this: - - ./configure --enable-valgrind - -that will arrange (assuming you have valgrind installed) for "make check" -to run tests via valgrind. That makes the tests run more slowly, but -helps detect certain types of bugs, as well as memory leaks. If you run -"make check" and valgrind detects a leak that is not listed as being -"ignorable-for-now", the test script in question will fail. However, -recording whether a leak is ignorable is not easy, when the stack -signature, libraries, compiler, O/S, architecture, etc., may all vary, -so if you see a new leak, try to figure out if it's one you can fix -before adding it to the list. - -To build and test everything: - make - make check - -This builds in the source tree. You can have multiple builds in the -same working copy with different configuration. For example you can do -the following to build twice, once for debug, the other with -optimization: - - make distclean - mkdir .build-dbg .build-opt - (cd .build-opt - ../configure --prefix=/tmp/x && make && make check) - (cd .build-dbg - ../configure CXXFLAGS=-g --prefix=/tmp/x \ - && make && make check) - -Since it's common to want to bootstrap & test a working copy with -default configuration you can say: - ./bootstrap -build - -Which is equivalent to - ./bootstrap && ./configure && make && make check - -=== Portability === - -All system calls are abstracted by classes under lib/common/sys. This -provides an object-oriented C++ API and contains platform-specific -code. - -These wrappers are mainly inline by-value classes so they impose no -run-time penalty compared do direct system calls. - -Initially we will have a full linux implementation and a portable -implementation sufficient for the client using the APR portability -library. The implementations may change in future but the interface -for qpid code outside the qpid/sys namespace should remain stable. - - -=== Unit tests === - -Unit tests are built as .so files containing CppUnit plugins. - -DllPlugInTester is provided as part of cppunit. You can use it to run -any subset of the unit tests. See Makefile for examples. - -NOTE: If foobar.so is a test plugin in the current directory then -surprisingly this will fail with "can't load plugin": - DllPluginTester foobar.so - -Instead you need to say: - DllPluginTester ./foobar.so - -Reason: DllPluginTester uses dlopen() which searches for shlibs -in the standard places unless the filename contains a "/". In -that case it just tries to open the filename. - -=== System tests === - -The Python test suite ../python/run_tests is the main set of broker -system tests. - -There are some C++ client test executables built under client/test. - -== Doxygen == - -Doxygen generates documentation in several formats from source code -using special comments. You can use javadoc style comments if you know -javadoc, if you don't or want to know the fully story on doxygen -markup see http://www.stack.nl/~dimitri/doxygen/ - -Even even if the code is completely uncommented, doxygen generates -UML-esque dependency diagrams that are ''extremely'' useful in navigating -around the code, especially for newcomers. - -To try it out "make doxygen" then open doxygen/html/index.html diff --git a/cpp/README.rhel3 b/cpp/README.rhel3 deleted file mode 100644 index 7e0c88512c..0000000000 --- a/cpp/README.rhel3 +++ /dev/null @@ -1,23 +0,0 @@ -Building on RHEL3 without access to root (i.e. no yum) -====================================================== - -Install or soft link the following: - - make-3.80 into ~/local/make-3.80 - apr-1.2.7 into ~/local/apr-1.2.7. - boost-1.33.1 into ~/local/boost-1.33.1 - cppunit-1.11.4 into ~/local/cppunit-1.11.4 - JDK 5.0 to ~/local/jdk-1.5 - -Build using the following command (builds release and debug profiles): - - $ ./build.rhel3 - -Generate cpp-client tarball (includes release and debug libs): - - $ ./release.client.rhel3 # will use the svn revision as release number - -or if you want to explicitly name the release version: - - $ ./release.client.rhel3 1.0-RC1 - diff --git a/cpp/bootstrap b/cpp/bootstrap index ded5b38481..e869115999 100755 --- a/cpp/bootstrap +++ b/cpp/bootstrap @@ -30,7 +30,8 @@ fi automake autoconf -if [ "$1" = "-build" ] ; then + +if [ "$1" = "-build" -o "$1" = "--build" ] ; then shift ./configure "$@" make -- cgit v1.2.1