Re: Gtk port to Win32 "progress report"

[Tim Janik <timj gtk org>]

On 19 Aug 1998, Owen Taylor wrote:

> 
> Tim Janik <timj@gtk.org> writes:
> 
> > On Tue, 18 Aug 1998, Tor Lillqvist wrote:
> > 
> > > > Would it be easier just to list all exported functions in the DLL DEF
> > > > file when the DLL is linked? This is also used to generate the import
> > > > library.
> > > 
> > > Well, yes, but I think the current trend is to avoid .def files as
> > > much as possible? Keeping the list of exports in a .def file
> > > up-to-date would be a pain, wouldnn't it?
> > 
> > hm, i'd volounteer to hack a compiler frontend that will generate
> > the required windows header, but maybe owen wants to tackle this
> > with some perl magic? ;)
> 
> Hmmm, how would this work? I think you would have to mark the
> relevant symbols in the header files with some token for the
> perl script to look for, maybesomething like:
>  
>  GLIBAPI void some_func()
> 
> ;-)
> 
> So I'm not sure that approach is worth pursuing. And I think
> the compiler-frontend idea is worse - I think we should try
> to stick to standard tools. So I tend to think that Tor's
> approach is a decent one.

hm, i wanted to go with his approach as well, but since the windows-export.def
file will be used to generate one big header file that just lists all gtk
prototypes again, prefixing them with GTKAPI, and since it would be most
convenient to have this .def file be autogenerated, i wonder why we shouldn't
just use some c/perl/something script/program, that gets the gtk headers as
input and dumps them again with the GTKAPI prefix.

i.e.

echo "void test(); gboolean kick();" | mymagic GTKAPI
produces
> GTKAPI void test(); GTKAPI gboolean kick();

this way, the windows .def file can be skipped, and we get one big header
file for the dll, including all symbol exports. and (probably more
important) it will always be up-to-date.

> 
> Regards,
>                                         Owen
> 
> 

---
ciaoTJ