winebuild & (name, heap, init)

[Patrik Stridvall]

> On September 10, 2002 02:15 pm, Alexandre Julliard wrote:
> 
> > Well, the problem is that the __declspec stuff is usually inside
> > macros, so you have to run the code through the C 
> preprocessor to find
> > them. It can be done, but it's not that trivial. Also one thing you
> > need to extract is the relay debugging information (and for 16-bit
> > code information for the relay routines), and this requires 
> a C parser
> > (or some of Patrik's magic Perl stuff).
> 
> I'm sure if we have the political will at the top, we'll find a
> solution... :) Patrik, care to help us extract the required stuff
> directly out of the source file?

Sure. BTW winapi_extract can already do that:

winapi_extract --spec-files

This generates a .spec2 file that should hopefully be the same as
the .spec file. It currently isn't (except for a few files) though
but that can hopefully be fixed.

Outputing in another format like .def files or
whatever should be quite easy.

However note that winapi_extract is quite ad hoc and specfic for
parsing the Wine source tree. It is not a generalized C parser.

I have begun with a generalized C parser in winapi_fixup however
it doesn't quite work that good yet. Parsing generalized C
is non trivial.
 
> > A related idea I had is to store the relay debugging independently
> > from the .spec file; you could then use it in other cases, notably
> > with snoop debugging of native dlls. And then you no longer need a
> > .spec, you can use a .def or directly extract the __declspecs, at
> > least for Win32. This would also potentially allow more intelligent
> > relay routines, maybe even per-dll relay code that knows 
> about the dll
> > internal data structures; and hopefully also relay debugging of COM
> > interfaces.
> 
> Exactly! That's where I was driving at. But this depends on getting
> stuff automatically out of .c file, because this way we can retain
> the type information, which we now lose (except for strings). Once
> we have the type information, the sky's the limit... But most 
> imprtantly,
> we eliminate (1) a potential source of mistakes, (2) a barrier for
> new commers (which are likely to be from the Windows world), and
> (3) avoid maintenaning the 700KB of .specs!!!

Agreed, but the script that does it is also a potential source of mistake
and the current state of the winapi tools are that they work MOST of
the time. However if we are to replace the .spec files it must work
ALL the time.

However I might be able to write a very specialized parser, that
pipes the .c files through the C preprosessor, that work all of the 
time, but this is quite some work as well.

Note however that piping every source file through the C prepropessor
is VERY SLOW. That is one of the reason the winapi tools doesn't
do that.