Arthur C. Norman 2933d80244 Add ileftshift, ileqv and ensure that irightshift adheres to C++ constraints 2 years ago
..
cslbase 2933d80244 Add ileftshift, ileqv and ensure that irightshift adheres to C++ constraints 2 years ago
embedded 0928d10632 This continues the process of moving to more idiomatic C++ with full adoption 5 years ago
fox 4b391b2553 The CSL compiler into bytecodes wants to make "car car x" onto "caar x" 2 years ago
foxtests edd6595002 A further round of updates to configure.ac. autoconf 2.61 is (I think) 3 years ago
generated-c 223f6588c5 scripts/test1 and hence testall now produce output that lines up in reasonably 2 years ago
m4 b14dd3afb5 The TEMPORARY file macports-setup-m1.sh is the recipe that I now hope/believe 2 years ago
new-embedded 749557ed5a Web REDUCE: minor build updates 2 years ago
reduce.doc 5048536b27 Update the license details slightly 8 years ago
support-packages 61f114ebfd I have been trying to speed CSL up on some cases where it has been reported 2 years ago
winbuild dd7bf6830d This tried to put in some fairly minor titying up changes into the 3 years ago
Makefile.am 62f646ef08 CSL: I have cleaned up some of the autoconf etc stuff so that reautoconf 5 years ago
Makefile.in 8512b0fe2e Thanks to Francis Wright for two very useful hints used in this revision. 3 years ago
README.testprogram 8cf3cf6ac4 Update the file a bit to respond to reports of it being incorrect 7 years ago
aclocal.m4 8512b0fe2e Thanks to Francis Wright for two very useful hints used in this revision. 3 years ago
autogen.sh 73a3c87be8 Correct a type reported by Alan Barnes (thank you!) 4 years ago
config.h.in 84b3b562f2 Substantial changes to the rataprx package. 5 years ago
configure 8512b0fe2e Thanks to Francis Wright for two very useful hints used in this revision. 3 years ago
configure.ac 441d6cbb9d Update more configure.ac files. Note that I will next need to check that these 3 years ago
kb.txt 327e3caf23 further removal of spurious svn:exectuable tags 12 years ago
libwindow.h 21ec08b967 This is a bigish check-in for CSL, so it gets a longet than usual explanation 8 years ago
solaris-notes.txt 327e3caf23 further removal of spurious svn:exectuable tags 12 years ago
testprogram.cpp 677427441a A recent commit changed eg printf to std::printf everywhere, and adjusted the 4 years ago
window.cpp 677427441a A recent commit changed eg printf to std::printf everywhere, and adjusted the 4 years ago

README.testprogram

Configuring in the CSL directory
================================


One of the most common causes of failure when trying to build CSL and Reduce
seems to be not having all the necessary development tools and libraries
installed and available. When things go wrong because of this there will
probably be a message somewhere in a configure or build log that can in
fact point at what has happened, but it is often tedious and non-obvious
to even experienced developers to find that.

So the .../trunk/csl directory contains a mini-project called "testprogram"
such that configuring and building it should be a reasonable sanity check
on your build environment. On Windows it creates a trivial dialog box that
can be closed by clicking the button in it, while on systems that use X it
puts a medium sized window in the middle of your screen and you can close
that using the close button that a window manager will attach to it.

These programs are crude and minimal - so they do not test everything - and
also the configure script that goes with them may report fatal errors in
cases where manual adjustment of resulting Makefiles could coax a full
version of Reduce to build. So please view this as an attempt to be helpful
and check for a collection of things that are expected and not as a carefully
engineered and precise qualification test for your platform!

From the trunk directory you can go
scripts/csl-sanity-check.sh
which carries out the steps described below.


The explanation here is for the benefit of peopel who wish to run through
the checks manually - presumably because there is some problem for them.

[optionally] autoreconf -f -i -v [in trunk/csl]
This will re-make the various autoconf-related files. You may not
need to do this, but if you get complaints about automake
version compatibility this is what you should try. Note that
the script .../trunk/autogen.sh performs this process in all relevant
parts of your local tree, so can be useful if autoreconf proves
necessary here. Indeed I would tend to view the use of the
autogen.sh script in the trunk directory as preferable since it
recreates configure-related scripts throughout the REDUCE tree.

./configure [in trunk/csl]
Some people will quite properly prefer
cd /tmp; .../reduce-algebra/trunk/csl/configure
so that the test performed here does not leave any files within the
main source tree. The top-level mechanisms to run the tests build
the test stuff in the ...trunk/cslbuild directory. Again this indicates
that useing scripts/csl-sanity-check is generally a good plan.
The configure script will take of the order of 30 second to (say)
ten minutes depending on how fast your computer and which operating
system it is running. If all goes well the final few lines of output
should be along the lines of
configure: creating ./config.status
config.status: creating Makefile
config.status: executing depfiles commands
configure: Build environment seems OK
If this is not the case and you get a diagnostic I hope it will be
a clean one asking you to install some particular tool or library.
Note that for the package management systems that come with many
operating systems you will need to install the "development" variant
of support for a package. Eg "ncurses-dev" rather than only "ncurses".

If the configure script fails but without a clear message asking you
to install some particular package then you can look at the log
file "config.log" to try to understand what went wrong, and when you
have found out please consider updating the configure script (in the
file "configure.ac") and reporting your proposed updates back to the
package maintainers.

make
Whether you configured in the source tree or in /tmp (or indeed
anywhere else) a call to "make" should compile a small test
program called "testprogram". If the compilation fails then you
will need to debug, update configure.ac to detect that cause of the
problem cleanly and report back to the Reduce developers.

Note that if you are not using either cygwin or Linux then it
might be prudent to check that you use the GNU version of "make"
rather than any other version, since for the main Reduce build
you will need that. You can verify that you have GNU make by
giving the command
make --version
and if "make" does not give a brief response identifying itself
as GNU Make then try "gmake" instead in case the version you need is
available under that name.

./testprogram
Finally you can try the program. Under X windows it will fail in a
messy way if you do not have any 24-point fonts installed, and the
font it uses to display a message is the first font of that size
that it comes across (and so will often be ugly). The test program
is not intended to be clever or pretty - it is just a chance to
verify that a library can be created and then linked to and that
the fundamental Windows or X libraries can be used.



===============================