Lines Matching full:which

92 see the respective manuals for that.  Instead, it describes which files
93 the developer must write, which files are machine generated and how they
175 harder to write programs which could run on all variants.  While it was
204 Most programs are built using the make program, which requires the
209 The X Window system is built using the imake tool, which uses a database
210 of rules to eliminate the duplication.  However, building a tool which
215 which permits developers to write very simple Makefiles.  However, this
218 In 1994, David MacKenzie wrote the first version of automake, which
219 permitted writing a simple build description which was converted into a
220 Makefile which could be used by the standard make program.  In 1995, Tom
227 Matzigkeit began working on libtool, which provided a standardized
245 script in the source directory.  The directory in which you run
248 In order to use a object directory which is different from the source
249 directory, you must be using the GNU version of @samp{make}, which has
283 which are generally specific to particular tools.  You can usually use
294 The directory named by the @samp{--exec-prefix} option, which is
371 Besides the portability tests which are specific to your particular
378 This macro takes a single argument, which is the name of a file in your
396 This macro names the header file which will hold the preprocessor macro
446 (Programs which do not use automake use neither @samp{AC_EXEEXT} nor
454 However, if this @file{configure.in} file is for a library which is to
455 be compiled by a cross compiler which may not fully work, then you will
457 variant which does not call the macro @samp{AC_PROG_CC_WORKS}.  Examples
472 shared, or you want to link against libraries which were built using
486 tests.  This defines the macro @samp{_GNU_SOURCE} when compiling, which
493 This macro takes a list of file names which the configure process should
502 file, then you will need to write a @file{acinclude.m4} file which
509 The different macro prefixes indicate which tool defines the macro.
510 Macros which start with @samp{AC_} are part of autoconf.  Macros which
600 refer to particular directories, which may be set by the @samp{--bindir}
635 any macro which appears in a @samp{AC_DEFINE} macro.
650 available in the @file{config.h} file which your code will use.
692 script which will have been created by @samp{autoconf} with the
694 Makefiles which will include rules to automatically rebuild all the
709 which we will call @samp{poke}, will take a single file name argument,
784 @samp{autoscan}, which will create a @file{configure.scan} file which we
801 names which autoconf will use).
912 @samp{install} program which may be used, and which supports optional
981 should be installed in the binary directory, which we called
986 @samp{VERSION}, which must be mentioned for all packages which use
1020 By default, @samp{automake} will run in GNU mode, which means that it
1023 @file{ChangeLog}, all of which are files which should appear in a
1027 Running these tools will generate the following files, all of which are
1075 Here is a picture of the files which are written by the developer, the
1076 generated files which would be included with a complete source
1077 distribution, and the tools which create those files.
1101 in the file will normally be an @samp{AC_OUTPUT} macro listing which
1112 tools which have not been converted, in which the developer writes
1119 @samp{AC_CONFIG_HEADER}), this file is used to describe macros which are
1166 This is the configure script which will be run when building the
1172 This is the file which the configure script will turn into the
1185 macros which @samp{autoconf} will use when generating the file
1197 some of the macros in it to create @file{config.h}, which may then be
1204 This rather uninteresting file, which I omitted from the picture, is
1211 in a way which does not affect @file{config.in}.
1217 This section describes the files which are created at configure and
1218 build time.  These are the files which somebody who builds the package
1234 Here is a picture of the files which will be created at build time.
1235 @file{config.status} is both a created file and a shell script which is
1243 This is a description of the files which are created at build time.
1250 @file{config.status}, which is itself a shell script.  When you first
1258 This is the file which make will read to build the program.  The
1264 This file defines C preprocessor macros which C code can use to adjust
1282 This file, which I omitted from the picture, is similar to
1286 @file{config.status} to change in a way which does not affect
1317 The man page which goes with @file{ansi2knr.c}.
1319 A shell script which determines the configuration name for the system on
1320 which it is run.
1322 A shell script which canonicalizes a configuration name entered by a
1327 A shell script which installs a program.  This is used if the configure
1330 Used by libtool.  This is a shell script which configures libtool for
1331 the particular system on which it is used.
1333 Used by libtool.  This is the actual libtool script which is used, after
1344 A shell script which creates a directory, including all parent
1403 A somewhat freeform field which indicates the manufacturer of the
1408 The name of the operating system which is run on the system.  This will
1411 @samp{aix4.1.4.0} are seen.  For an embedded system, which has no
1421 configuration name for the system on which it is run.  It does by
1435 code differently based on something which can not be tested using a
1442 name, you should define a macro which describes the feature, rather than
1443 defining a macro which describes the particular system you are on.
1448 canonical configuration name (which will be the case if
1462 field, in order to match the version number which will be generated by
1478 compilation} tools.  A cross compilation tool is a tool which runs on
1479 one system and produces code which runs on another system.
1494 A compiler which produces programs which run on a different system is a
1498 In the normal case, a compiler produces code which runs on the same
1499 system as the one on which the compiler runs.  When it is necessary to
1505 nevertheless meaningful to speak of a cross debugger: a debugger which
1506 is used to debug code which runs on another system.  Everything that is
1516 involved: the system on which the tools will run, and the system for
1517 which the tools generate code.
1519 The system on which the tools will run is called the @dfn{host} system.
1521 The system for which the tools generate code is called the @dfn{target}
1524 For example, suppose you have a compiler which runs on a GNU/Linux
1534 @samp{binutils} which actually produce running code.  For example, it
1547 In almost all cases the host system is the system on which you run the
1548 @samp{configure} script, and on which you build the tools (for the case
1591 name of the system for which you wish to generate code.
1594 For example, to build tools which generate code for a MIPS ELF embedded
1644 @samp{target_alias} should be used.  This includes anything which may
1702 which run on the host, which is called the host compiler.  This includes
1705 or gcc which run on the host.
1717 There is a complication here.  The configure process needs to know which
1744 there even is one) uses the same ABI as the g++ compiler which will be
1784 some target library, which naturally means that they will not exist when
1788 any test which requires doing a link.  This unfortunately includes many
1790 which do a compile but not a link, such as @samp{AC_CHECK_HEADERS}, may
1795 thus know which functions will be available.
1804 in directories which are siblings to the host tools, and are sometimes
1818 A library which can be built both standalone and as a target library may
1821 be installed in @samp{$(libdir)}.  When built as a target library which
1837 For every subdirectory @var{dir} which holds a host library or program,
1846 For every subdirectory @var{dir} which holds a target library, the
1856 There are several other targets which may be of interest for each
1866 it is the only directory which is built both using the host compiler and
1898 program which will run on a system which is different from the system on
1899 which the tools are built.  In other words, it is possible to build
1919 While running on a GNU/Linux, you can build a program which will run on
1942 involved: the system on which the tools are being built, and the system
1943 on which the tools will run.
1945 The system on which the tools are being built is called the @dfn{build}
1948 The system on which the tools will run is called the host system.
1956 case, the system for which the resulting cross compiler generates code
2013 which it is run, it really identifies the build system.  Since the host
2035 cross tools which you want to use to build the program.  This is done by
2040 @samp{AR}, and @samp{RANLIB} to the cross tools which you want to use to
2046 You would set these environment variables to the build cross tools which
2079 @samp{--target} option that is the same as the system which we are now
2082 Type}).  Since that is the system which we are now calling the host,
2103 compiler will be a program which runs on the host system, and therefore
2114 cross target tools is imposed by the Cygnus tree, which expects to be
2118 system, which means that it must use a build cross target toolchain.
2163 However, it is not hard to write configure and make tests which will
2177 shell variable @samp{cross_compiling}.  In a Canadian Cross, which means
2187 and @samp{build_os}, which correspond to the similar @samp{target} and
2193 Macros like @samp{AC_CHECK_FUNCS} which use the compiler will test the
2195 compiler, which is actually a build cross host compiler.  If the
2208 will be compiled for the host system, which means that it will not run
2226 There are a few other autoconf macros which will not work correctly with
2239 to use a subsidiary program to generate code or data which you will then
2255 native compiler).  Subsidiary programs are normally simple filters which
2261 The gcc @file{Makefile.in} shows a complex situation in which certain
2293 script named @samp{configure} which may be found at the top of the
2336 directory which uses it at present is @file{newlib}.
2347 read in after the first line in @file{Makefile.in} which starts with
2353 values for @samp{make} variables which are then used during compilation.
2367 will create a file named @file{config.status} which, when run, will
2382 which case Cygnus configure will invoke itself recursively.  If the
2418 means that the floating point registers are not available, which means
2477 source directory (which is not recommended), it will build a symlink
2484 variables which will do the right thing in the subdirectories.
2496 (which is not recommended).
2527 which are used when building multilibs.
2548 In general, any operation, other than clean, which should be performed
2563 @item Which do I run first, @samp{autoconf} or @samp{automake}?
2571 This means that you have macros in your @file{configure.in} which are
2580 This means that you have macros in your @file{configure.in} which should
2618 It is the build system which was developed at Cygnus, using the Cygnus
2625 themselves which need to be fixed, and each time that happens everybody