[Date Prev][Date Next][Thread Prev][Thread Next][Thread Index]

[XaraXtreme-dev] Re: XaraXtreme, Split Debian Package

On Sat, 29 Jul 2006, Joachim Breitner wrote:
> I have created a debian package of 0.7r1596 that builds and seperates:


> Paul, what do you think of that setup,

Can we get the $(DESTDIR) pushed up into the main source build
system?  Ideally that's something we shouldn't need to patch in, incase the
paths are changed.

I'm also a fan of getting rid of 'xaralx' everwhere, if everything is being
rebranded 'xaraxtreme' and 'xaradraw'.  Would people happy with:

  xaraxtreme             the binary
  xaraxtreme-examples    the example files
  libxar-dev             files need to *read a xar file*  [0]
  xaraxtreme-plugin-svg  the SVG filter

later on we can then also have:

  libxaradraw            the rendering library
  libxaradraw-dev        files need to link against the rendering library

It's probably better that /we/ create these last two (libxaradraw) as part
of the package build process (even if Xtreme itself is still statically
linked and the API is likely to change anyway), otherwise somebody else will
do---and will do fairly quickly.

Hyphen-rational, thinking about it, I think 'xaraxtreme' without a hyphen is
better (than 'xara-xtreme').  The hypen then clearly separates
"$the_product" from "things related to $the_product".  The logically name
might be 'xtreme', but that causes namespace collisions and it's known as
'xara' to most people... :)

Joachim: For moment, I also agree about keeping the plugin[s] ;-) in the
main tarball and built as a part of that as those show that they are
'offical' ones and they're coming from that tarball anyway.  The business
about 'libxar' linking against wxWidgets seems a bit messy, but if it does,
then it does...

[0] If 'libxar' actually does something other than read Xar files (eg, it's
actually a plugin interface library), then it should probably be called
something else?...

High on a tall bridge, surrounded by noisy lorries.  London, GB