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