modelica-trac-importer
commented
5 years ago Comment by iakovn on 8 Apr 2014 08:39 UTC In the compliance checker & FMI Library we were addressing this since a couple of years by now. Basic principle is to implement namespace separation in the importing code that needs multi-version FMI support and follow some design rules. The fact that we used some renaming in the code is just an implementation detail which does not require changes to the standard. We had so far no problems running compliance checker in Visual Studio. The code is Public domain so others can use it.
When statically linking each FMU will get it's own name for each function. Therefore I don't see any additional complex issues there. The importing code obviously needs to treat FMUs of different standard versions differently anyway.
Modelon's preference is therefore keeping RC1 intact unless there are cases where things actually cannot be done with the current standard proposal.
That said we agree that handling multiple standards is cumbersome while manageable. If there is a decision to change names in the standard then:
- Platform files MUST be included in renaming. They are actually the most difficult ones to handle (e.g., due to fmiBoolean having different actual types in FMI1 & FMI2). I'd also expect value reference type to become 64-bit eventually when FMI is supporting large arrays.
- You're suggesting "fmi20" prefix. I'm really hoping that FMI 2.1 will be backward compatible with FMI 2.0 (that is any FMI 2.0 FMU will be a valid FMI 2.1 FMU but FMI 2.1 may have additional features) and so fmi2 should be enough. Incompatibility would then require a change to the major version number which is more natural.
Reported by andreas.junghanns on 4 Apr 2014 10:12 UTC All this is related to building an environment that can run FMUs of 1.0 and 2.0. So far, file names, type names etc do not reflect the different versions of the standard.
This causes the following problems: 1) Include files now are named the same: so we have to tweak our build process to build different objects using the different include files. Not nice, but manageable. 2) Functions with the same name have different arguments: Only using function pointers saves us from serious trouble here. But we have to still cast these to get the compiler to accept the right arguments - or build abstraction layers to avoid compiler trouble. Not nice and the code turns into a mess. 3) Enums with the same name have different elements: We only extended one and at the end. Not nice, but we might get away with it - this time (next version?). 4) Structs with the same name but different definitions: When using the #include files right, we get it compiled correctly. But I have seen Visual Studio debugger completely loosing it (dying on me in horribly ways) because it assumes structs with the same name using the same definition (sizes)
We could avoid all (?) these problems, if all types, macros, enums, files and functions (...?) have unique names across versions. (Platform types might be excluded - they are not connected to the standard version but to the platform version - and that is handled separately.)
The suggestion (Martin Otter, Torsten Blochwitz, Andreas Junghanns) is: change all "fmi" to "fmi20" (read this case insensitive) for:
This would be a major change, very late - violating the common definition of the "RC"-phase we are officially in. But if we don't do this now, we cannot do it either when building 2.1 or later, because everyone will have build around the current limitations with multi-version tools.
In the compliance checker, the problem was solved by renaming (as suggested here). Is there another solution people have found that we are not aware of and saves us from the proposed renaming?
Migrated-From: https://trac.fmi-standard.org/ticket/218