Salome HOME
copy tag mergefrom_BR_V0_1_CC_Salome_04oct07
[modules/yacs.git] / INSTALL
1 Installation Instructions
2 *************************
3
4 Specific part for YACS
5 ~~~~~~~~~~~~~~~~~~~~~~
6
7 Prerequisites
8 =============
9 YACS needs:
10  - g++ 3.3.5 or more,
11  - CPPUNIT
12  - omniORB 4.05 or more,
13  - Python,
14  - SALOME 3.2.x KERNEL (for SALOME tests)
15
16 **WARNINGS**:
17  -  with g++>= 4.1, problem with CORBA::Any and double, for omniORB <= 4.0.7
18     You need to take the latest omniORB cvs snapshot from http://omniorb.sourceforge.net/snapshots
19
20 Build and check
21 ===============
22
23 SALOME is required for directories runtime and yacsloader. For tests with make check,
24 we suppose that all SALOME <modules>_ROOT_DIR are in a directory under a name
25 <PATH_TO_ROOT_DIR>/<MODULE>_<VERSION>, for instance $HOME/SALOME/KERNEL_V3_2_3.
26 We also suppose that there a script that sets prerequisites environment for SALOME
27 under the name <PATH_TO_ROOT_DIR>/profile_<VERSION>.
28 So, to define SALOME installation, just KERNEL_ROOT_DIR is required. Other path
29 are deduced.
30
31 build and install are done in separate directories, not in source directory.
32 For instance, if the path to YACS sources is ${BASEREP}/YACS_SRC::
33
34   export KERNEL_ROOT_DIR=...
35
36   cd ${BASEREP}
37   rm -rf build install
38   mkdir build install
39
40   cd ${BASEREP}/YACS_SRC
41   ./root_clean
42   ./build_configure
43
44   cd ${BASEREP}/build
45   ../YACS_SRC/configure --prefix=${BASEREP}/install
46
47   make
48   make check
49
50   make install
51   
52
53 Generic part
54 ~~~~~~~~~~~~
55
56 Copyright (C) 1994, 1995, 1996, 1999, 2000, 2001, 2002, 2004, 2005 Free
57 Software Foundation, Inc.
58
59 This file is free documentation; the Free Software Foundation gives
60 unlimited permission to copy, distribute and modify it.
61
62 Basic Installation
63 ==================
64
65 These are generic installation instructions.
66
67 The `configure' shell script attempts to guess correct values for
68 various system-dependent variables used during compilation.  It uses
69 those values to create a `Makefile' in each directory of the package.
70 It may also create one or more `.h' files containing system-dependent
71 definitions.  Finally, it creates a shell script `config.status' that
72 you can run in the future to recreate the current configuration, and a
73 file `config.log' containing compiler output (useful mainly for
74 debugging `configure').
75
76 It can also use an optional file (typically called `config.cache'
77 and enabled with `--cache-file=config.cache' or simply `-C') that saves
78 the results of its tests to speed up reconfiguring.  (Caching is
79 disabled by default to prevent problems with accidental use of stale
80 cache files.)
81
82 If you need to do unusual things to compile the package, please try
83 to figure out how `configure' could check whether to do them, and mail
84 diffs or instructions to the address given in the `README' so they can
85 be considered for the next release.  If you are using the cache, and at
86 some point `config.cache' contains results you don't want to keep, you
87 may remove or edit it.
88
89 The file `configure.ac' (or `configure.in') is used to create
90 `configure' by a program called `autoconf'.  You only need
91 `configure.ac' if you want to change it or regenerate `configure' using
92 a newer version of `autoconf'.
93
94 The simplest way to compile this package is:
95
96   1. `cd' to the directory containing the package's source code and type
97      `./configure' to configure the package for your system.  If you're
98      using `csh' on an old version of System V, you might need to type
99      `sh ./configure' instead to prevent `csh' from trying to execute
100      `configure' itself.
101
102      Running `configure' takes awhile.  While running, it prints some
103      messages telling which features it is checking for.
104
105   2. Type `make' to compile the package.
106
107   3. Optionally, type `make check' to run any self-tests that come with
108      the package.
109
110   4. Type `make install' to install the programs and any data files and
111      documentation.
112
113   5. You can remove the program binaries and object files from the
114      source code directory by typing `make clean'.  To also remove the
115      files that `configure' created (so you can compile the package for
116      a different kind of computer), type `make distclean'.  There is
117      also a `make maintainer-clean' target, but that is intended mainly
118      for the package's developers.  If you use it, you may have to get
119      all sorts of other programs in order to regenerate files that came
120      with the distribution.
121
122 Compilers and Options
123 =====================
124
125 Some systems require unusual options for compilation or linking that the
126 `configure' script does not know about.  Run `./configure --help' for
127 details on some of the pertinent environment variables.
128
129    You can give `configure' initial values for configuration parameters
130 by setting variables in the command line or in the environment.  Here
131 is an example:
132
133      ./configure CC=c89 CFLAGS=-O2 LIBS=-lposix
134
135    *Note Defining Variables::, for more details.
136
137 Compiling For Multiple Architectures
138 ====================================
139
140 You can compile the package for more than one kind of computer at the
141 same time, by placing the object files for each architecture in their
142 own directory.  To do this, you must use a version of `make' that
143 supports the `VPATH' variable, such as GNU `make'.  `cd' to the
144 directory where you want the object files and executables to go and run
145 the `configure' script.  `configure' automatically checks for the
146 source code in the directory that `configure' is in and in `..'.
147
148    If you have to use a `make' that does not support the `VPATH'
149 variable, you have to compile the package for one architecture at a
150 time in the source code directory.  After you have installed the
151 package for one architecture, use `make distclean' before reconfiguring
152 for another architecture.
153
154 Installation Names
155 ==================
156
157 By default, `make install' will install the package's files in
158 `/usr/local/bin', `/usr/local/man', etc.  You can specify an
159 installation prefix other than `/usr/local' by giving `configure' the
160 option `--prefix=PREFIX'.
161
162    You can specify separate installation prefixes for
163 architecture-specific files and architecture-independent files.  If you
164 give `configure' the option `--exec-prefix=PREFIX', the package will
165 use PREFIX as the prefix for installing programs and libraries.
166 Documentation and other data files will still use the regular prefix.
167
168    In addition, if you use an unusual directory layout you can give
169 options like `--bindir=DIR' to specify different values for particular
170 kinds of files.  Run `configure --help' for a list of the directories
171 you can set and what kinds of files go in them.
172
173    If the package supports it, you can cause programs to be installed
174 with an extra prefix or suffix on their names by giving `configure' the
175 option `--program-prefix=PREFIX' or `--program-suffix=SUFFIX'.
176
177 Optional Features
178 =================
179
180 Some packages pay attention to `--enable-FEATURE' options to
181 `configure', where FEATURE indicates an optional part of the package.
182 They may also pay attention to `--with-PACKAGE' options, where PACKAGE
183 is something like `gnu-as' or `x' (for the X Window System).  The
184 `README' should mention any `--enable-' and `--with-' options that the
185 package recognizes.
186
187    For packages that use the X Window System, `configure' can usually
188 find the X include and library files automatically, but if it doesn't,
189 you can use the `configure' options `--x-includes=DIR' and
190 `--x-libraries=DIR' to specify their locations.
191
192 Specifying the System Type
193 ==========================
194
195 There may be some features `configure' cannot figure out automatically,
196 but needs to determine by the type of machine the package will run on.
197 Usually, assuming the package is built to be run on the _same_
198 architectures, `configure' can figure that out, but if it prints a
199 message saying it cannot guess the machine type, give it the
200 `--build=TYPE' option.  TYPE can either be a short name for the system
201 type, such as `sun4', or a canonical name which has the form:
202
203      CPU-COMPANY-SYSTEM
204
205 where SYSTEM can have one of these forms:
206
207      OS KERNEL-OS
208
209    See the file `config.sub' for the possible values of each field.  If
210 `config.sub' isn't included in this package, then this package doesn't
211 need to know the machine type.
212
213    If you are _building_ compiler tools for cross-compiling, you should
214 use the `--target=TYPE' option to select the type of system they will
215 produce code for.
216
217    If you want to _use_ a cross compiler, that generates code for a
218 platform different from the build platform, you should specify the
219 "host" platform (i.e., that on which the generated programs will
220 eventually be run) with `--host=TYPE'.
221
222 Sharing Defaults
223 ================
224
225 If you want to set default values for `configure' scripts to share, you
226 can create a site shell script called `config.site' that gives default
227 values for variables like `CC', `cache_file', and `prefix'.
228 `configure' looks for `PREFIX/share/config.site' if it exists, then
229 `PREFIX/etc/config.site' if it exists.  Or, you can set the
230 `CONFIG_SITE' environment variable to the location of the site script.
231 A warning: not all `configure' scripts look for a site script.
232
233 Defining Variables
234 ==================
235
236 Variables not defined in a site shell script can be set in the
237 environment passed to `configure'.  However, some packages may run
238 configure again during the build, and the customized values of these
239 variables may be lost.  In order to avoid this problem, you should set
240 them in the `configure' command line, using `VAR=value'.  For example:
241
242      ./configure CC=/usr/local2/bin/gcc
243
244 causes the specified `gcc' to be used as the C compiler (unless it is
245 overridden in the site shell script).  Here is a another example:
246
247      /bin/bash ./configure CONFIG_SHELL=/bin/bash
248
249 Here the `CONFIG_SHELL=/bin/bash' operand causes subsequent
250 configuration-related scripts to be executed by `/bin/bash'.
251
252 `configure' Invocation
253 ======================
254
255 `configure' recognizes the following options to control how it operates.
256
257 `--help'
258 `-h'
259      Print a summary of the options to `configure', and exit.
260
261 `--version'
262 `-V'
263      Print the version of Autoconf used to generate the `configure'
264      script, and exit.
265
266 `--cache-file=FILE'
267      Enable the cache: use and save the results of the tests in FILE,
268      traditionally `config.cache'.  FILE defaults to `/dev/null' to
269      disable caching.
270
271 `--config-cache'
272 `-C'
273      Alias for `--cache-file=config.cache'.
274
275 `--quiet'
276 `--silent'
277 `-q'
278      Do not print messages saying which checks are being made.  To
279      suppress all normal output, redirect it to `/dev/null' (any error
280      messages will still be shown).
281
282 `--srcdir=DIR'
283      Look for the package's source code in directory DIR.  Usually
284      `configure' can determine that directory automatically.
285
286 `configure' also accepts some other, not widely useful, options.  Run
287 `configure --help' for more details.
288