Am 10.06.2009 um 05:14 schrieb Gregory Hellings:
On Jun 9, 2009, at 22:51, Dmitrijs Ledkovs
<dmitrij.led...@gmail.com> wrote:
2009/6/10 Greg Hellings <greg.helli...@gmail.com>:
I know the question has been raised before about separating
utilities
from the library but nothing has ever shaken out of it. To me, this
again makes sense in this category. If the utilities were placed
into
their own SVN repository they could easily be released on their own
schedule with their own requirements. An svn:externals could force
the source to be included with an SVN checkout of the library, but
could allow the utilities to be conceptually "operated" as a set of
highly specialized front-ends (which is really what they are) for
the
library and released on their own schedule.
--Greg
Keep the same svn. With a little bit of auto-foo magic you can
generate two different tarballs and release either of them at their
respective schedules.
I don't think that it's a technical issue that people are worried
about as much as it is a conceptual one. If it's a separate repo, I
think it's easier for most people to think of "releasing" the
utilities separately when appropriate.
Generally I would think too the utilities are front-ends and should
get their own place in svn. I think though a separate folder on the
same level as the engine would be sufficient instead of a whole repo.
Manfred
Releasing a single subdirectory within another project that has its
own release schedule seems more counterintuitive than including a
related project as an external. However, at this point, moving to
an external repo could fragment all the SVN history for the utils if
not done correctly.
But minimally the autotools magic should probably be reworked to
allow such releases by whichever method.
--Greg
IMHO this should be at least done for the bindings. Because python
bindings autofoo assumes that the libsword is already installed on
the
system during build-time. This is very hard to satisfy on buildd /
chroot. On the other hand if bindings were a separate tarball it
could
easily build-depend on libsword such that we (as is packagers) create
libsword package first and then create bindings package.
Maybe I'm wrong. In that case could you please suggest how to build
python bindings when all you have is compiled sword in the current
directory, or you have libsword installed into $DESTDIR eg. in debian
case ./debian/libsword/usr/lib/ and other similar paths.
--
With best regards
Dmitrijs Ledkovs (for short Dima),
Ледков Дмитрий Юрьевич
_______________________________________________
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
_______________________________________________
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
_______________________________________________
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
