Theoretically extending this logic to infinity will lead to creation of a new high level language, stored in xml documents, parsing which rbuild generates source code in C or other language needed. :-).
The thing is, .def is rather simple, .spec is a bit more advanced to include more stuff ("stub", what else does reactos use from it?). There is absolutely no need to invent yet another format for storing export functions. It was invented once by MSVC, it was invented by GCC/MinGW, both are incompatible, it was invented by Wine to have ability of easy functions stubbing. Should there be another invention of the same wheel by ReactOS now?
If GCC/MinGW wouldn't be that *strange*, it could stdcall-fixup, and then properly link, this way .def could be created in the lowest common denominator format.
With the best regards, Aleksey Bragin.
On Nov 24, 2007, at 4:36 PM, Marc Piulachs wrote:
I wouldn't use .spec files for several reasons, first of all is that it violates the way how rbuild currently works. Rbuild reads xml documents in a custom format and produce different outputs depending on various conditions. IMO rbuild shouldn't be extended to parse anything else but just .rbuild files.
Also, winebuild from the rbuild point of view is not different from any other compiler , so I think the problem is just the opposite , rbuild should use the information stored in it's rbuild file to produce the spec file in addition to the specific def file (it shouldn't be produced by winebuild anymore) as both files are required to compile wine module XYZ.
Having the information in rbuild files has also other advantages, the most important is that it would allow us to use the conditional logic to export functions based on a given condition, for example hacks like /lib/debugsup.rbuild won't be necessary anymore.
I wouldn't fork winebuild.
Regards, Marc