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?
Just to clarify one thing, if we were going to support only one compiler which speaks only one dialect of those 3 there wouldn't be any problem. But it's a fact that we want to support at least 3 compilers (for now) msvc , gcc and winebuild which use incompatible syntax between them. Expressing this information in a structured format like xml makes the parsing stage easier and we have all the power builtin in rbuild to process that information and generate back the msvc , gcc and winebuild versions with ease. All the pieces fit together and we don't have to modify winebuild not even create any other tool or parser from scratch.
I think is the easier solution to archive real compiler independent .def files.
/marc
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
_______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev