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.