[sword-devel] How broadly do we define "API" (was: Re: which engine sources to use )
bergmannmd at web.de
Wed Jun 10 00:00:12 MST 2009
Am 10.06.2009 um 05:14 schrieb Gregory Hellings:
> On Jun 9, 2009, at 22:51, Dmitrijs Ledkovs
> <dmitrij.ledkov at gmail.com> wrote:
>> 2009/6/10 Greg Hellings <greg.hellings at gmail.com>:
>>> I know the question has been raised before about separating
>>> 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
>>> 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
>>> library and released on their own schedule.
>> 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.
> 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.
>> IMHO this should be at least done for the bindings. Because python
>> bindings autofoo assumes that the libsword is already installed on
>> system during build-time. This is very hard to satisfy on buildd /
>> chroot. On the other hand if bindings were a separate tarball it
>> 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 at crosswire.org
>> Instructions to unsubscribe/change your settings at above page
> sword-devel mailing list: sword-devel at crosswire.org
> Instructions to unsubscribe/change your settings at above page
More information about the sword-devel