[vsipl++] PATCH: Allow multiple configurations of the same library to be installed on top of each other.

[Jules Bergmann]

Stefan,

I'm sorry, I didn't do a very good job of explaining the problem that I 
would like to solve.

Let's say we install a Sourcery VSIPL++ binary package on a machine 
(like the GTRI cluster).  What I would like is to allow people to use 
Makefiles like this:

----------------------------------------------------------------
PKG      = vsipl++
CXX      = $(shell pkg-config --variable=cxx      $PKG)
CXXFLAGS = $(shell pkg-config --cflags            $PKG) \
            $(shell pkg-config --variable=cxxflags $PKG)
LIBS     = $(shell pkg-config --libs              $PKG)

all: example1

example1.o: example1.cpp

%: %.o
         @ $(CXX) $(CXXFLAGS) -o $@ $< $(LIBS) || rm -f $@

%.o: %.cpp
         @ $(CXX) -c $(CXXFLAGS) -o $@ $< || rm -f $@
----------------------------------------------------------------

When developing, they would set PKG to "vsipl++-debug", which would 
result in CXXFLAGS that include debugging and warnings, don't include 
optimization, etc (i.e. "-g -W -Wall").  When building a release version 
of an application, people would set PKG to "vsipl++" or perhaps 
"vsipl++-release", which would ratchet up the optimization flags (i.e. 
something ugly like "-g -O2 -funswitch-loops -fgcse-after-reload --param 
max-inline-insns-single=2000 --param large-function-insns=6000 --param 
large-function-growth=800 --param inline-unit-growth=300").  Also, on a 
machine that could be used in 32-bit or 64-bit mode, we could imagine 
having PKGs for "vsipl++-release-64" etc.

pkg-config doesn't include compilation options in the --cflags, but by 
using variables, we can advertise to the user our recommended compiler 
(which is good since the default c++ compiler in their path may not be 
ABI compatible with the one that built VSIPL++) and our recommended 
flags (also useful, since getting good performance will require 
aggressive inlining).

We could do this by having multiple .pc files that exist in the same 
directory.  After installing the binary package, there would be a 
"vsipl++.pc", a "vsipl++-debug.pc", a "vsipl++-release.pc", etc.  Users 
would select between .pc packages by the package name given to 
pkg-config, not the directory the .pc files are in.

It matters less where the libraries are installed (i.e. either putting 
them in separate directories, such as the patch, or giving them 
differing suffixes "libvsip-release.a", would be fine.)


To make it possible to build a binary package this way, if we had an 
option to specify a .pc/library suffix to configure, then we could do 
something like this:

configure CXXFLAGS="-g" --suffix="-debug"
make
make install

configure CXXFLAGS="-go-fast" --suffix="-release"
make
make install

The second 'make install' would write over the first, with the 
exceptions of the .pc files and libraries, which would have different 
suffixes.  Later in the release process, we could insert a symbolic link 
from vsipl++.pc to vsipl++-release.pc .

How does this sound?

				-- Jules



Stefan Seefeld wrote:
> The attached patch moves the generation of the vsipl++.pc config file
> to the 'install' target, and thus allows certain values to vary between
> configuration and installation time.
> 
> With that I'm able to run the following sequence:
> 
> ../vpp/configure --prefix=/usr/local
> make install libdir=/usr/local/lib/vsip-debug
> make clean
> make install libdir=/usr/local/lib/vsip-optimize
> 
> and will get two versions of libvsip.a (and vsipl++.pc), but only
> one set of header files.