Hi Colin,
Your opinion makes sense, you almost convinced me :D but let me post a few open questions/comments:
The modified winebuild or equivalent tool you proposed will work as the current version, completely disconnected from rbuild , it only knows that this tool should be called when a .spec file is found inside a module , then it expects to find a def file with the format modulename.spec.def that he doesn't even know was generated by winebuild , it's simply there. Now if we are going to generate two .def files f.e: modulename.msvc.spec.def and modulename.gcc.spec.def how we should declare it on the modulename.rbuild? we have to add some logic there to map the appropriate generated def file or even worse hardcode the filename in rbuild backends. How does exactly fit on the current rbuild format/backends?
* With my proposed method the def files are created by backends on request so on a msvc build only msvc compatible def files would be generated , also the process takes places inside rbuild so a part from error/checking and the other advantages the generated def file can be automatically added to the module so would render the importlibrary element obsolete. It would be all automatic.
Don't see winebuild as a compiler!
Actually it is :) . A compiler is blackbox which produces something (in this case a def file + C files) out of a human-readable text file.
Your example lib/debugsup/debugsup.rbuild just uses the same export definition file for two modules, I don't consider this a hack.
Of course it works but I think is hack for two reasons:
- debugsup_ntoskrnl and debugsup_ntdll are not 'real' modules , they don't represent or produce anything they are there only because there isn't a better solution. - If you take a look at /tools/rbuild/modulehandler.cpp:2506 you will be horrorified to see that both module names are hardcoded on rbuild which is not good.
Last but not least, from my point of view integration is important, We have a fairly complex build tool, all the information we can give to it about the codebase will worth it because more automatic checking we will be able to do and more things we will be able to autogenerate , we should let rbuild itself generate as much things as possible.
/marc