Changes between Version 3 and Version 4 of pm-switch


Ignore:
Timestamp:
Oct 27, 2010 1:59:17 AM (9 years ago)
Author:
stefan
Comment:

fix a few typos

Legend:

Unmodified
Added
Removed
Modified
  • pm-switch

    v3 v4  
    44
    55 1. Support for the {{{pkg-config}}} command to build lists of dependencies and command line options. Configuration files associated with pkg-config are used when the {{{pkg-config}}} command is present.
    6  1. All dependent projects are treated more or less as "third-party," so that it is now easy to link against installed version of COIN projects (using pkg-config if it is available). This also means that What were truly "third-party" projects are now treated more or less the same as COIN projects. We provide build, pkg-config, and install support for these projects if source is available and otherwise provide a mechanism for linking to installed libraries, as before.
     6 1. All dependent projects are treated more or less as "third-party", so that it is now easy to link against installed version of COIN-OR projects (using pkg-config if it is available). This also means that what were truly "third-party" projects are now treated more or less the same as COIN-OR projects. We provide build, pkg-config, and install support for these projects if source is available and otherwise provide a mechanism for linking to installed libraries, as before.
    77
    88== What Needs to be Edited ==
     
    1616 * {{{Root/Xxx/test/Makefile.am}}}
    1717 * {{{Root/Externals}}}
    18 and the following files need to be created:
     18the following files need to be created:
    1919 * {{{Root/Xxx/xxx.pc.in}}}
    2020 * {{{Root/Xxx/xxx-uninstalled.pc.in}}}
    2121 * {{{Root/Dependencies}}}
     22and the following files need to be deleted:
     23 * {{{Root/Xxx/xxx_addlibs.txt.in}}}
    2224There may also be changes needed in any examples that use installed versions of the COIN libraries, but these are a little less standardized, so it's difficult to say exactly what files would be affected.
    2325
     
    5052}}}
    5153
    52 Another change with the new setup is that it is now highly recommended to use release versions in your externals. To make this easy, there is a script called {{{set_externals}}} that is part of the build tools that will automatically set your externals. To use it, you maintain a "dependencies" file (usually called {{{Root/Dependencies}}}) as opposed to an "externals" file. The dependencies files will usually contain the stable versions on which a project depends in the same format as the current {{{Externals}}} file. When you run the command {{{set_externals Dependencies}}}, the dependencies files will be parsed and externals set to latest release versions automatically. Note that if your dependencies files contains trunk or specific release versions, these will be used instead, overriding the mechanism for using the latest release version. For example, here is the current Dependencies file for the trunk of Blis, which depends on the trunks of Alps and BiCePS.
     54Another change with the new setup is that it is now highly recommended to use release versions in your externals (once they are there). To make this easy, there is a script called {{{set_externals}}} that is part of the build tools that will automatically set your externals. To use it, you maintain a "dependencies" file (usually called {{{Root/Dependencies}}}) as opposed to an "externals" file. The dependencies files will usually contain the stable versions on which a project depends in the same format as the current {{{Externals}}} file. When you run the command {{{set_externals Dependencies}}}, the dependencies files will be parsed and externals set to latest release versions automatically. Note that if your dependencies files contains trunk or specific release versions, these will be used instead, overriding the mechanism for using the latest release version. For example, here is the current Dependencies file for the trunk of Blis, which depends on the trunks of Alps and BiCePS.
    5355
    5456{{{
     
    7072
    7173 1. Calls to {{{AC_COIN_MAIN_SUBDIRS()}}} should generally be changed to {{{AC_COIN_MAIN_PACKAGEDIR()}}}. For example, {{{AC_COIN_MAIN_SUBDIRS(CoinUtils)}}} => {{{AC_COIN_MAIN_PACKAGEDIR(CoinUtils)}}}
    72  1. Calls to {{{AC_COIN_THIRDPARTY_SUBDIRS()}}} should '''also''' be changed to {{{AC_COIN_MAIN_PACKAGEDIR()}}} (these packages are treated more or less the same way as COIN packages now). One difference between COIN projects and third part projects is that the source is that the source is typically checked out into a subdirectory {{{ThirdParty}} to make the separation clear. There is also a mechanism for checking to make sure that the project source is actually present (since this has to be downloaded separately by the user using the {{{getYyy}}} script. These capabilities are implemented using the optional second, third, and fourth arguments of {{{AC_COIN_MAIN_PACKAGEDIR()}}}, similar to the arguments of {{{AC_COIN_THIRDPARTY_SUBDIRS()}}} previously. The second argument denotes the subdirectory in which the project is to be found, the third argument is a file to check for to make sure that the source is present, and the fourth argument is the name of the pkg-config package associated with the installed library. So for BLAS, the call would be {{{AC_COIN_MAIN_PACKAGEDIR(Blas,ThirdParty,[daxpy.f],coinblas)}}}.
     74 1. Calls to {{{AC_COIN_THIRDPARTY_SUBDIRS()}}} should '''also''' be changed to {{{AC_COIN_MAIN_PACKAGEDIR()}}} (these packages are treated more or less the same way as COIN-OR packages now). One difference between COIN projects and third part projects is that the source is typically checked out into a subdirectory {{{ThirdParty}}} to make the separation clear. There is also a mechanism for checking to make sure that the project source is actually present (since this has to be downloaded separately by the user using the {{{get.Yyy}}} script. These capabilities are implemented using the optional second, third, and fourth arguments of {{{AC_COIN_MAIN_PACKAGEDIR()}}}, similar to the arguments of {{{AC_COIN_THIRDPARTY_SUBDIRS()}}} previously. The second argument denotes the subdirectory in which the project is to be found, the third argument is a file to check for to make sure that the source is present, and the fourth argument is the name of the pkg-config package associated with the installed library. So for BLAS, the call would be {{{AC_COIN_MAIN_PACKAGEDIR(Blas,ThirdParty,[daxpy.f],coinblas)}}}.
    7375 1. Note also that most calls to {{{AC_COIN_HAS_USER_LIBRARY()}}} for libraries like CPLEX are not needed in the {{{configure.ac}}} files in the root directory of higher-level projects, as these checks are made in the configure script of {{{Osi}}} and the list of libraries needed on the link line is automatically constructed and passed on to the higher-level project.
    7476
     
    7779In the {{{Root/Makefile.am}}} file, the changes are as follows:
    7880
    79  1. The {{{SUBDIRS}}} variables dos not need to set to an explicit list of dependencies, the available subdirectories are determined automatically according to which projects are present in source form. So the command {{{SUBDIRS = $(subdirs)}}} replaces any command setting the value of {{{SUBDIRS}}} that was previously present.
     81 1. The {{{SUBDIRS}}} variables does not need to be set to an explicit list of dependencies, the available subdirectories are determined automatically according to which projects are present in source form. So the command {{{SUBDIRS = $(subdirs)}}} replaces any command setting the value of {{{SUBDIRS}}} that was previously present.
    8082 1. The command {{{DISTCLEANFILES = coin_subdirs.txt}}} should be set to clean up the file in which the list of subdirectories was written. Previously, this variable was set to the empty string.
    8183
     
    8486 1. The function {{{AC_COIN_PROJECTDIR_INIT}}} now takes as an argument the name of the project, so the call would now be {{{AC_COIN_PROJECTDIR_INIT(Xxx)}}}.
    8587 1. Calls to {{{AC_COIN_HAS_PROJECT()}}} should be replaced with calls to {{{AC_COIN_HAS_PACKAGE()}}}. There are also three arguments now.
    86    * The first argument is the name of the "package", which can consist of multiple COIN projects. For example, one can defined a "package" consisting of both CoinUtils and Clp, called {{{CoinDepend}}} and make the configuration bail out when any component of the package is not present. This mechanism is meant for cases in which a project is not useful by itself, but only in combination with others.
     88   * The first argument is the name of the "package", which can consist of multiple COIN-OR projects. For example, one can defined a "package" consisting of both CoinUtils and Clp, called {{{CoinDepend}}} and make the configuration bail out when any component of the package is not present. This mechanism is meant for cases in which a project is not useful by itself, but only in combination with others.
    8789   * The second argument are the names the pkg-config files associated with the projects that make up the package, with the optional ability to specify specific required versions (see example below).
    88    * The third argument can be used to specify a particular library or binary to which the particular dependency applies. This is for cases where the project exports both a library and a binary executable and these have different dependencies. In this case, different command lines are built up for each of them separately. 
     90   * The third argument can be used to specify a particular library or binary to which the particular dependency applies. This is for cases where the project exports both a library and a binary executable and these have different dependencies. In this case, different command lines are built up for each of them separately.
    8991   * An example of how this comes together is the call {{{AC_COIN_HAS_PACKAGE(CoinDepend, [coinutils = trunk osi = trunk alps = trunk], [DipLib])}}}, which defines a package called {{{CoinDepend}}} that consists of the trunk versions of !CoinUtils, Osi, and Alps. The dependency applies to the Dip library. We'll see below how this specification comes to play in the Makefiles.
    9092 1. Calls to the function {{{AC_COIN_HAS_USER_LIBRARY()}}} can generally be replaced with calls to {{{AC_COIN_HAS_PACKAGE()}}} if they apply to solvers to be used through Osi. This is because the {{{OsiYyy}}} packages now have pkg-config support. So the call to check for the presence of CPLEX, for example, is now {{{AC_COIN_HAS_PACKAGE(Cpx,  [osi-cplex],  [DipLib])}}}.
     
    179181{{{
    180182AM_CPPFLAGS = $(COINDEPEND_CFLAGS)
    181 LDADD = $(COINDEPEND_CFLAGS)
     183LDADD = $(COINDEPEND_LIBS)
    182184}}}
    183185Note that the names of the variables correspond exactly to the names given to the libraries and binaries in the third argument {{{AC_COIN_HAS_PACKAGE()}}}, as described in the section on the {{{Root/Xxx/configure.ac}}} file above. Hence, the command {{{AC_COIN_HAS_PACKAGE(CoinDepend, [coinutils = trunk osi = trunk alps = trunk], [XxxLib])}}} will result in the libraries and flags for each of those dependencies being put into variables called {{{XXXLIB_LIBS}}} and {{{XXXLIB_CFLAGS}}} respectively. One curcial difference between these two variables, though, is that the {{{LIBS}}} variable includes secondary and tertiary dependencies, whereas the {{{CFLAGS}}} variable does not. So there's a little more work involved in building up the flags than the libraries. We will try to change this.
     
    191193== {{{Root/Xxx/examples}}} ==
    192194
    193 Again, the main difference here is that one has to build from the new set of variables defined above in linking to the installed libraries. Alternatively, if you would like to check for or assume the presence of pkg-config on the system the examples will be buitl on, the most ideal thing would be to build your example Makefiles to show to use pkg-config, as this is the exact use case we are attempting to support.
     195Again, the main difference here is that one has to build from the new set of variables defined above in linking to the installed libraries. Alternatively, if you would like to check for or assume the presence of pkg-config on the system the examples will be built on, the most ideal thing would be to build your example Makefiles to show to use pkg-config, as this is the exact use case we are attempting to support.