FAQ -- CVS versions of required libraries (was RE: overwrite mode)


Subject: FAQ -- CVS versions of required libraries (was RE: overwrite mode)
From: Paul Rohr (paul@abisource.com)
Date: Sat Jan 29 2000 - 10:55:02 CST


At 01:54 PM 1/29/00 +0300, Alexey Sinutin wrote:
>BTW I cannot to compile Abi on my Win32 workstation. I downloaded libiconv
>from libiconv's home page,

Bingo. That's your problem. Check out the libiconv CVS module from our
website, which includes the file you're missing.

Note that with a number of "outside" libraries -- currently expat and wv on
all platforms, plus libpng, zlib, and libiconv on others -- we mirror a
local copy of the version we're using in CVS. In all cases, there should be
only two differences between the "official" copy and ours:

  1. Our version is known to build and link properly with AbiWord, but it
      may be a bit out of date w.r.t. the latest official version.

  2. It contains one or more extra files (usually called Makefile.abi) for
      use with our XP diving make system.

The net effect is that with CVS versions of all of the peer trees in place,
we can fire off a single build from the abi tree which will also dive "down
and over" into these peer directories and copy their outputs into a known
clean location so we can link them into AbiWord. For more details on how
this works, see:

  abi/src/config/require/*

Shaw and I tend to argue every other month about whether there's a better
way to do this, but so far nobody's implemented anything.

It would definitely be convenient to not have to maintain these parallel
makefiles, so that we could just drop the latest official version of a
required library in place and rebuild.

So, if anyone has a better **cross-platform** strategy for using the
unmodified stock makefiles shipped with each package, please let us know. I
was tempted to make this a POW, but given all the platforms we support, it's
definitely a non-trivial problem, and I plan on being *very* picky about the
robustness and reliability of any proposed patches.

After all, our current solution may not be pretty in everyone's eyes, but it
Just Works. :-)

Thanks,
Paul



This archive was generated by hypermail 2b25 : Sat Jan 29 2000 - 10:49:42 CST