[sword-devel] remove buildtest

[Greg Hellings]

Manfred,

On Wed, Feb 18, 2009 at 12:16 PM, Manfred Bergmann <bergmannmd at web.de> wrote:
> Hi Greg.
>
>
> Am 18.02.2009 um 17:33 schrieb Greg Hellings:
>
>> On Wed, Feb 18, 2009 at 10:54 AM, Manfred Bergmann <bergmannmd at web.de>
>> wrote:
>>>
>>> Hi.
>>>
>>> Is it possible to remove the buildtest from the build process of the
>>> library?
>>
>> I thought there was a configure-time switch, but I could be mistaken on
>> that.
>
> I build with --disable-utilities, tests are disabled by default but that
> doesn't seem to apply for buildtest.

I believe I've gone into the Makefile.in and found all references to
buildtest.cpp and removed it -- obviously not the most user-friendly
way to go about it, but I believe it works.  In absence of a configure
option, that may be your best bet... just add it to a general for-Mac
patch until a switch is put into configure.

>
>>>
>>> The ICU support on MacOSX is only partial and there is no licuio library
>>> which is needed for buildtest but not for the library.
>>
>> From Macports I have a /opt/local/lib/libicuio.dylib as well as a
>> .40.dylib and .40.0.dylib.  For many of the SWORD library dependencies
>> I have found Macports invaluable as a way to maintain and update them
>> freely.
>>
>>> This breaks my build script so that I now have to put things together
>>> manually in order to create a ppc/intel cross-compile binary.
>>
>> I'm fairly certain that the macports.conf file has a way to specify
>> that you want to build fat binaries.  According to their website, just
>> enabling the +universal flag in their variants.conf file should allow
>> those libraries that support it to build in universal i386/ppc fat
>> binaries.
>
> The problem is that I don't like MacPorts and I won't install a second
> package management system next to Fink.
> Fink only installs the headers for the Apple supplied ICU (3.6) so you'll be
> able to use it for compile.
>
> Using a MacPorts version would create a dependency in that someone needs to
> install the MacPorts libicu.
> Static linking is not so easy, if possible at all on Darwin.

I also won't stand for having both package managers installed -- my
issue was that fink was so far behind release versions, didn't work
with its attempt to support the installed Apple libraries (e.g.
libicu) and had almost no package coverage relative to MacPorts that I
finally just uninstalled it, installed MacPorts and have never looked
back.  The thing that finally convinced me to change was libicu, to
tell the truth.  Fink's attempt to provide the headers never resulted
in a combination of headers/libraries that I could force to work,
whereas with MacPorts I was able to have a later version of the
library, have the headers and build against them.

If you use a .dylib from MacPorts and link against it, can't you just
add it to your .app bundle and distribute it with the program?  As for
static linking, I've never had a problem with it -- that's how I was
able to shoehorn the SWORD binaries into builds of BibleTime that I
was doing on Mac.  I just disabled shared libraries for SWORD, linked
against the static libraries with BibleTime and tossed the completed
binary into the .app bundle.  I never bothered to try the .dylib
approach, because I didn't want to have to learn how to position that
at the same time I was learning what a .app folder was at the time,
but I have seen .dylib files inside of other .app folders before, so
it ought to be possible.  At the very least, placing the .dylib in the
app bundle would remove someone being required to install MacPorts (I
just checked and MacPorts claims that icu has no other dependencies).
It would increase the download size of your app, but not atrociously
so.

--Greg