Well, Stefan would know better, but as I understand it, the
AC_COIN_HAS_PACKAGE command actually first creates *_LIB and *_CFLAGS
variables for the package named in the first argument and then also
adds those to the *_LIB and *_CFLAGS variables of the library/binary
that depends on the package being defined. So the COINDEPEND_CFLAGS
are just the combination of the flags of the individual packages that
make up CoinDepend. These then get added to XXXLIB_CFLAGS along with
any other dependent project identified in later AC_COIN_HAS_PACKAGE to
form the full set of flags for XXXLIB. Admittedly, this is a bit
confusing and I'm not sure I got it entirely right. Stefan?



This has nothing to do with how you code as a developer. We are
talking about users, not you, when we talk about what should be in the
Makefile for the examples. To a user, all they have to know is that
they want to link to OS. A user should not have to know that, for
instance, you built without support for Bonmin and Couenne this time
because they aren't available and so they don't have to put those on
the link line. How would they know that? The .pc file automatically
contains whatever dependencies were present at the time of the
building of the library, no matter what those were. As far as
development goes, nothing changes in the above.

> 2.  OS depends, for example, on Cgl. But OS also uses SYMPHONY. In SYMPHONY
> you have
>
> Requires: cgl osi-vol osi-dylp osi-clp coinutils = trunk osi
>
> so should I skip Cgl?

If it is possible for OS to use Cgl *directly*, not *indirectly*
because some other project linked to by OS needs it, then it should be
listed. But I don't really see how you could use Cgl directly without
having some project like Cbc, SYMPHONY, Bonmin, Couenne, etc. present,
in which case Cgl would be among the dependencies of *that* project.
Is there a use case where you would want to link to Cgl without one of
the others present?

In any case, this is not something you have to decide since these
dependencies are generated automatically based on what projects you
check for in configure.ac. The checking there works the same way---you
only check for the things that you directly depend on, not the
secondary dependencies. the m4 macros use pkg-config in the same way
as I've been describing to generate the secondary dependencies. So
just don't worry about what goes in the .pc files under
dependencies---it's checks in configure.ac that you have to worry
about. Just eliminate any that you don't need (such as for Cgl?) and
they will not appear in the .pc file either.

> Maybe not if the user has not installed SYMPHONY.
>  Also, I see you have osi-clp, but NOT clp. I guess based on what you said
> about the recursive nature of things this is not necessary since osi-clp has
>
> Requires: clp osi

Yes, SYMPHONY can't use Clp except through Osi, so there is no reason
to check for Clp directly. If we had a native interface to Clp that
could be used if Osi was missing, then Clp could be checked for as a
dependency. 


From Lou:

> What happened to $(COINUTILSSRCDIR)????

	Answer on two levels. First, for the file you were looking at
(CoinUtils/test/Makefile.am), it makes sense to give a relative location
for the headers. If you're building in the test directory, the headers
are in ../src. If you're doing a VPATH build, you need to know where the
source directory is, then a relative path, hence $(srcdir)/../src. The
rule to remember is that srcdir is the source for the directory you're
building. When you're building the test directory, srcdir resolves to
the source for test.

	More generally, what happened to COINUTILSSRCDIR? A short but somewhat
misleading answer would be `It's been replaced by COINUTILS_CFLAGS'. But
a longer answer may give you a better perspective.

	It's been replaced by pkg-config, and a whole bunch of buildtools
macros that query pkg-config and deal with the situation when pkg-config
isn't available (I'll let Stefan speak to that). If you want to know the
header directories for CoinUtils, you ask

  pkg-config --cflags coinutils

and pkg-config consults coinutils.pc to give the answer (correct for my
particular configuration)

-I/devel/Coin/Split-FedGCC64/include/coin
-I/devel/Coin/Split-FedGCC64/include/coin/ThirdParty

These are the places to look for the installed headers for CoinUtils and
Glpk in my local build structure. Notice that pkg-config is helping me
here, keeping track of the fact that my CoinUtils build brings in glpk.
To get the libs needed to link against libCoinUtils,

  pkg-config --libs coinutils

gives

 -L/devel/Coin/Split-FedGCC64/lib/coin  
 -L/devel/Coin/Split-FedGCC64/lib/coin/ThirdParty -lCoinUtils -lbz2 
 -llapack -lblas -lm -lcoinglpk -ldl -lgmp -lz

So you can see why this simplifies things in the makefiles. When you're
building against uninstalled packages pkg-config needs to find
coinutils-uninstalled.pc. Again, the buildtools macros take care of
this, manipulating PKG_CONFIG_PATH so that pkg-config can find the
right .pc file.

You can ask for information about more than one package, e.g.,

  pkg-config --cflags coinutils osi cgl

and you'll get the combined information for all, duplicates removed:

  -I/devel/Coin/Split-FedGCC64/include/coin 
  -I/devel/Coin/Split-FedGCC64/include/coin/ThirdParty
  
If you're saying `but that's exactly the same as the previous answer',
you're exactly right. All the installed header files are in one place.
You don't get the same information repeated three times (for CoinUtils,
Osi, and Cgl). So when configure.ac uses

AC_COIN_HAS_PACKAGE(CoinDepend, [cgl osi coinutils = trunk], [CbcLib
CbcGeneric])

what will happen is that buildtools creates a variable,
COINDEPEND_CFLAGS, and this is set to the output of

  pkg-config --cflags cgl osi coinutils

(with some fussing to make sure it's the trunk of coinutils).
COINDEPEND_CFLAGS will be added to command lines when building CbcLib
and CbcGeneric.

	Hope this helps. There's nothing quite so frustrating as finding
yourself afloat in an unfamiliar sea.


%%%%%%%%%%%

export  PKG_CONFIG_PATH=/Users/kmartin/coin/os-tmp/vpath-debug/lib/pkgconfig 

%%%%%%

Here is something from Ted explaining how the Build System determines if something is a dependency


Well, here's the answer. The check in configure.ac looks like this:

AC_COIN_HAS_PACKAGE(ASL,   [coinasl])   <====== missing the third argument
AC_COIN_HAS_PACKAGE(HSL,   [coinhsl],   [IpoptLib])
AC_COIN_HAS_PACKAGE(Mumps, [coinmumps], [IpoptLib])

So ASL is not going to be listed as a dependency for the Ipopt
*library* and I guess that's because it isn't a dependency of the
*library*, just of the *binary*. Apparently, the AMPL interpreter is
not part of the library (unless this is a mistake). So you can link to
the Ipopt library without liniking to ASL. However, in the case of
ASL, that really is a direct dependency of OS, right? You can directly
read AMPL files, independent of any solver being able to solve
whatever you read in, right?


%%%%%%%%

Another hint from Lou:

	As Stefan says, += doesn't work in all shells. I'm probably telling you
something you know, but the standard idiom looks like this:

OSLIB_LIBS="$LIBS $OSLIB_LIBS"

to prepend. Reverse the order to append. I'm a serial offender on this;
I regularly forget that I need to add to a variable without trashing the
existing value.

						Lou
%%%%%%%%%%%%%%%%%

INFO on Externals

        You'll want to migrate towards Dependencies and the use of the
set_externals script to set svn:externals.  Documentation has definitely fallen
behind.  I guess what you're seeing here is bits of the new order --- the
independent (split) configuration stuff that Stefan's been implementing ---
starting to leak out.  I used the revised scripts described below to generate
the releases you were questioning.

        You can certainly keep on using the Externals file and
BuildTools/stable/0.6 for a while yet.  BuildTools/trunk should work on the
classic configuration with externals, so you should be able to use it on OS in
the classic packaging.  BuildTools/trunk is essential if you're going to
experiment with the split configuration (i.e., each project checked out
independently, without externals).

        There are major changes in the [prepare,commit]_new_[stable,release]
scripts in BuildTools/trunk.  (In fact, *_new_stable do not exist anywhere
except BuildTools/trunk.)  Also for run_autotools.  They are much more flexible
in terms of where they live and how they are run.  In the split configuration,
there's no guarantee that BuildTools will be present in the classic external
position.  The revised *_new_* scripts behave like normal command scripts.  You
can, for instance, copy them into some directory that's already in your command
search path and execute them from there.  Run_autotools is a bit more limited
due to its need for a number of autotools scripts that we distribute in
BuildTools. The revised scripts have long usage messages; they will help you.

        Prepare_new_stable will look to see whether you've supplied Externals or
Dependencies in your trunk.  If you've created Dependencies, it will use it.  If
all you have is Externals, it will generate Dependencies from Externals and add
it to the stable candidate.

        I'm not sure how much will be useful to you, but I've attached some
scripts below that I use to maintain a split configuration (trunks).  Create a
directory (e.g., Split) where you want the checkout to live.  Start with
getSplit, which will do checkout, update, or status.  When it finishes, you'll
have separate subdirectories for BuildTools, CoinUtils, Osi, etc.  If you want
to run the autotools, just type BuildTools/run_autotools in the Split directory.

        ConfigSplit will run configure, make, and make install (install is a
necessary step in a split configuration).  The first 2/3 of the script are of
marginal utility unless you adopt my stylised naming convention for build
directories. But the final third shows how to run make and make install.

	(Stylised naming convention: Suppose you checked out the split 
configuration in <path>/Split. The script expects the build directory to be
	named <path>/Split-<OS><compiler><bits><opt>
For example, Split-FedGCC64Opt is Fedora, GCC, 64-bit, optimised. Check the 
script to see what it recognises and adapt accordingly.)

	getThirdParty will haul down third-party software into the appropriate
ThirdParty subdirectories.

	testSplit will run `make test'
	
This is probably way more than you wanted to know on Saturday morning   :-)   But 
I'm on a flex week, today's a normal workday for me.
	
							Lou
%%% 


Stefan on LIBS

XXXLIB_LIBS is what you should use in your Makefile.am, XXXLIB_PCLIBS is
what you should use in the .pc.in file to setup the Libs entry.
The thing is that XXXLIB_LIBS hold all flags needed to link against
XXXLIB, but for the .pc file you want to distinguish between
dependencies that have a .pc file and those where you just know the
linking flags. So these two informations are stored in XXXLIB_PCREQUIRED
and XXXLIB_PCLIBS.


%%%%%%%%%%%%

Ralphs on naming convention

First of all, if it's working, then the names are correct  :) . Don't
overthink it  :) . The names are whatever *you* choose them to be for
your individual project. Whatever name you give to the corresponding
package in *your* configure.ac is how those variables get named. Since
you have the line

AC_COIN_CHECK_PACKAGE(Clp, [osi-clp]. [OSLib])

in your configure.ac, the variable for Clp libraries will be CLP_LIBS.
If you change the first argument of AC_COIN_CHECK_PACKAGE to "ClpLib,"
then you would use CLPLIB_LIBS. It doesn't matter what any other
project does. You choose your names within your project, though it
would probably be nice if we did it all similarly to avoid too much
confusion. At the moments, I believe we are mostly similar, but the
reason project add "LIB" onto the names internally is to distinguish
between dependencies for the library versus the executable. Since you
don't have to make that distinction (you are only using the library),
you don't need the redundant "LIB" added to the name.

Cheers,
