This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[wwwdocs] gcc-3.1/testing-* cleanup

We actually copied the following pages

  htdocs/gcc-3.1/testing-blitz.html
  htdocs/gcc-3.1/testing-boost.html
  htdocs/gcc-3.1/testing-ftensor.html
  htdocs/gcc-3.1/testing-lapack.html
  htdocs/gcc-3.1/testing-pooma.html
  htdocs/gcc-3.1/testing-qt.html

to htdocs/testing a while ago and added redirects from the old URLs
to the new ones so that we do not have to maintain this documentation
on a per-release base.

This patch now removes those original pages.  I verified that we do
not have any direct links left to these left.

Installed.

Gerald

Index: testing-blitz.html
===================================================================
RCS file: testing-blitz.html
diff -N testing-blitz.html
--- testing-blitz.html	24 Apr 2002 19:31:41 -0000	1.3
+++ /dev/null	1 Jan 1970 00:00:00 -0000
@@ -1,102 +0,0 @@
-<html>
-
-<head>
-<title>Blitz++ build and test guide</title>
-</head>
-
-<body>
-<h1>Blitz++ build and test guide</h1>
-
-<p>This page is a guide to building the Blitz++ scientific computing class
-library as part of GCC integration testing.</p>
-
-<h2>Resource usage</h2>
-
-<p>The Blitz++ distribution, available at
-<a href="http://www.oonumerics.org/blitz/download/snapshots/blitz-20001213.tar.gz";>
-blitz-20001213.tar.gz</a>,
-is a 0.7 MB file.  The uncompressed distribution
-comprises 4.6 MB of source files.  Building and running the
-test suite adds between 90 and 125 MB of object files
-and executables to this, and building the Blitz++ example programs
-adds lots more.</p>
-
-<p>Building and running the Blitz++ test suite on a 750 Mhz
-Pentium III laptop takes 13 minutes.  Building the Blitz++ example
-programs takes a lot of additional time.</p>
-
-<h2>Prepare</h2>
-
-<p>To prepare the Blitz++ distribution, perform the following:</p>
-<ul>
-<li>Unpack the file:
-    <ul>
-    <li><code>tar zxf blitz-20001213.tar.gz</code>, or</li>
-    <li><code>gunzip -c blitz-20001213.tar.gz | tar xf -</code></li>
-    </ul>
-</li>
-<li>Change to the new directory:
-    <ul>
-    <li><code>cd blitz-20001213</code></li>
-    </ul>
-</li>
-</ul>
-
-<p>On some platforms, particularly Cygwin, you'll also need to apply
-<a href="http://gcc.gnu.org/ml/libstdc++/2001-06/msg00074.html";>this patch</a>;
-without it, <code>example/random.cpp</code> doesn't build.</p>
-
-<h2>Configure</h2>
-
-<p>You can use the simplest form of configuration if the directory
-containing the compiler under test is in your <code>PATH</code> variable
-and the directory containing the C++ libraries to test is in
-<code>LD_LIBRARY_PATH</code>:</p>
-
-<pre><code>./configure --prefix=`pwd` --with-cxx=gcc
-</code></pre>
-
-<p>To specify optimizations (by default Blitz++ is built using no
-optimization flags) and to specify the full pathname of the compiler
-and the location of the library, configure with:</p>
-
-<pre><code>GCC_INST=directory/where/you/installed/GCC
-LDFLAGS="-Wl,-rpath=${GCC_INST}/lib" \
-./configure --prefix=`pwd` \
-    --with-cxx="gcc:${GCC_INST}/bin/g++ &lt;optimization_flags&gt;" 
-</code></pre>
-
-<h2>Testing</h2>
-
-<p>To build and run the Blitz++ tests, do:</p>
-
-<pre><code>make check</code></pre>
-
-<p>The output of <code>make check</code> should include the line
-"All tests passed."  Failure to build a test prevents the rest of the
-tests from being built and any of the tests from running.  To build and
-run an individual test (see the list for <code>SINGLE_TESTS</code> from
-<code>testsuite/Makefile</code>), do:</p>
-
-<pre><code>cd testsuite
-make &lt;testname&gt;
-./&lt;testname&gt; || echo failed
-</code></pre>
-
-<p>The Blitz++ distribution also includes examples.  To build the examples
-as well as building and running the tests, do <code>make all</code>
-instead of <code>make check</code>.</p>
-
-<h2>Timing</h2>
-
-<p>TBD</p>
-
-<h2>Cleanup</h2>
-
-<p>Cleanup (to prepare the directory for a fresh run, e.g.
-with another version of the compiler), is done as follows:</p>
-
-<pre><code>make -k clean</code></pre>
-
-</body>
-</html>
Index: testing-boost.html
===================================================================
RCS file: testing-boost.html
diff -N testing-boost.html
--- testing-boost.html	9 Apr 2002 19:59:49 -0000	1.1
+++ /dev/null	1 Jan 1970 00:00:00 -0000
@@ -1,123 +0,0 @@
-<html>
-
-<head>
-<title>Boost build and test guide</title>
-</head>
-
-<body>
-<h1>Boost build and test guide</h1>
-
-<p>This page is a guide to running the testing and timing programs for the
-Boost class libraries as part of GCC integration testing.</p>
-
-<h2>Resource usage</h2>
-
-<p>The Boost distribution, available at the Boost site at
-<a href="http://www.boost.org/boost_all.tar.gz";>boost_all.tar.gz</a>,
-is a 3.8 MB file.
-The uncompressed distribution comprises some 16 MB of source files.
-Building the library and tests adds between 80 and 140 MB of
-object files and executables to this.</p>
-
-<p>On a Pentium III laptop, building the Boost library takes 15 minutes
-and building and running the regression tests takes an additional 5
-minutes.</p>
-
-<h2>Prepare</h2>
-
-<p>To prepare for a build, perform the following:</p>
-<ul>
-<li>Unpack the file:
-<ul>
-<li><code>tar zxf boost_all.tar.gz</code>, or</li>
-<li><code>gunzip -c boost_all.tar.gz | tar xf -</code></li>
-</ul>
-</li>
-<li>Change directory to the repository thus created.
-<ul>
-<li><code>cd boost_1_27_0</code></li>
-</ul>
-</li>
-<li>Define and  export environment variables:
-    <ul>
-    <li><code>PATH</code> should include the <code>bin</code> directory
-        of the GCC installation under test.</li>
-    <li><code>LD_LIBRARY_PATH</code> should include the <code>lib</code>
-        directory of the GCC installation under test.</li>
-    <li><code>BOOST_ROOT</code> should be the full pathname of the top
-        directory of the boost distribution (the one to which we just
-        changed).</li>
-    </ul>
-</li>
-</ul>
-
-<h2>Configure</h2>
-
-<p>The Boost package gets information about how to compile and link
-from the file <code>compiler.cfg</code>.  On a GNU/Linux system you
-can replace the contents of that file with the following:</p>
-
-<pre><code>linux
-gcc-3.1
-GCC 3.1
-g++ -c -w -ftemplate-depth-30 -I%include %source
-g++ -o boosttmp.exe -w -ftemplate-depth-30 -I%include %source -lrt
-GNU&lt;br&gt;&lt;a href="http://gcc.gnu.org/"&gt;GCC&lt;/a&gt;&lt;br&gt;3.1
-</code></pre>
-
-<p>To build the package with specific optimizations, add them to the
-compile line in this file.</p>
-
-<h2>Build</h2>
-
-<p>To build the Boost class library, do:</p>
-
-<pre><code>cd ${BOOST_ROOT}/tools/build/jam_src
-make all
-cd ${BOOST_ROOT}
-tools/build/jam_src/jam0 \
-    -sBOOST_ROOT=${BOOST_ROOT} -sTOOLS="gcc"
-</code></pre>
-
-<p>If you don't have Python installed, there will be build failures for
-Python support.  The <code>wregex</code> support fails to build if glibc
-is older than 2.2.4.  These failures do not prevent the build from
-continuing.</p>
-
-<h2>Test</h2>
-
-<p>Build the Boost regression tests with:</p>
-
-<pre><code>cd ${BOOST_ROOT}/status
-g++ -I${BOOST_ROOT} -o regression regression.cpp
-</code></pre>
-
-<p>Run the tests with:</p>
-
-<pre><code>cd ${BOOST_ROOT}/status
-./regression
-</code></pre>
-
-<p>"Pass" or "Fail" appears at the end of the output for each test.
-There should be no failures, although if your glibc is older than
-2.2.4 then tests 
-<code>libs/integer/integer_traits_test.cpp</code> and
-<code>libs/regex/test/regress/wregex_test.cpp</code> will fail.</p>
-
-<h2>Time</h2>
-
-<p>TBD</p>
-
-<h2>Cleanup</h2>
-
-<p>Cleanup (to prepare the directory for a fresh run, e.g.
-with another version of the compiler), is done as follows:</p>
-
-<pre><code>cd ${BOOST_ROOT}
-rm -f ${BOOST_ROOT}/build/jam_src/jam0
-rm -f ${BOOST_ROOT}/status/regression
-find . -name \*.o -exec rm -f {} \;
-</code></pre>
-
-</body>
-</html>
Index: testing-ftensor.html
===================================================================
RCS file: testing-ftensor.html
diff -N testing-ftensor.html
--- testing-ftensor.html	12 Apr 2002 23:51:10 -0000	1.1
+++ /dev/null	1 Jan 1970 00:00:00 -0000
@@ -1,110 +0,0 @@
-<html>
-
-<head>
-<title>FTensor build and test guide</title>
-</head>
-
-<body>
-<h1>FTensor build and test guide</h1>
-
-<p>This page is a guide to running the testing and timing programs for the
-FTensor tensor class library as part of GCC integration testing.  FTensor
-does not build successfully with versions of GCC earlier than 3.1.</p>
-
-<h2>Resource usage</h2>
-
-<p>The FTensor distribution, available at
-<a href="http://www.oonumerics.org/FTensor/FTensor_gcc_integration_test.tar.gz";>
-FTensor_gcc_integration_test.tar.gz</a>, is a 176K file.  The uncompressed
-distribution comprises some 4.5 MB of source files.  Building the testing
-and timing programs adds between 20 and 32 MB of object files and executables
-to this.</p>
-
-<p>On a Pentium III laptop, the conformance tests take 7 minutes and the
-performance tests take 3 minutes.</p>
-
-<h2>Prepare</h2>
-
-<p>To prepare for a build, perform the following:</p>
-<ul>
-<li>Unpack the file:
-<ul>
-<li><code>tar zxf FTensor_gcc_integration_test.tar.gz</code>, or</li>
-<li><code>gunzip -c FTensor_gcc_integration_test.tar.gz | tar xf -</code></li>
-</ul>
-</li>
-<li>Change directory to the repository thus created:
-<ul>
-<li><code>cd FTensor--main--1.1--patch-16</code></li>
-</ul>
-</li>
-</ul>
-
-<h2>Testing</h2>
-
-<p>FTensor tests in directory <code>tests/conformance</code> exercise
-most of the package's possible operations, and the tests in directory
-<code>tests/speed</code> compare how fast the FTensor classes are
-compared to ordinary arrays.  See the file <code>tests/README</code>
-for more information about the two sets of tests.</p>
-
-<p>To build and run the subset of conformance tests meant for compiler
-testing, do:</p>
-
-<code>
-cd tests/conformance
-<br />
-make CXX=&lt;compiler&gt; CXXOPTIMIZE="&lt;flags&gt;" test_compiler
-<br />
-./test_compiler
-</code>
-
-<p>The conformance tests print out <code>PASS</code> or <code>FAIL</code>
-followed by a unique test name.  There should be no failures.</p>
-
-<p>The path to the C++ compiler is defined in <code>CXX</code> and the
-compiler optimization options are defined in <code>CXXOPTIMIZE</code>
-in the Makefile.  If you don't override them as shown above,
-<code>CXX</code> will be <code>g++</code> and <code>CXXOPTIMIZE</code>
-will be the flags that are normally used by FTensor developers and
-users.  Testing with the usual flags ensures that FTensor will work for
-its users on your platform; testing with other optimizations might
-uncover GCC bugs.</p>
-
-<p>To build and run the performance tests using the optimizations that
-are normally used for them, simply do:</p>
-
-<code>
-cd tests/speed
-./one_over_script
-</code>
-
-<p>To use different optimizations and/or a different compiler, first do:</p>
-
-<code>
-make CXX=&lt;compiler&gt; CXXOPTIMIZE="&lt;flags&gt;" one_over one_over_fast
-</code>
-
-<p>In this case when the the script <code>one_over_script</code> invokes
-make, there is nothing for make to do.</p>
-
-<p>In addition to printing timing information, <code>one_over_script</code>
-prints out <code>PASS</code> or <code>FAIL</code> for each performance test,
-followed by the unique test name.  There should be no failures.</p>
-
-<h2>Timing</h2>
-
-<p>FTensor didn't build with versions of GCC before 3.1, so it cannot
-be used for comparing performance between GCC 3.1 and earlier versions.</p>
-
-<h2>Cleanup</h2>
-
-<p>Cleanup (to prepare the directory for a fresh run, e.g.
-with another version of the compiler), is done as follows:</p>
-
-<pre><code>(cd tests/conformance; make clean)
-(cd tests/speed; make clean)
-</code></pre>
-
-</body>
-</html>
Index: testing-lapack.html
===================================================================
RCS file: testing-lapack.html
diff -N testing-lapack.html
--- testing-lapack.html	8 Apr 2002 16:47:26 -0000	1.2
+++ /dev/null	1 Jan 1970 00:00:00 -0000
@@ -1,120 +0,0 @@
-<html>
-
-<head>
-<title>LAPACK build and test guide</title>
-</head>
-
-<body>
-<h1>LAPACK build and test guide</h1>
-
-<p>This page is a guide to building the LAPACK linear algebra
-package and running its testing and timing programs as part of
-GCC integration testing.</p>
-
-<h2>Resource usage</h2>
-
-<p>The LAPACK distribution, available from the netlib repository at
-<a href="http://www.netlib.org/lapack/lapack.tgz";>lapack.tgz</a>,
-is a 5 MB file.  The uncompressed LAPACK distribution comprises some 35 MB
-of source files.  Building the libraries, test and timing programs adds
-between 80 and 100 MB of objects, libraries and executables to this.</p>
-
-<p>On a 750 Mhz Pentium III laptop, building and testing LAPACK takes
-about 30 minutes.  Building and running the timing programs takes
-a lot longer.</p>
-
-<h2>Prepare</h2>
-
-<p>To prepare the LAPACK distribution, do the following:</p>
-<ul>
-<li>Unpack the .tgz file:
-    <ul>
-    <li><code>tar zxf lapack.tgz</code>, or</li>
-    <li><code>gunzip -c lapack.tgz | tar xf -</code></li>
-    </ul>
-</li>
-<li>Change directory to the repository thus created:
-    <ul>
-    <li><code>cd LAPACK</code></li>
-    </ul>
-</li>
-<li>Edit the include file of the main Makefile (<code>make.inc</code>):
-    <ul>
-    <li><code>PLAT = G77</code></li>
-    <li><code>FORTRAN = &lt;path_to_GCC_installation&gt;/bin/g77</code></li>
-    <li><code>OPTS = -g -O2 -funroll-loops</code></li>
-    <li><code>NOOPT = -g</code></li>
-    <li><code>LOADER = $(FORTRAN)</code></li>
-    <li><code>LOADOPTS = -Wl,-rpath=&lt;path_to_GCC_installation&gt;/lib
-        </code></li>
-    <li><code>RANLIB = ranlib</code></li>
-    <li><code>BLASLIB = ../../blas$(PLAT).a</code></li>
-    </ul>
-    Note that the value of RANLIB depends on ranlib being
-    available (and necessary) on your operating system.
-</li>
-<li>If you want to test LAPACK with an uninstalled compiler,
-    change the following in the above:
-    <ul>
-    <li>Add: <code>GCC_DIR = /path/to/gcc/build/directory</code></li>
-    <li>Change: <code>FORTRAN = $(GCC_DIR)/gcc/g77 -B$(GCC_DIR)/gcc/</code></li>
-    <li>Change: <code>LOADER = $(FORTRAN) -L$(GCC_DIR)/&lt;target&gt;/libf2c</code></li>
-    </ul>
-    where <code>&lt;target&gt;</code> is the target triple for your system (e.g.
-    <code>mips-sgi-irix6.5</code>)
-</li>
-</ul>
-
-<p>A final note:  On 64-bit targets, LAPACK cannot be built using GCC 2.95.2
-without specifying the <code>-femulate-complex</code> flag.  Building it
-using GCC 3.x should not need that flag.</p>
-
-<p>On Alphas it is necessary to add the flag <code>-mieee</code> to OPTS,
-NOOPT and LOADOPTS.</p>
-
-<h2>Build</h2>
-
-<p>The LAPACK Makefile assumes that you have the current
-directory in your path.  If this is not the case in your
-shell setup, use the following command line:</p>
-
-<code>(PATH=$PATH:. export PATH;
-make install blaslib lapacklib tmglib testing blas_testing)</code>
-
-<p>If the main memory in your machine is 512 Mbyte or larger,
-you are able to run the timing programs in addition to the
-testing programs that are run with the command above.  In that
-case, issue the command:</p>
-
-<code>(PATH=$PATH:. export PATH;
-make install blaslib lapacklib tmglib
-testing blas_testing timing blas_timing)</code>
-
-<h2>Test</h2>
-
-<p>The output of the testing programs is written into files with
-extension <code>.out</code> in the <code>TESTING</code> subdirectory of
-the main LAPACK directory.  Use the command <code>grep -i fail *.out</code>
-to find the number of failing tests.</p>
-
-<p>GCC 3.1 should not result in more failures than GCC 3.0.4</p>
-
-<h2>Time</h2>
-
-<p>TBD</p>
-
-<h2>Cleanup</h2>
-
-<p>Cleanup (to prepare the directory for a fresh run, e.g.
-with another version of the compiler), has to be done as follows:</p>
-
-<code>(PATH=$PATH:. export PATH; make clean;
-rm `find . -name '*.SUMM' -print`)</code>
-
-<p>The reason for this is that the LAPACK programs leave files
-behind with the extension .SUMM, which are opened with <code>
-STATUS='NEW'</code> - this will result in an abort if the files
-already exist.</p>
-
-</body>
-</html>
Index: testing-pooma.html
===================================================================
RCS file: testing-pooma.html
diff -N testing-pooma.html
--- testing-pooma.html	1 May 2002 12:36:50 -0000	1.4
+++ /dev/null	1 Jan 1970 00:00:00 -0000
@@ -1,100 +0,0 @@
-<html>
-
-<head>
-<title>POOMA build and test guide</title>
-</head>
-
-<body>
-<h1>POOMA build and test guide</h1>
-
-<p>This page is a guide to building the POOMA parallel object-oriented
-code and running its test programs.</p>
-
-<h2>Download and Extract</h2>
-
-<p>It is assumed that you already downloaded the POOMA code.</p>
-
-<p>To configure the source code, compile the source code and example
-programs, and run the examples, use:</p>
-<ul>
-<li>Unpack the .tar.gz file:
-    <ul>
-    <li><code>tar zxf pooma-gcc.tar.gz</code>, or</li>
-    <li><code>gunzip -c pooma-gcc.tar.gz | tar xf -</code></li>
-    </ul>
-</li>
-<li>Change directory to the repository thus created:
-    <ul>
-    <li><code>cd pooma-gcc</code></li>
-    </ul>
-</li>
-<li>The script tester.pl tests for host type using <code>uname</code>,
-    rather than target triples.   No further configuration is required  
-    when <code>uname</code> matches:
-    <ul>
-    <li>linux</li>
-    <li>irix64 - 64 bit Irix 6.x platforms</li>
-    <li>sunos - Sun Solaris</li>
-    </ul>
-</li>
-<li>For other architectures it is necessary to:
-    <ul>
-    <li>Add a line of code to tester.pl to recognise the platform.
-    For example, configuration for Cygwin required the patch:
-<pre>
---- tester.pl.orig      Sat Apr 27 14:43:39 2002
-+++ tester.pl   Sat Apr 27 14:53:15 2002
-@@ -79,6 +79,7 @@
- elsif ($uname =~ m/irix64/i)   { $arch = "SGIN32gcc"; }
- ## FIX How do I know when to use "SGI64gcc"?
- elsif ($uname =~ m/sunos/i)    { $arch = "SUNgcc"; }
-+elsif ($uname =~ m/cygwin/i)    { $arch = "CYGWINgcc"; }
- else
- {
-     die ("The ${uname} architecture is not supported.");
-</pre>
-    </li>
-    <li>Create a suitable file 
-      <code>config/arch/<em>ARCH</em>gcc-template.conf</code>.  
-      All that was required for cygwin was<br />
-      <code>cp config/arch/LINUXgcc-template.conf  
-        config/arch/CYGWINgcc-template.conf</code>
-    </li>
-    </ul>
-</li>
-</ul>
-
-
-<h2>Run</h2>
-
-<p>To configure the source code, compile the source code and example
-programs, and run the examples, use</p>
-<ul>
-<li><code>./tester.pl <em>gcc-location-prefix</em></code>
-
-    <p>where
-    <em>g++-location-prefix</em> specifies which gcc program to use.
-    We assume gcc is at <em>g++-location-prefix</em>/bin/gcc and the
-    associated C++ libraries are located at
-    <em>g++-location-prefix</em>/lib.  Command-line options are
-    documented at the beginning of tester.pl.</p>
-</li>
-<li>If unsuccessful, read the resulting tester.log log file and fix
-   the problem or email it to someone who can diagnose and fix the
-   problem.
-</li>
-</ul>
-
-<h2>Testing</h2>
-
-<p>The output of the testing programs gets written into
-tester.log.</p>
-
-<h2>Cleanup</h2>
-
-<p>Rerunning tester.pl will rerun the test programs but will not
-rebuild the library.  To force the library to be rebuilt, use
-<code>make realcleansuite</code>.</p>
-
-</body>
-</html>
Index: testing-qt.html
===================================================================
RCS file: testing-qt.html
diff -N testing-qt.html
--- testing-qt.html	8 Apr 2002 16:47:26 -0000	1.2
+++ /dev/null	1 Jan 1970 00:00:00 -0000
@@ -1,108 +0,0 @@
-<html>
-
-<head>
-<title>Qt build and test guide</title>
-</head>
-
-<body>
-<h1>Qt build and test guide</h1>
-
-<p>This page is a guide to building the Qt application development toolkit
-as part of GCC integration testing.</p>
-
-<h2>Resource usage</h2>
-
-<p>The Qt distribution, available from Trolltech's site at
-<a href="ftp://ftp.trolltech.com/qt/source/qt-x11-2.3.0.tar.gz";>
-qt-x11-2.3.0.tar.gz</a>, is an 8.7 MB file.  The uncompressed distribution
-comprises 40 MB of source files.  Building the package adds 40 to 75 MB
-of object files and executables to this.</p>
-
-<p>Building the entire Qt distribution on a 750 Mhz Pentium III laptop
-takes about 40 minutes.</p>
-
-<h2>Prepare</h2>
-
-<p>To prepare the Qt distribution, perform the following:</p>
-<ul>
-<li>Unpack the file:
-    <ul>
-    <li><code>tar zxf qt-x11-2.3.0.tar.gz</code>, or</li>
-    <li><code>gunzip -c qt-x11-2.3.0.tar.gz | tar xf -</code></li>
-    </ul>
-</li>
-<li>Rename the directory thus created and move to it:
-    <ul>
-    <li><code>mv qt-x11-2.3.0 qt; cd qt</code></li>
-    </ul>
-</li>
-<li>Define and export environment variables:
-    <ul>
-    <li><code>PATH</code> should include the <code>bin</code> directory
-        of the GCC installation under test.</li>
-    <li><code>LD_LIBRARY_PATH</code> should include the <code>lib</code>
-        directory of the GCC installation under test.</li>
-    <li><code>QTDIR</code> should be the full pathname of the top
-        directory of the Qt distribution (the one we just renamed as
-        <code>qt</code>).</li>
-    </ul>
-</li>
-<li>By default, the Qt package uses the compiler flags <code>-pipe -O2</code>.
-You can specify different flags by changing the values of
-<code>SYSCONF_CXXFLAGS</code> and <code>SYSCONF_CFLAGS</code> in the
-configuration file.  On a GNU/Linux system the configuration file is
-<code>configs/linux-g++-shared</code>.
-</li>
-</ul>
-
-<h2>Configure</h2>
-
-<p>Run the configure script before building the first time or after
-modifying the configuration file:</p>
-
-<pre><code>./configure</code></pre>
-
-<p>The configure script waits for input after printing:</p>
-
-<pre><code>This is the Qt Free Edition.
-
-You are licensed to use this software under the terms of either
-the Q Public License (QPL) or the GNU General Public License (GPL).
-
-Type 'Q' to view the Q Public License.
-Type 'G' to view the GNU General Public License.
-Type 'yes' to accept this license offer.
-Type 'no' to decline this license offer.
-
-Do you accept the terms of the license?
-</code></pre>
-
-<p>If you invoke <code>configure</code> from a script you can simply have
-an input file with the word "yes".</p>
- 
-<h2>Build</h2>
-
-<p>To build all of Qt, do:</p>
-
-<pre><code>make all</code></pre>
-
-<p>The <code>all</code> target includes several other targets.  You can
-build them separately if that's more convenient.</p>
-
-<h2>Testing</h2>
-
-<p>Qt has no automated tests.</p>
-
-<h2>Timing</h2>
-
-<p>Qt has no performance tests.</p>
-
-<h2>Cleanup</h2>
-
-<p>Cleanup (to prepare the directory for a fresh run, e.g.
-with another version of the compiler), is done as follows.</p>
-
-<pre><code>make -k clean</code></pre>
-
-</body>
-</html>
Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]