f57e22b203
2004/08/09 14:35:22 vg 1.18.2.12: RESYNC MERGED 1.18 1.19 Everything below this line will be added to the revision comment. 2004/07/18 20:13:15 vq 1.18.2.11: #i31676# Fix the dmake build problem for W32-4NT. 2004/07/14 16:16:23 vq 1.18.2.10: #i31446# Remove cygwin b2x cruft from set_soenv.in. 2004/07/09 21:39:48 rene 1.18.2.9: #i23779# Patch to use system libs - remove unneeded AC_MSG_CHECKING's - rename system{_,-}odbc / SYSTEM_ODBC to system{_,-}odbc{_,-}headers / SYSTEM_ODBC_HEADERS - regenerate configure 2004/07/06 12:48:42 rene 1.18.2.8: #i23779# Patch to use system libs - add missing curl configure help - add system-nas and system-neon + checks - check for headers with AC_CHECK_HEADER not AC_TRY_COMPILE Issue number: Submitted by: Reviewed by: 2004/07/05 14:01:24 cmc 1.18.2.7: #i30801# make curl an optional compile 2004/07/04 03:08:11 waratah 1.18.2.6: #i28835# Implement a switch for non-product builds without full debugging 2004/07/03 02:45:01 vq 1.18.2.5: #i29893# *crossmerge* Switch SOLARSRC to default style. 2004/07/02 16:52:25 cmc 1.18.2.4: #i30801# restrict to db3 2004/06/28 07:14:23 cmc 1.18.2.3: #i30801 allow using system libs if possible 2004/06/26 13:14:46 waratah 1.18.2.2: Correct missing semicolon 2004/06/26 13:10:32 waratah 1.18.2.1: Clean up old gcc 2.94 code |
||
---|---|---|
.. | ||
aclocal.m4 | ||
bootstrap.1 | ||
configure | ||
configure.in | ||
makefile.rc | ||
README | ||
set_soenv.in |
Various unresolved issues with configure: ---------------------------------------- * --with-gcc-home may cause a warning message to be displayed even if the correct version of gcc is found. This should be harmless. * It is at present time not possible to use --with-local-solenv to point to a solenv residing at a non-standard location. * The configure script also creates a bootstrap script in the top-level directory to support the creation of the build executable tools needed to bootstrap the build process. These tools normally reside in the solenv/$OUTPATH/bin directory for the supported platforms. It is hoped that these tools will be removed from the solenv tree at some stage. Running configure on Windows NT: ------------------------------- * configure must be run from the Cygnus bash shell. On the bash command line type "bash configure <options>" to run the script. The generated winenv.bat file must then be executed from the 4NT shell in which you will be building OpenOffice.org * The path to the Microsoft C/C++ compiler home directory must be given as an MS-DOS format path on the command line with the configure option --with-cl-home. MS-DOS format names are <8 characters in length and don't contain spaces. To get the MS-DOS format of a Windows pathname select the directory in a window and right-click and choose properties. * configure automatically copies the top level makefile.rc from the config_office directory to the top level directory when run. If you are not running configure and are using a pre-generated winenv.bat to set up the build environment, then you must manually copy the makefile.rc file in config_office to the top level directory. * It is recommended that you close the Cygnus bash shell before you start the build as it might cause problems later on. Some quasi standards for configure ---------------------------------- * configure will use four type of parameters: --with-xyz-home to locate an executable tool and related libraries, eg jdk. --with-xyz to locate a library of that type --without-xyz to disable a library, not always available. --enable-xyz to set a compile feature such as debugging. * Try and make tests as generic as possible, specific is good for early testing of a feature but don't keep the pattern, make it generic quickly. * configure should terminate with an error if it does not locate something that is needed for a build to succeed, note that this conflicts with previous standards which had a manual entry override. This is less than successful configure either works or it fails, no data entry allowed. Premises for configure ---------------------- * This is not a true autoconf project. The code base is huge and the ability to test for everything is impossible. We are currently supporting only a subset of compilers therefore do not need a lot of testing on compiler capabilities.