Re: libgsf: very preliminary patch

Robert Staudinger wrote:

> On 2/21/06, Tomas Frydrych <tf@o-hand.com> wrote:
>
>>Ryan Pavlik wrote:
>>
>>>The new WV requires glib on Win32, and I'm fairly certain I also need to
>>>build libgsf for that as well. So for me, recent glib and libgsf in the
>>>main Win32 dist. for 2.6 is a done deal: it's necessary already.
>
>
> Ryan, I'm aware this is outrageous, but what about using prebuilt
> libs? We in linux do that all the time (well, except gentoo *ducks*).
> Seriously, two trustable sources come to mind:
> http://gladewin32.sourceforge.net (this is what gnumeric uses if i'm
> not mistaken)
> http://www.gimp.org/~tml/gimp/win32/downloads.html (Tor Lillqvist's stuff)
>

I've always used Tor's builds for glib DLLs on Windows. For me the
issue has little to do with what is used for releases, its having source
with debug information to make tracking down weird bugs easier.

>
...
>>I also agree with martin that now that we have made glib a dependency,
>>it would make sense to refactor the UT_ layer to make maximum use of it
>>and eliminate any unnecessary code of our own.
>
>
> I have been longing that day.
> This is a quick rundown of some stuff in abi/src/af/util/xp:
>
> UT_Allocator: unused as suggested by grep
> ut_assert -- g_assert stuff
> ut_path -- g_path stuff
> ut_types: many things debatable since provided by glib (UT_uint8,
> ...), IMO we should get rid of XML_Char at least.

Related to this and the STL comments in other messages of this thread.
I'd rather we use standard compliant types if a switch is to be done
instead of glib specific stuff; but I also agree that such a change
should have a technical reason. Also templates should not be used in a
way that crosses plugin API boundary -- I know right now this is not
true (and personally why I consider plugins technically broke since 2.2)
but I still want to see a clean[1] plugin API.

[1] clean just means well defined and done in such a way that any
compiler on the same platform that can be binary compatible could be
used to build the plugin (not currently the case); this means any Win32
compiler including oddballs like VB or Delphi could be used, and given
the headers none of ABI's core source should be required.
>
> Best,
> Rob
>

As for the original question, I'd say commit it, but first PLEASE make a
branch with the non-glib based code that can be worked on (cause I
really do plan to have a working DOS port via Win32 API in the next few
months, but it won't support glib).

Thanks,
Jeremy

(yeah I know, big plans but nothing to show for it, one day I'll be rich
enough to not need to work and still won't have enough time to do
everything I want/plan :-)
Received on Wed Feb 22 20:43:06 2006