configuration
上传用户:qaz666999
上传日期:2022-08-06
资源大小:2570k
文件大小:14k
源码类别:

数学计算

开发平台:

Unix_Linux

  1. /* doc/configuration (in Emacs -*-outline-*- format). */
  2. Copyright 2000, 2001, 2002, 2003, 2004 Free Software Foundation, Inc.
  3. This file is part of the GNU MP Library.
  4. The GNU MP Library is free software; you can redistribute it and/or modify
  5. it under the terms of the GNU Lesser General Public License as published by
  6. the Free Software Foundation; either version 3 of the License, or (at your
  7. option) any later version.
  8. The GNU MP Library is distributed in the hope that it will be useful, but
  9. WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
  10. or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU Lesser General Public
  11. License for more details.
  12. You should have received a copy of the GNU Lesser General Public License
  13. along with the GNU MP Library.  If not, see http://www.gnu.org/licenses/.
  14. * Adding a new file
  15. ** Adding a top-level file
  16.   i) Add it to libgmp_la_SOURCES in Makefile.am.
  17.   ii) If libmp.la needs it (usually doesn't), then add it to
  18.       libmp_la_SOURCES too.
  19. ** Adding a subdirectory file
  20. For instance for mpz,
  21.   i) Add file.c to libmpz_la_SOURCES in mpz/Makefile.am.
  22.   ii) Add mpz/file$U.lo to MPZ_OBJECTS in the top-level Makefile.am
  23.   iii) If for some reason libmp.la needs it (usually doesn't) then add
  24.        mpz/file$U.lo to libmp_la_DEPENDENCIES in the top-level
  25.        Makefile.am too.
  26. The same applies to mpf, mpq, scanf and printf.
  27. ** Adding an mpn file
  28. The way we build libmpn (in the `mpn' subdirectory) is quite special.
  29. Currently only mpn/mp_bases.c is truely generic and included in every
  30. configuration.  All other files are linked at build time into the mpn
  31. build directory from one of the CPU specific sub-directories, or from
  32. the mpn/generic directory.
  33. There are four types of mpn source files.
  34.   .asm   Assembly code preprocessed with m4
  35.   .S   Assembly code preprocessed with cpp
  36.   .s   Assembly code not preprocessed at all
  37.   .c   C code
  38. There are two types of .asm files.
  39.   i) ``Normal'' files containing one function, though possibly with
  40.      more than one entry point.
  41.   ii) Multi-function files that generate one of a set of functions
  42.       according to build options.
  43. To add a new implementation of an existing function,
  44.   i) Put it in the appropriate CPU-specific mpn subdirectory, it'll be
  45.      detected and used.
  46.   ii) Any entrypoints tested by HAVE_NATIVE_func in other code must
  47.       have PROLOGUE(func) for configure to grep.  This is normal for
  48.       .asm or .S files, but for .c files a dummy comment like the
  49.       following will be needed.
  50.               /*
  51.               PROLOGUE(func)
  52.               */
  53. To add a new implementation using a multi-function file, in addition
  54. do the following,
  55.   i) Use a MULFUNC_PROLOGUE(func1 func2 ...) in the .asm, declaring
  56.      all the functions implemented, including carry-in variants.
  57.      If there's a separate PROLOGUE(func) for each possible function
  58.      (but this is usually not the case), then MULFUNC_PROLOGUE isn't
  59.      necessary.
  60. To add a new style of multi-function file, in addition do the
  61. following,
  62.   i) Add to the GMP_MULFUNC_CHOICES "case" statement in configure.in
  63.      which lists each multi-function filename and what function files
  64.      it can provide.
  65. To add a completely new mpn function file, do the following,
  66.   i) Ensure the filename is a valid C identifier, due to the
  67.      -DOPERATION_$* used to support multi-function files.  This means
  68.      "-" can't be used (but "_" can).
  69.   ii) Add it to configure.in under one of the following
  70.       a) `gmp_mpn_functions' if it exists for every target.  This
  71.          means there must be a C version in mpn/generic.  (Eg. mul_1)
  72.       b) `gmp_mpn_functions_optional' if it's a standard function, but
  73.          doesn't need to exist for every target.  Code wanting to use
  74.          this will test HAVE_NATIVE_func to see if it's available.
  75.          (Eg. copyi)
  76.       c) `extra_functions' for some targets, if it's a special
  77.          function that only ever needs to exist for certain targets.
  78.          Code wanting to use it can test either HAVE_NATIVE_func or
  79.          HAVE_HOST_CPU_foo, as desired.
  80.   iii) If HAVE_NATIVE_func is going to be used, then add a #undef to
  81.        the AH_VERBATIM([HAVE_NATIVE] block in configure.in.
  82.   iv) Add file.c to nodist_libdummy_la_SOURCES in mpn/Makefile.am (in
  83.       order to get an ansi2knr rule).  If the file is only in
  84.       assembler then this step is unnecessary, but do it anyway so as
  85.       not to forget if later a .c version is added.
  86.   v) If the function can be provided by a multi-function file, then
  87.      add to the "case" statement in configure.in which lists each
  88.      multi-function filename and what function files it can provide.
  89. ** Adding a test program
  90.   i) Tests to be run early in the testing can be added to the main
  91.      "tests" sub-directory.
  92.   ii) Tests for mpn, mpz, mpq and mpf can be added under the
  93.       corresponding tests subdirectory.
  94.   iii) Generic tests for late in the testing can be added to
  95.        "tests/misc".  printf and scanf tests currently live there too.
  96.   iv) Random number function tests can be added to "tests/rand".  That
  97.       directory has some development-time programs too.
  98.   v) C++ test programs can be added to "tests/cxx".  A line like the
  99.      following must be added for each, since by default automake looks
  100.      for a .c file.
  101.              t_foo_SOURCES = t-foo.cc
  102. In all cases the name of the program should be added to check_PROGRAMS
  103. in the Makefile.am.  TESTS is equal to check_PROGRAMS, so all those
  104. programs get run.
  105. "tests/devel" has a number of programs which are only for development
  106. purposes and are not for use in "make check".  These should be listed
  107. in EXTRA_PROGRAMS to get Makefile rules created, but they're never
  108. built or run unless an explicit "make someprog" is used.
  109. * Adding a new CPU
  110. In general it's policy to use proper names for each CPU type
  111. supported.  If two CPUs are quite similar and perhaps don't have any
  112. actual differences in GMP then they're still given separate names, for
  113. example alphaev67 and alphaev68.
  114. Canonical names:
  115.   i) Decide the canonical CPU names GMP will accept.
  116.   ii) Add these to the config.sub wrapper if configfsf.sub doesn't
  117.       already accept them.
  118.   iii) Document the names in gmp.texi.
  119. Aliases (optional):
  120.   i) Any aliases can be added to the config.sub wrapper, unless
  121.      configfsf.sub already does the right thing with them.
  122.   ii) Leave configure.in and everywhere else using only the canonical
  123.       names.  Aliases shouldn't appear anywhere except config.sub.
  124.   iii) Document in gmp.texi, if desired.  Usually this isn't a good
  125.        idea, better encourage users to know just the canonical
  126.        names.
  127. Configure:
  128.   i) Add patterns to configure.in for the new CPU names.  Include the
  129.      following (see configure.in for the variables to set up),
  130.      a) ABI choices (if any).
  131.      b) Compiler choices.
  132.      c) mpn path for CPU specific code.
  133.      d) Good default CFLAGS for each likely compiler.
  134.      d) Any special tests necessary on the compiler or assembler
  135.         capabilities.
  136.   ii) M4 macros to be shared by asm files in a CPU family are by
  137.       convention in a foo-defs.m4 like mpn/x86/x86-defs.m4.  They're
  138.       likely to use settings from config.m4 generated by configure.
  139. Fat binaries:
  140.   i) In configure.in, add CPU specific directory(s) to fat_path.
  141.   ii) In mpn/<cpu>/fat.c, identify the CPU at runtime and use suitable
  142.       CPUVEC_SETUP_subdir macros to select the function pointers for it.
  143.   iii) For the x86s, add to the "$tmp_prefix" setups in configure.in
  144.        which abbreviates subdirectory names to fit an 8.3 filesystem.
  145.        (No need to restrict to 8.3, just ensure uniqueness when
  146.        truncated.)
  147. * The configure system
  148. ** Installing tools
  149. The current versions of automake, autoconf and libtool in use can be
  150. checked in the ChangeLog.  Look for "Update to ...".  Patches may have
  151. been applied, look for "Regenerate ...".
  152. The GMP build system is in places somewhat dependent on the internals
  153. of the build tools.  Obviously that's avoided as much as possible, but
  154. where it can't it creates a problem when upgrading or attempting to
  155. use different tools versions.
  156. ** Updating gmp
  157. The following files need to be updated when going to a new version of
  158. the build tools.  Unfortunately the tools generally don't identify
  159. when an out-of-date version is present.
  160. aclocal.m4 is updated by running "aclocal".  (Only needed for a new
  161. automake or libtool.)
  162. INSTALL.autoconf can be copied from INSTALL in autoconf.
  163. ltmain.sh comes from libtool.  Remove it and run "libtoolize --copy",
  164. or just copy the file by hand.
  165. ansi2knr.c, ansi2knr.1, install-sh and doc/mdate-sh come from automake
  166. and can be updated by copying or by removing and running "automake
  167. --add-missing --copy".
  168. texinfo.tex can be updated from ftp.gnu.org.  Check it still works
  169. with "make gmp.dvi", "make gmp.ps" and "make gmp.pdf".
  170. configfsf.guess and configfsf.sub can be updated from ftp.gnu.org (or
  171. from the "config" cvs module at subversions.gnu.org).  The gmp
  172. config.guess and config.sub wrappers are supposed to make such an
  173. update fairly painless.
  174. depcomp from automake is not needed because configure.in specifies
  175. automake with "no-dependencies".
  176. ** How it works
  177. During development:
  178.     Input files                       Tool       Output files
  179.     ---------------------------------------------------------
  180.                                      aclocal
  181.     $prefix/share/aclocal*/*.m4 ----------------> aclocal.m4
  182.     configure.in                    autoconf
  183.     aclocal.m4   / -----------------------------> configure
  184.     */Makefile.am                   automake
  185.     configure.in  | ----------------------------> Makefile.in
  186.     aclocal.m4    /
  187.     configure.in                   autoheader
  188.     aclocal.m4   / -----------------------------> config.in
  189. At build time:
  190.     Input files          Tool       Output files
  191.     --------------------------------------------
  192.     */Makefile.in     configure    / */Makefile
  193.     config.in      | -------------> | config.h
  194.     gmp-h.in       |                | config.m4
  195.     mp-h.in        /                | gmp.h
  196.                                     | mp.h
  197.                                      fat.h  (fat binary build only)
  198. When configured with --enable-maintainer-mode the Makefiles include
  199. rules to re-run the necessary tools if the input files are changed.
  200. This can end up running a lot more things than are really necessary.
  201. If a build tree is in too much of a mess for those rules to work
  202. properly then a bootstrap can be done from the source directory with
  203. aclocal
  204. autoconf
  205. automake
  206. autoheader
  207. The autom4te.cache directory is created by autoconf to save some work
  208. in subsequent automake or autoheader runs.  It's recreated
  209. automatically if removed, it doesn't get distributed.
  210. ** C++ configuration
  211. It's intended that the contents of libgmp.la won't vary according to
  212. whether --enable-cxx is selected.  This means that if C++ shared
  213. libraries don't work properly then a shared+static with --disable-cxx
  214. can be done for the C parts, then a static-only with --enable-cxx to
  215. get libgmpxx.
  216. libgmpxx.la uses some internals from libgmp.la, in order to share code
  217. between C and C++.  It's intended that libgmpxx can only be expected
  218. to work with libgmp from the same version of GMP.  If some of the
  219. shared internals change their interface, then it's proposed to rename
  220. them, for instance __gmp_doprint2 or the like, so as to provoke link
  221. errors rather than mysterious failures from a mismatch.
  222. * Development setups
  223. ** General
  224. --disable-shared will make builds go much faster, though of course
  225. shared or shared+static should be tested too.
  226. --enable-mpbsd grabs various bits of mpz, which might need to be
  227. adjusted if things in those routines are changed.  Building mpbsd all
  228. the time doesn't cost much.
  229. --prefix to a dummy directory followed by "make install" will show
  230. what's installed.
  231. "make check" acts on the libgmp just built, and will ignore any other
  232. /usr/lib/libgmp, or at least it should do.  Libtool does various hairy
  233. things to ensure it hits the just-built library.
  234. ** Long long limb testing
  235. On systems where gcc supports long long, but a limb is normally just a
  236. long, the following can be used to force long long for testing
  237. purposes.  It will probably run quite slowly.
  238. ./configure --host=none ABI=longlong
  239. ** Function argument conversions
  240. When using gcc, configuring with something like
  241. ./configure CFLAGS="-g -Wall -Wconversion -Wno-sign-compare"
  242. can show where function parameters are being converted due to having
  243. function prototypes available, which won't happen in a K&R compiler.
  244. Doing this in combination with the long long limb setups above is
  245. good.
  246. Conversions between int and long aren't warned about by gcc when
  247. they're the same size, which is unfortunate because casts should be
  248. used in such cases, for the benefit of K&R compilers with int!=long
  249. and where the difference matters in function calls.
  250. ** K&R support
  251. Function definitions must be in the GNU stylized form to work.  See
  252. the ansi2knr.1 man page (included in the GMP sources).
  253. __GMP_PROTO is used for function prototypes, other ANSI / K&R
  254. differences are conditionalized in various places.
  255. Proper testing of the K&R support requires a compiler which gives an
  256. error for ANSI-isms.  Configuring with --host=none is a good idea, to
  257. test all the generic C code.
  258. When using an ANSI compiler, the ansi2knr setups can be partially
  259. tested with
  260. ./configure am_cv_prog_cc_stdc=no ac_cv_prog_cc_stdc=no
  261. This will test the use of $U and the like in the makefiles, but not
  262. much else.
  263. Forcing the cache variables can be used with a compiler like HP C
  264. which is K&R by default but to which configure normally adds ANSI mode
  265. flags.  This then should be a good full K&R test.
  266. * Other Notes
  267. ** Compatibility
  268. compat.c is the home of functions retained for binary compatibility,
  269.     but now done by other means (like a macro).
  270. struct __mpz_struct etc - this must be retained for C++ compatibility.
  271.     C++ applications defining functions taking mpz_t etc parameters
  272.     will get this in the mangled name because C++ "sees though" the
  273.     typedef mpz_t to the underlying struct.
  274.     Incidentally, this probably means for C++ that our mp.h is not
  275.     compatible with an original BSD mp.h, since we use struct
  276.     __mpz_struct for MINT in ours.  Maybe we could change to whatever
  277.     the original did, but it seems unlikely anyone would be using C++
  278.     with mp.h.
  279. __gmpn - note that glibc defines some __mpn symbols, old versions of
  280.     some mpn routines, which it uses for floating point printfs.
  281. Local variables:
  282. mode: outline
  283. fill-column: 70
  284. End:
  285. /* eof doc/configuration */