Restore ModelicaUtilities.h #4487
Conversation
beutlich
force-pushed
the
restore-ModelicaUtilities.h
branch
from
39f3f5c to
8fceb4f
Compare
beutlich
added
L: C-Sources
| @@ -120,7 +120,7 @@ separated by LF or CR-LF. | |||
| pure function error "Print error message and cancel all actions - in case of an unrecoverable error" | |||
| extends Modelica.Icons.Function; | |||
| input String string "String to be printed to error message window"; | |||
| external "C" ModelicaError(string) annotation(Include="#include \"ModelicaUtilities.h\"", Library="ModelicaExternalC"); | |||
There was a problem hiding this comment.
At the moment, it is a tool de-facto responsibility to ensure #include "ModelicaUtilities.h" will find the file, so doesn't this change belong in a separate discussion about how Modelica external functions should point to ModelicaUtilities.h?
| @@ -1,4 +1,4 @@ | |||
| #include "ModelicaUtilities.h" | |||
| #include "../../Modelica/Resources/C-Sources/ModelicaUtilities.h" | |||
There was a problem hiding this comment.
(Attaching comment to one of several possible places.)
Considering that ModelicaUtilities.h has prototypes for functions that should be provided by the tool, and not for functions provided by the MSL, wouldn't a mode natural location be inside ModelicaServices?
| #include "../../Modelica/Resources/C-Sources/ModelicaUtilities.h" | |
| #include "../../ModelicaServices/Resources/Include/ModelicaUtilities.h" |
(Also note the use of the default include directory for the library.)
There was a problem hiding this comment.
If we are now to reintroduce the file in the MSL, I expect it to be taken as an indication of how other libraries should also deal with the need to find the file when building their external code.
One of the concerns behind the earlier decision to not include ModelicaUtilities.h with the MSL was that the file is tied to a version of the language specification. This isn't really a problem for the MSL, since the MSL is verbally tied to a language version:
It is fully compliant to <a href="https://specification.modelica.org/maint/3.6/MLS.html\">Modelica Specification version 3.6 and it has been tested with Modelica tools from different vendors.
but becomes a problem if other libraries that may not even have any dependency on the MSL start making copies of the file.
Is this something to consider for this PR, or a concern to address in future work?
|
I had a closer look at this PR, but it contains a lot more that what I proposed in #4484. The requirement in #4484 is to have a .h file only containing the definitions of the functions found in Section 12.9.6, to be used by people writing external functions that need to call ModelicaUtilities functions. Nothing more than that. Just a courtesy so you don't have to copy-and-paste from the specification. This file is not meant to help building MSL external function libraries. BTW, we agreed that we won't even add them to the repo starting from the next version, as it is the tool vendor's responsibility to provide them. |
I think they can happily copy it into their code base, we could even write that in the header. That's what everybody's been doing so far, but using tool-specific files, which is not good if you want to build tool-agnostic libraries. |
|
Note that the MSL is standard, but not tool agnostic, it is well understood that each tool vendor needs to adapt it to its tool (implementing ModelicaServices low-level functions, compiling the tables C code, etc.) for a number of good reasons. What is standard are the interfaces, but not the implementations. Adapting the MSL to a specific tool is a burden of each tool vendor, that needs to do it once for its own tool, which is OK. What we want to avoid is to give other library developers the burden of developing N versions of their libraries, one for each tool. Of course they should be able to just release one that works everywhere. The MA-provided ModelicaUtilities.h file simply fulfills this purpose. |
This seems to me a good argument. |
Yes, that's why I called it restoration. Actually, the qualifiers for noreturn or format are really useful. I would not agree on a plain ModelicaUtilities.h without them. Why would we give up on such valuable information by design? |
Agreed. In that case, we should also update what we wrote in the MLS, otherwise that would be weird. In fact, the MLS could remain as it is, with a footnote like: these are conceptual definitions, please see the ModelicaConstants.h in ModelicaServices/Resources for more detail. Or something like that. Do you agree? |
Isn't it standard procedure in the C/C++ world to have this sort of difference between how the prototypes are presented in documentation and what they actually look like in a header from the real world? On the same theme, wouldn't it be just ugly if the Modelica specification had to say exactly which macro name ( That said, I think we should also do something about the current presentation of ModelicaUtilities.h in the specification. At the moment, it looks like this:
We could imagine something like this instead (to be made more concrete in a PR on the specification):
|
|
Not so sure about my own suggestion with Modelica URIs here… Would we really want to encourage a solution where the ugly practice of implementations contained in It both seems inconvenient for the library author, and means that tools that – for reasons I can't really understand – would like to use their own ModelicaUtilities.h would need overwrite the file inside ModelicaServices. If we had standardized the use of CMake for external code build projects, I would have proposed to explore the idea of relying on Since most Modelica libraries are made to work with the MSL anyways, it doesn't seem like a too strong assumption that their build projects would be ready to point to a specific version of the MSL for finding ModelicaUtilities.h. A side effect of this is that since the MSL is made for a specific version of the MLS, this way of locating ModelicaUtilities.h is indirectly locating the ModelicaUtilities.h for that specific version of the MLS. Based on this, I would prefer to not start making general use of Modelica URIs for locating ModelicaUtilities.h or its parent directory. Something specific like this could serve us better:
|
Revert "refs modelica#3867: Remove LICENSE_ModelicaUtilities.txt" This reverts commit 7fe506f. Revert "refs modelica#3867: Remove ModelicaUtilities.h" This reverts commit 1bb1d40.
beutlich
force-pushed
the
restore-ModelicaUtilities.h
branch
from
8fceb4f to
272e4d9
Compare
This reverts #3871 for main/4.1.x.