[XaraXtreme-dev] SVNFilter & xarlib build instructions

[Alex Bligh <alex@xxxxxxxxxxx>]

These now will build in-tree.

Pass configure
  --enable-xarlib    - to enable building of xarlib (as well
                       as the main app).
  --enable-svnfilter - to enable building of svnfilter with a
                       local xarlib (need not be installed)

The way they do it is slightly different, and I described
them below.

SVGFilter
=========

SVGFilter is designed to be a completely separate
tree (it has its own configure etc.). It should normally
be compiled and run as such. However, for automated build
(e.g. the build server) and package making, you may want
to build these on an environment where xarlib (at
least the most recent version) is not installed. The
new option allows you to do that. I repeat that this is
not designed as a practical option for ftiler
developers, and is NOT intended to be used as the main
development mechanism (IT WILL SLOW YOU DOWN).

What you can quite happily do (however) is (without
enabling the option below), go into the filters/SVFGfilter
directory, and type ./configure ; make etc. as normal.
I have tested "make install" for xarlib, and it seems
to do the sensible thing.

xarlib
======

xarlib uses the same source code as the main application,
just far fewer files, and different compile flags. This should
now be built in tree. You don't have to compile the
whole app to build xarlib (see below).

If you want to make just xarlib, you should be able to
do
   make -C xarlib
and
   make -C xarlib install

Of course if you are building "out of tree" (object files
not next to source files) you will need
   (cd debug ; make -C xarlib)
etc.

When building xarlib, I currently PREVENT any shared libraries
from being built. This is because we do not (yet) have
a stable XarLib API/ABI. So anyone who tries to link to
shared libraries would be in for a rude awakening if
someone updated them.

xarlib itself, however, links to other libraries (e.g.
WX). The way xarlib does this is dependent on the
--static-exec-enable flag (i.e. the same as the rest
of Camelot). So if you build XaraLX to static link to
wx, xarlib will static link to wx - etc. This has the
result that if you build xarlib to dynamic link,
your otherwise static-linked binary which is in
turn linked to xarlib may have rather more dynamic
linkages than you thought.

Functionality of xarlib and SVGFilter
=====================================

I have NOT tested this. In fact we know it currently
does not work (or at least expandxar doesn't work).
This may well be because I picked up an old expandxar
from the web site rather than the SVN version.

Gerry is looking at why this might be

Alex (automonkey for the day)