As I remember it, Hoijui didn't get around to implementing AI interface error checking, and there wasn't much need for it, and us AI developers never complained about it, so he got on with other more pressing matters such as the pureint branch.
Although a more graceful crash message or even abandoning loading the AI, continuing, and just spitting out an error saying loading failed, or a stacktrace at the very least would be welcomed.
Supporting old interfaces would be nice, but I think that would lead to allsorts of maintenance issues and it would force all sorts of design decisions on us that we would regret later.
Instead, I'd be happy if we just had clear warnings and messages, and a graceful fallback, e.g.
AI 1 (Shard v0.30) failed to load, interface version mismatch, interface version: 12, AI supports: 11. Please rebuild with the latest engine source
This would be a massive improvement, as this is even better and clearer than what we had before Hoijui arrived here and rearchitected the AI interface, and even back then this was an issue of contention amongst those unfamiliar with how things worked.
This message is more precise, tells you which AI failed to load, why it failed to load, and what needs doing to fix it. This could be followed by the usual abandoning the attempt to load the AI and continuing as if nothing happened.
indeed, what AF suggests there should be done. the other thing is practical nonsense, maintenance wise. not doable. The reason this is not done yet, is cause i wanted a more sophisticated version checking thing, which would include eg. the engine version, mod name and version and whatnot, but as was discussed in other threads, this would be done otherwise. and as pureint is in master now, i guess the time to implement this is good now.
What we want to to here, is check ABI (Application Binary Interface) compatibility. To do this, we have some stuff prepared in the source already (see eg. aidefines.h). But it is only partly useful, as it can not find all incompatibilities. For example, it would detect if the number of functions in the callback changed, but not if names or arguments changed. To really find all incompatibilities, we could create a hash over all the headers in rts/ExternalAI/Interface/ in the build-system (CMake), pass it to the source with a define, and use this as a version number. The problem with this is, that it will also detect incompatibility if merely a comment or white-space changed. What we would need, is a way to create a kind of pre-compiled form of the headers in rts/ExternalAI/Interface/, and do a hash over these. I feel like actual pre-compiled headers is not the right thing here, as it is meant for only a single header, and it does work differently on different compilers. An other method would be, processing/stripping the headers with AWK, and hashing the resulting files. Please give input about how else it could be done. To consider:
all headers are C only
we should get the same results with different compilers/build-system
optional (unimportant): create the same hash on different OS
stuff like 32 or 64 bit-ness can be checked in an other way -> does not have to be considered in the hash
the problem is not the pre-processor, but the compiling step. if the preprocessors of different compilers would spit out different stuff when fed with these headers, that would be a bug in the headers. hiding this in the version number would be bad, so using the preprocessor of the compiler that will be used to compile is preferable, if it need be done.
If we run the headers through the mcpp preprocessor on spring current, and the headers the AI used, the output should be identical if both use the same version.
If the headers are identical, then of course the AI must be compatible since the same headers and interface data is being used to compile the ABI, and the interface is based on a C API.
As such, we need only calculate this hash in the spring github repo and bundle it in a separate header file so as not to effect the preprocessor step. That way if the version hash is identical, we know that the source both binaries were built from is the same, regardless of compiler, and thus we are using the same interface version.
We could automate the whole process this way ^_^ I suggest the version ID and the function that implements the callback for getting the version be included in an autogenerated header file, then included in the AI headers surrounded by ifndef guards. These can then be used to filter out this include in the preprocessor stage, and then the resulting header can be hashed, and then the hash written to the header. That way the AIs would not need to be modified, and there would be no accidental releases that have newer interfaces but the version has not been updated.
i do not see what the pre-processor is useful for in your proposal. we get the same effect when using only awk (we already have awk readily available in CMake on different OS, sed not) to strip out the comments/white-spaces. as i said, we need to arrive at the same pre-processed headers on different compilers anyway. if this is not the case, it is a bug in the headers and needs to be corrected there. it does not have to be incorporated into a version hash.
basically, what we have two options:
reduce the headers (source files) to the extend where they represent only what actually matters for ABI compatibility
compile them into some binary format
in either way, it would be good to use only a single tool to do it, and not multiple ones. i also can not see how multiple ones would make it any better. both ways have pros an contras i guess. the later one may show incompatibility where there is none, and the source file approach will likely consist of self-made stripping scripts -> one more source for errors, need to be maintained.
BrainDamage pointed me to the ABI_compliance_checker. This is a perl tool, so possibly not optimal to use from CMake (cause of the perl dependency). The wiki page also mentions some Similar tools, among them icheck, which seems to be better fit for what we need. Sadly, it looks like it... pretty much died in about 2005 or so :/. It is a C utility that compresses C headers to a form that represents ABI compatibility. Maybe we can get to latest sources of it, and if it is simple (in terms of dependencies), we might just be able to compile it ourselfs (also for windows) and use that.
not able to contact the author of icheck, but i found a source package from debian.. it is perl too. possibly it is even the forefather of the ABI Compliance Checker. Speaking of which, the wiki states it only works on POSIX. though, i cant imagine the part we need would not work on windows, as it just converts C source.
am working on a custom made system. quite complex for that small thing it will do in the end. AWK plus CMake magic. quite some progress made already: can create a file containing an MD5 hash that sums up a customizable list of header files, and gets actualized only & always when it should (eg, headers or scripts change). i can also put it into a #define in a C header, but will now try to get it into the *Info.lua files as a property, so it could also be used by unitsync.
Users browsing this forum: No registered users and 0 guests
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot post attachments in this forum