DOC HOME SITE MAP MAN PAGES GNU INFO SEARCH
 

(automake) Program and Library Variables

Info Catalog (automake) A Shared Library (automake) Programs (automake) LIBOBJS
 
 Program and Library Variables
 =============================
 
    Associated with each program are a collection of variables which can
 be used to modify how that program is built.  There is a similar list of
 such variables for each library.  The canonical name of the program (or
 library) is used as a base for naming these variables.
 
    In the list below, we use the name "maude" to refer to the program or
 library.  In your `Makefile.am' you would replace this with the
 canonical name of your program.  This list also refers to "maude" as a
 program, but in general the same rules apply for both static and dynamic
 libraries; the documentation below notes situations where programs and
 libraries differ.
 
 `maude_SOURCES'
      This variable, if it exists, lists all the source files which are
      compiled to build the program.  These files are added to the
      distribution by default.  When building the program, Automake will
      cause each source file to be compiled to a single `.o' file (or
      `.lo' when using libtool).  Normally these object files are named
      after the source file, but other factors can change this.  If a
      file in the `_SOURCES' variable has an unrecognized extension,
      Automake will do one of two things with it.  If a suffix rule
      exists for turning files with the unrecognized extension into `.o'
      files, then automake will treat this file as it will any other
      source file ( Support for Other Languages).  Otherwise, the
      file will be ignored as though it were a header file.
 
      The prefixes `dist_' and `nodist_' can be used to control whether
      files listed in a `_SOURCES' variable are distributed.  `dist_' is
      redundant, as sources are distributed by default, but it can be
      specified for clarity if desired.
 
      It is possible to have both `dist_' and `nodist_' variants of a
      given `_SOURCES' variable at once; this lets you easily distribute
      some files and not others, for instance:
 
           nodist_maude_SOURCES = nodist.c
           dist_maude_SOURCES = dist-me.c
 
      By default the output file (on Unix systems, the `.o' file) will be
      put into the current build directory.  However, if the option
      `subdir-objects' is in effect in the current directory then the
      `.o' file will be put into the subdirectory named after the source
      file.  For instance, with `subdir-objects' enabled,
      `sub/dir/file.c' will be compiled to `sub/dir/file.o'.  Some
      people prefer this mode of operation.  You can specify
      `subdir-objects' in `AUTOMAKE_OPTIONS' ( Options).
 
 `EXTRA_maude_SOURCES'
      Automake needs to know the list of files you intend to compile
      _statically_.  For one thing, this is the only way Automake has of
      knowing what sort of language support a given `Makefile.in'
      requires.  (1)  This means that, for example, you can't put a
      configure substitution like `@my_sources@' into a `_SOURCES'
      variable.  If you intend to conditionally compile source files and
      use `configure' to substitute the appropriate object names into,
      e.g., `_LDADD' (see below), then you should list the corresponding
      source files in the `EXTRA_' variable.
 
      This variable also supports `dist_' and `nodist_' prefixes, e.g.,
      `nodist_EXTRA_maude_SOURCES'.
 
 `maude_AR'
      A static library is created by default by invoking `$(AR) cru'
      followed by the name of the library and then the objects being put
      into the library.  You can override this by setting the `_AR'
      variable.  This is usually used with C++; some C++ compilers
      require a special invocation in order to instantiate all the
      templates which should go into a library.  For instance, the SGI
      C++ compiler likes this variable set like so:
           libmaude_a_AR = $(CXX) -ar -o
 
 `maude_LIBADD'
      Extra objects can be added to a library using the `_LIBADD'
      variable.  This should be used for objects determined by
      `configure'.
 
 `maude_LDADD'
      Extra objects can be added to a shared library or a program by
      listing them in the `_LDADD' variable.  This should be used for
      objects determined by `configure'.
 
      `_LDADD' and `_LIBADD' are inappropriate for passing
      program-specific linker flags (except for `-l', `-L', `-dlopen'
      and `-dlpreopen').  Use the `_LDFLAGS' variable for this purpose.
 
      For instance, if your `configure.in' uses `AC_PATH_XTRA', you
      could link your program against the X libraries like so:
 
           maude_LDADD = $(X_PRE_LIBS) $(X_LIBS) $(X_EXTRA_LIBS)
 
 `maude_LDFLAGS'
      This variable is used to pass extra flags to the link step of a
      program or a shared library.
 
 `maude_LINK'
      You can override the linker on a per-program basis.  By default the
      linker is chosen according to the languages used by the program.
      For instance, a program that includes C++ source code would use
      the C++ compiler to link.  The `_LINK' variable must hold the name
      of a command which can be passed all the `.o' file names as
      arguments.  Note that the name of the underlying program is _not_
      passed to `_LINK'; typically one uses `$@':
 
           maude_LINK = $(CCLD) -magic -o $@
 
 `maude_CCASFLAGS'
 `maude_CFLAGS'
 `maude_CPPFLAGS'
 `maude_CXXFLAGS'
 `maude_FFLAGS'
 `maude_GCJFLAGS'
 `maude_LFLAGS'
 `maude_OBJCFLAGS'
 `maude_RFLAGS'
 `maude_YFLAGS'
      Automake allows you to set compilation flags on a per-program (or
      per-library) basis.  A single source file can be included in
      several programs, and it will potentially be compiled with
      different flags for each program.  This works for any language
      directly supported by Automake.  The flags are `_CCASFLAGS',
      `_CFLAGS', `_CPPFLAGS', `_CXXFLAGS', `_FFLAGS', `_GCJFLAGS',
      `_LFLAGS', `_OBJCFLAGS', `_RFLAGS', and `_YFLAGS'.
 
      When using a per-program compilation flag, Automake will choose a
      different name for the intermediate object files.  Ordinarily a
      file like `sample.c' will be compiled to produce `sample.o'.
      However, if the program's `_CFLAGS' variable is set, then the
      object file will be named, for instance, `maude-sample.o'.
 
      In compilations with per-program flags, the ordinary `AM_' form of
      the flags variable is _not_ automatically included in the
      compilation (however, the user form of the variable _is_ included).
      So for instance, if you want the hypothetical `maude' compilations
      to also use the value of `AM_CFLAGS', you would need to write:
 
           maude_CFLAGS = ... your flags ... $(AM_CFLAGS)
 
 `maude_DEPENDENCIES'
      It is also occasionally useful to have a program depend on some
      other target which is not actually part of that program.  This can
      be done using the `_DEPENDENCIES' variable.  Each program depends
      on the contents of such a variable, but no further interpretation
      is done.
 
      If `_DEPENDENCIES' is not supplied, it is computed by Automake.
      The automatically-assigned value is the contents of `_LDADD' or
      `_LIBADD', with most configure substitutions, `-l', `-L',
      `-dlopen' and `-dlpreopen' options removed.  The configure
      substitutions that are left in are only `@LIBOBJS@' and
      `@ALLOCA@'; these are left because it is known that they will not
      cause an invalid value for `_DEPENDENCIES' to be generated.
 
 `maude_SHORTNAME'
      On some platforms the allowable file names are very short.  In
      order to support these systems and per-program compilation flags
      at the same time, Automake allows you to set a "short name" which
      will influence how intermediate object files are named.  For
      instance, if you set `maude_SHORTNAME' to `m', then in the above
      per-program compilation flag example the object file would be named
      `m-sample.o' rather than `maude-sample.o'.  This facility is
      rarely needed in practice, and we recommend avoiding it until you
      find it is required.
 
    ---------- Footnotes ----------
 
    (1) There are other, more obscure reasons reasons for this
 limitation as well.
 
Info Catalog (automake) A Shared Library (automake) Programs (automake) LIBOBJS
automatically generated byinfo2html