In SDK, fonline.h was always edited manually; in fact, it never was part of source repo at all. It's a working solution, sure, but i'd like to automate it, to minimize possible human mistakes resulting in broken dlls.
In perfect world, we'd just copy related headers (Critter.h, Item.h, Map.h, and so on), write a wrapper with #include wall, add entry point stuff etc. and be done with it.
That, however, won't work as headers aren't written with such exposure in mind. Just look at Common.h which is must-have with such approach - wall of #pragma comment(lib) and #include for almost all third party libs, and that's just a beginning. Ugh.
I don't consider it as a part of any currently planned milestones. V15 will most likely affect it, but automated dll header creation should be a result of various changes, rather than a goal. As of now, i've included header in repo, so we can at least connect changes in header with changes in engine, by simply doing both in one commit.
Things which we can prepared beforehand:
[x] add dummy dll target into build process; if it fails on exactly same compiler, it's a major screwup
[ ] make a proper test and include at least one other toolset
[ ] use external tools for testing across multiple compilers (appveyor, travis)
I'll probably get on that at some point in future, as of today it's very minor priority.
In SDK, fonline.h was always edited manually; in fact, it never was part of source repo at all. It's a working solution, sure, but i'd like to automate it, to minimize possible human mistakes resulting in broken dlls.
In perfect world, we'd just copy related headers (Critter.h, Item.h, Map.h, and so on), write a wrapper with
#includewall, add entry point stuff etc. and be done with it.That, however, won't work as headers aren't written with such exposure in mind. Just look at Common.h which is must-have with such approach - wall of
#pragma comment(lib)and#includefor almost all third party libs, and that's just a beginning. Ugh.I don't consider it as a part of any currently planned milestones. V15 will most likely affect it, but automated dll header creation should be a result of various changes, rather than a goal. As of now, i've included header in repo, so we can at least connect changes in header with changes in engine, by simply doing both in one commit.
Things which we can prepared beforehand:
I'll probably get on that at some point in future, as of today it's very minor priority.