123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366 |
- Fetching and Building REDUCE
- ============================
- January 2015
- June 2020
- The notes here are about having a full set of Reduce sources fetched from
- Sourceforge and compiling them on your own computer. Following that path
- lets you track the most recent changes, updates and corrections. Because
- both Reduce and the platforms that people may wish to build on change over
- time what is explained here will almost always have a few details where it
- is out of date: so check the date to see how recently this has been refreshed.
- But almost always the changes needed to what is explained here will be small,
- and if you find some please report back to the Reduce mailing list for the
- benefit of others.
- The prerequisites for using this package will depend somewhat on whether
- you choose to use the CSL or PSL build.
- Users of PSL will use the ready-build binaries of the PSL Lisp system that
- are present in the material hosted at Sourceforge. Rebuilding PSL from source
- is possible but the procedures are not covered at all here and anybody needing
- to do that probably needs to consult the PSL experts. Because PSL uses
- pre-made binaries these have to be present for the architecture you are using.
- They are available for all the most important or common cases. Because the
- binaries are pre-made there are few demands for compilers or special
- libraries installed on the computer you will use PSL on.
- For CSL you need to be able to compile both CSL itself and the FOX toolkit
- on which it depends. Please note that even if you have FOX available already
- on your computer the code her uses a (slightly) customised version and your
- standard system-wide installation of FOX will not be used and should be
- irrelevant here. To join in development work on what is hoped to be a future
- version of CSL-Reduce you would also need to be able to work with wxWidgets.
- You will need:
- For Windows, the "cygwin" environment providing a "bash" shell.
- Note that building under "msys" or the plain Windows command
- prompt is not possible (without you doing significant work of your
- own to arrange for it). Obviously it will be sensible to keep your
- cygwin installation up to date, and some updates there have in the
- past not always been upards compatible. The aim is to keep the
- current CSL/Reduce at Sourceforge buildable using the most recent
- cygwin release. But any difficulty due to temporary bugs or glitches
- at the cygwin end can not be resolved here! These days you MUST use
- the 64-bit version of cygwin - note that the obsolete 32-bit one is
- deprecated by its suppliers.
- The command scripts/cygwin-sanity-check.sh attempts to check if
- sufficient cygwin components have been installed, and it may save
- you pain if you try it and respond to its suggestions before trying
- a full build of Reduce.
- For Macintosh you need the XCode command line tools, and you are liable
- to need to use Macports to fetch and install a significant number
- of commands and libraries that Apple do not provide as standard.
- There is a file in the scripts directory that I use to fetch the
- set of "ports" that I use. You will also need Xquartz to support the
- GUI.
- For Linux you can inspect scripts/ubuntu-sanity-check.sh or the fedora
- equivalent to find a script that installs what is probably a superset
- of the packages you will need.
- For other platforms there is a hope that everything will work if you
- can provide a bash shell and enough development libraries, but you
- mat need to sort out details for yourself. Here are a few more comments:
- GNU make (other versions of "make" are not liable to work), autoconf,
- automake and libtool. All should be at least tolerably up to date
- versions.
- You need a C++ development context. On Windows you need the
- and "mingw-x86_64" compiler variants (as well as plain g++) from
- cygwin while on other systems you need X11 and other
- development capability, including Xft, fontconfig, (n)curses, Posix
- threads. The building has been tested using versions of both gcc
- and clang. The compiler should be new enough that it supports C++11
- and for choice C++17.
- I have (recently) built using cygwin64, Ubuntu and Fedora Linuxes
- on pcs, Raspbian (raspberry Pi OS, both 32 and 64-bit variants) on a
- Raspberry Pi and OSX Catalina. In the past I have built using PCBSD/FreeBSD
- and Solaris on both pc and sparc (requiring significant
- extra software installation), SGI, HP-pa, the IBM z-architecture and at one
- stage (not now I think) I coudd run Reduce on an HP IPAQ 4700 PDA or an
- openWRT router. The hope is that almost any machine with a C++ compiler
- should suffice for the basic system. In case of a challenging environment
- it may be prudent to do initial testing by running
- "./configure --with-csl --without-gui" to avoid all attempts to build
- windowing libraries. Also in recent years I have started to suppose that all
- computers have substantial amounts of memory, so ones with only a few megabytes
- (or even only tend or hundreds) may cause problems.
- One of the most common problems people seem to have the first time that they
- try to build CSL arises when they do not have quite all the necessary tools,
- libraries and header files installed. While most relevant run-time libraries
- are liable to have been provided for them by default, the development versions
- might not have. The state of your cygwin installation can be checked using
- scripts/cygwin-sanity-check.sh but please be aware that the tests that does
- are indicative rather than definitive and when (occasionally) either Reduce
- is extended and additional dependencies arise or cygwin is reorganised and the
- names of some packages alter the tests may become outdated.
- If you try to build REDUCE but one of the programming tools or development
- libraries that is required is not available then there is no guarantee that
- the failure that results will describe itself to you clearly! If the failure
- is detected at configuer time the evidence will be in a file "config.log"
- (possibly somewhere within the cslbuild directory). In case of trouble I often
- go
- script buildlog.log
- rm -rf cslbuild
- ./configure --with-csl
- make
- exit
- and then buildlog.log contains a full transcript of all the output from the
- attempt. Its size can be daunting and distinguishing between messages,
- warnings, observations and errors can take experience!
- To try to make that easier to cope with I provide a script that attempts to
- check for prerequisites and that is lighter weight than the full configuration
- process and maybe reports trouble in a cleaner way. To use it select the
- Reduce "trunk" directory as current and at a bash prompt (you MUST have
- "bash" available as a shell, and you will run least risk if you run all
- scripts from it. I have tried to make most of them compatible with a legacy
- /bin/sh but testing and guaranteeing that is tedious) go
- scripts/csl-sanity-check.sh
- This should run auto-configure scripts and eventually compile and run a small
- program that pops up a dull window. If you get the window at the end it has
- succeeded and you can try building Reduce. If not then it probably reports
- a step where some header file or library is missing. You need to search the
- installation sources relevant your operating system and install more stuff,
- then try again. Eg for cygwin you re-run "setup", while on Linux you are
- looking at "apt-get" and "yum" and various other package managers. You need
- to check the documentation of your particular operating system - or perhaps
- better find local expert to get you started.
- Note that if you configure using "--with-csl --with-wx" you also need GTK2
- (GTK+) development files if you are on an X11-based platform, but at present
- csl-sanity-check.sh does not test for that.
- Some people may find that they need things that are not installed on
- their system but they have not been granted adminitrator authority and so
- can not merely install them in the obvious way. The easiest response is to
- talk to a local system manager! But for a range of the tools (eg autoconf,
- make, ncurses etc) if you can not identify a ready-built binary
- package that suits your environment it will be easy to build one from sources
- found "at the usual places", and may be easy to arrange that the resulting
- binaries are on your PATH and libraries somewhere where they will be found.
- But in such a case you may end up needing to hand-patch some of the Makefiles
- here.
- If you have run the main CSL/Reduce configure step, as in
- ./configure --with-csl
- and tried "make" at a stage when you do not have all relevant headers and
- libraries installed then the build can fail part way through in a messy way.
- In principle you can check ALL the logs and work out what happened, but in
- reality that can be daunting. Furthermore it can get in a state where a
- subsequent use of "make" fails in an unhelpful manner. Experts can patch
- things up and recover, but the simplest approach in case of confusion is
- rm -rf cslbuild
- ./configure --with-csl
- make
- where all the partially build stuff that had accumulated in cslbuild is
- discarded and the configuration and compilation is started afresh. Obviously
- you will not delete that directory if you have put important files of your
- own there!
- A feature of subversion is that if you change any file locally then your local
- edit is interpreted as a possibly valuable update that you may at some stage
- contribute back into the project. This is good, but it means that if you
- accidentally corrupt a local copy of some file then subversion will NOT
- automatically repair it. So if you have just recently started with Reduce and
- something odd is happening it may make sense to get yourself back in lock-step
- with the central repository. You are provided with two scripts
- scripts/make-pristine.sh
- scripts/stamp.sh
- The first of those merely issues the subversion commands that discard all local
- changes you have made to bring everything into step. The second updates the
- time-stamps on various configuration files so that when you run "configure"
- it should not attempt to use autoconf and automake locally, but instead should
- be content with the files as fetched. These two scripts can avoid confusion
- early on. Once you are fully working and especially if you are doing your own
- development within Reduce you will not wish to use them.
- You can fetch or update REDUCE in one of (at least) two ways
- (1) Fetch a file from the Sourceforge download area, eg from the
- reduce-algebra-source section. Unpack it. Note that the full archives
- at sourceforge are updated sporadically and not to any coherent schedule,
- so what you get could be a little out of date. Thus this scheme is not
- recommended!
- OR
- (2) Use subversion to fetch or refresh a copy from the master site.
- svn checkout \
- svn://svn.code.sf.net/p/reduce-algebra/code/trunk \
- reduce-algebra
- That should create a directory called "reduce-algebra" for you.
- To refresh your files, enter the reduce-algebra directory and go
- svn update
- You can check the documentation of subversion (svn) to discover
- what further options and possibilities tare provided. Two notable
- advanntages of this are (a) "svn update" lets you refresh your copy
- to match the very latest one available without needing to fetch
- everything again afresh and (n) "svn -r NNNN update" lets you update
- you local copy to match "revision NNNN", a possibly older copy of
- everything, so if the main development version is even temporarily
- broken (that should only happen accidentally!) you can fetch older
- versions for comparison.
- The version fetched and updated using subversion (hah - note that you
- need "subversion" installed on your computer to do this!) will be fully
- up to date. That naturally means that at some moments it will include
- changes that temporarily break it, but in general any such should be
- corrected fairly rapdily. Furthermore by browsing the documentation of
- subversion you can find out how to check out a version from say 2 weeks
- ago (or indeed any historical varient) if needbe.
- The simplest way version of the build process is to select the directory
- where REDUCE was unpacked as current and issue one of the command
- ./configure --with-csl
- OR ./configure --with-psl
- (or first one of those then the other)
- It ought not to be necessary to provide any other options to the configure
- script or to pre-set environment variables, but for experts there are (of
- course) many opportunities for customisation. If you find you are on a platform
- where simple use of the configure script is insufficient please report that
- so that things can be updated and users in the future will come closer to
- find that everything works first time without fuss.
- Follow that by the command "make" and if all goes well everything relevant
- will be compiled. But at least in the CSL case please try
- scripts/csl-sanity-check.sh first - it may save you a lot of agony.
- If you build both the CSL and PSL versions then it can be a comfort to
- run
- scripts/testall.sh
- which runs all the various test scripts and displays a report showing any
- places where the output on your machine does not match reference versions
- of the logs. Directories called csl-times and psl-times end up with the
- log output. In some cases log discrepancies are expected! For instance some
- of the test files generate timing reports so their output varies depending on
- the speed or size of your computer. In other cases improvements to the
- system may change test output but the reference logs may not have been
- updated to reflect it. Some logs are there to highlight difference between
- detailed behaviour of CSL and PSL that are not hugely important but that
- may be addressed at some stage in the future.
- For (some sort of) convenience a script "rebuild.sh" in the top level of
- the distribution tries to do this for both PSL and CSL and it then leaves
- overall log files also at the top level.
- You can then run REDUCE using the command
- bin/redcsl
- or
- bin/redpsl
- [At present I do not in any way guarantee (and I probably do not even expect)
- that the usual "configure" option "--prefix=..." or the idiom "make install"
- will behave as you might have hoped. Indeed there are reports that at
- present "make install" is deeply broken and SHOULD NOT BE ATTEMPTED.
- But there is scripts/mk-snapshots.sh which is used to build the distribution
- snapshots and those can then be installed.]
- Any machine you are on is attributed an identity such as x86_64-pc-windows
- or x86_64-unknown-ubuntu10.10. Note that this is slightly more specific than
- the normal GNU host triple in that it attempts to include the name of a Linux
- distribution. Binaries are actually built within cslbuild/<triple> or
- pslbuild/<triple>. This arrangement is intended to be helpful if you have one
- file-space shared between several machine that may have different
- architectures. So the scripts like bin/redcsl deduce where to look and
- chain to binaries there. In the CSL case you could make a symbolic link
- as in "ln -s .../trunk/cslbuild/<triple>/csl/reduce XXXX" where XXXX is some
- location on your PATH which then lets you launch Reduce more directly. Reduce
- needs some resources in the same directory as the main executable so merely
- copying <triple>/csl/reduce to somewhere else is not liable to be a good idea.
- Logs from building and testing Reduce end up in the directory where the
- main binary gets created, so if things go wrong that is where you may wish
- to look.
- There are a number of optional ways in which configuration may be customised:
- ./configure --with-csl --enable-debug
- Enable "gcc -g" compilation of the C parts of CSL so that gdb can be
- used to debug things.
- ./configure --with-csl --without-gui
- ./configure --with-csl --with-wx
- By default the CSL version build in support for a GUI using the FOX
- toolkit. If for some reason that is not required or can not be supported
- then "--without-gui" removes it. There are some plans to change to use
- wxWidgets rather than FOX, and "--with-wx" enables the experimental build
- for that. At the time of writing the code compiles but is significantly
- unfinished. Volunteers to help complete it would be useful! But neither of
- these options are a very good idea for ordinary users!
- There are other options, many of which are experimental or historical.
- See "./configure --help" for a definitive list.
- Developers and some more ambitious users may need to understand the
- directory layout in more detail. The document "Inside Reduce" the
- the "primers" part of the Reduce documentation directory may provide
- useful guidance.
- The main directories supplied are as follows, where MACHINE stands for
- a machine identification, eg x86_64-pc-windows-debug.
- trunk The main version of everything
- bin Scripts to launch REDUCE etc
- csl/cslbase Main CSL Lisp sources
- fox the FOX GUI toolkit, an LGPL package
- cslbuild/generated-c Part of REDUCE compiled into C
- MACHINE/csl where REDUCE binaries are built
- fox where the FOX GUI toolkit is built
- packages/alg REDUCE sources, on package per directory
- ...
- ztrans
- psl/psl-amd64 Ready-build binaries of the PSL Lisp system ...
- ... ...
- psl/win32 ... for a variety of architectures
- pslbuild/MACHINE/. where REDUCE gets built
- psl copy of relevant architecture-specific PSL
- red REDUCE built binary "fasl" and image files
- deps used to record dependencies in the build
- scripts scripts used to maintain the system.
- If you are working on just one platform and have completed the configuration
- and done an initial build you may like to select either cslbuild/MACHINE/csl
- or pslbuild/MACHINE as your current directory: the Makefile that ends up there
- is the main one used for rebuilding the system.
- For special purposes you may wish to investigate the csl/jlisp directory (all
- Reduce runnable via Java - distinctly slower and at present the user interface
- is not well sorted, but it might be fun) and csl/new-embedded (a kit for
- making a simple small C-coded version for potential use as a component in
- some other software rather than a free-standing complete program). Both of
- these are for experienced programmers who want to use them in some broader
- project rather than being fully supported variants on Reduce itself.
- There are also "spins" of Reduce by way of extra files and scripts that have
- made it possible to build the system on other Lisps, from Common Lisp as
- far as emacs lisp. There are a range of alternative interfaces for both
- console and GUI purposes in varying states of support and maturity.
- The more alive the Reduce project is the more you can expect there to be
- additions, changes and enhancements but please understand that these all
- carry risk of transient introduction of bugs. Report trouble to us via
- Sourceforge and when and if we can we will fix them. But all the source code
- is there so you can also join in the debugging and propose fixes (please!)
- A C Norman. July 2008. Updated Jan 2009, September 2010, March 2011,
- September 2014, January 2015, June 2020.
|