Describe common ways of using ModelicaUtilities.h #3455
Conversation
| \end{example} | ||
|
|
||
| \begin{nonnormative} | ||
| There is no standardized way to build external libraries using the functions in \filename{ModelicaUtilities.h}. |
There was a problem hiding this comment.
The term "standardized" is a bit ambiguous, would it be possible to be clearer?
As a library developer ideally one would want a tool-independent way of building external libraries using them; having a standardized tool-dependent way would be messy, and we have neither (that's why wrappers are needed even if building libraries for Modelica - but on the other hand making the library independent of Modelica has benefits).
There was a problem hiding this comment.
Hmm... Having tested a few things within ModelicaStandardLibrary I'm not sure how necessary and correct this is.
The current build-projects for resources just includes ModelicaUtilities.h; and doesn't do any special tricks, so it seems there is at least a tool-dependent way of building external libraries using the function in ModelicaUtilities.h; and the resulting library may even be portable between tools (I haven't checked).
There was a problem hiding this comment.
The term "standardized" is a bit ambiguous, would it be possible to be clearer?
Yes, it would be possible, but I'd also like to avoid introducing new ways to talk about what is determined by the document itself. For example, we currently have formulations such as
The license file is standardized.
or
Obfuscation and encryption are not standardized.
Hence, I'm somewhat skeptical to use a formulation like this instead:
| There is no standardized way to build external libraries using the functions in \filename{ModelicaUtilities.h}. | |
| The Modelica specification does not describe any way to build external libraries using the functions in \filename{ModelicaUtilities.h}. |
There was a problem hiding this comment.
The current build-projects for resources just includes ModelicaUtilities.h; and doesn't do any special tricks, so it seems there is at least a tool-dependent way of building external libraries using the function in ModelicaUtilities.h; and the resulting library may even be portable between tools (I haven't checked).
The MSL is cheating by including its own copy of ModelicaUtilities.h. We don't want a solution where there's a copy of this file in every library; it would make it impossible to develop the contents of the file. Instead, there should be a mechanism for tools to tell (CMake projects à la #1668) where they provide this file.
There was a problem hiding this comment.
But even if MSL is "cheating" - it seems odd to specify that the approach that is currently used shouldn't work. I agree that we need something better, but requiring a change before we have a the better approach seems problematic.
There was a problem hiding this comment.
That we state that there is no standardized way is not the same as saying that there is nothing that could work in non-standardized ways.
There was a problem hiding this comment.
The MSL is cheating by including its own copy of ModelicaUtilities.h.
Which no longer is true as of modelica/ModelicaStandardLibrary#3871.
There was a problem hiding this comment.
Well, this just shifts the discussion to whether what is done inside .CI could be considered a standardized non-cheating solution for building the binaries. I still think it isn't; the CI is like its own tool environment, providing its own ModelicaUtilities.h (as every tool environment should) and building the binaries in a way which hasn't been standardized (and probably won't be either, as everything points in the direction of going with CMake for standardization).
This was factored out of #3452, as promised in #3452 (comment).
In addition to examples and other non-normative text, this PR makes clear that
#include "ModelicaUtilities.h"shall work inside anIncludeannotation.