disable error on warning

[Derek Atkins]

Josh Sled <jsled at asynchronous.org> writes:

> On Mon, 2005-08-22 at 12:18 -0400, Derek Atkins wrote:
>> IMHO, a conditional build for the internal goffice vs. an external
>> library would be fine.  If you find libgoffice installed then use
>> that, otherwise try to build our own.  But we should probably also
>> have a configure check for the version of libgda.
>
> Maybe, but remember that lib/goffice/ isn't exactly a copy of
> libgoffice.  It's really
> lib/jsled-ripped-something-out-of-gnumeric-cvs-kinda-like-goffice-and-jody-doesn't-agree-with-our-dependency-philosophy-so-we-can't-directly-depend-on-the-real-libgoffice,-yet/
> As such, it's not clear that they're going to be api compatible.

I wasn't proposing that we _depend_ on libgoffice, but if it *IS*
available on the current platform I see no reason not to use it....
Provided it's API compatible, of course.

> It might be worth it to ensure that that's true, but it might also be
> true that if we wait long enough, we can safely entail libgoffice's
> dependency set, and we can just depend on libgoffice properly and drop
> it from our source tree.

Well, I think the issue is that some distros (read: Debian Unstable)
may be far enough along that they DO have the "newer" dependencies
to enable them to use a native libgoffice...  But we shouldn't drop
our copy from our tree because we're still targetting FC3/RHEL4.

I.e., we should try to build with the native version if we're building
on a distro that is "new enough" to provide it, but we should still
work on our target platform by using our own.

At least that's how *I* think it should work ;)

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available