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

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

Paul Sladen wrote:

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.


It's already there as of this afternoon.


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.


mmm... I don't want to encourage people to think it is in a state to use
as an external library yet. If they pull it out themselves and it
blows up in their face next time we do an API change, that's their
own issue. If you package it up you are saying "see, this thing has
got a stable API, even if not a stable ABI, IE you will be fine
to static link to it at least". That's not the case. There is
(for instance) a lot of work to be done on the context stuff before
it becomes useful for outside consumption, so I'd rather not
do this just yet because I think it would be seen to "bless" it as
OK. If we did that, we would need to write in big letters DO NOT
USE THIS PACKAGE OUTSIDE XARA XTREME THE API AND ABI ARE UNSTABLE.
But what's the point of creating a package we're telling people
not to use? That's for libxaradraw-dev. libxaradraw would be
empty because it's static link only for the above reason. So I
don't think we should do this yet.


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...


It's in essence because it uses the wxWidgets basic classes. I too
thought "yuck" until Gerry reminded me that:
1. Anyone bringing up UI will want it to look consistent with the
   program (filters can bring up UI).
2. Anyone writing filters will want some sort of file streaming library
   anyway, so it's helpful.

Note you don't need to initialize your filter as a GUI app - you can write
a completely command line based one that will (for instance) run outside
X.


[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?...


It's really a sort of "backwards filter". All it does is read and
write xar files to stdio. But the idea is you write the bit
that reads and writes other things. It pipes the xar file to/from
Xtreme. So in each case, it is definitely either reading or
writing a xar file.

Alex