Describe common ways of using ModelicaUtilities.h #3455
Conversation
| The tool must ensure that the header is found by \lstinline[language=C]!#include "ModelicaUtilities.h"! within an \lstinline!Include! annotation (see \cref{annotations-for-external-libraries-and-include-files}); no \lstinline!IncludeDirectory! annotation is needed. | ||
|
|
||
| \begin{example} | ||
| The following usage patterns are common: |
There was a problem hiding this comment.
This is too much text where real examples seem more useful to me. Might be a good idea to have all three patterns available as proper examples, e. g. in the ModelicaCompliance library or ModelicaReference library or any other dedicated library.
Co-authored-by: Hans Olsson <[email protected]>
chapters/functions.tex
Outdated
| \end{example} | ||
|
|
||
| \begin{nonnormative} | ||
| When building external libraries, it is not possible to rely on the tool mechanism that provides \filename{ModelicaUtilities.h} for \lstinline!Include! annotations. |
There was a problem hiding this comment.
But I could add IncludeDirectory="modelica://Modelica/Resources/C-Sources" to my annotations of my external library project such that ModelicaUtilities.h is found on the include path.
There was a problem hiding this comment.
This remark is not about building code in the annotations of a Modelica external function. This is about building an external library with no Modelica code or concepts involved, with the intent of later linking with the library using the Library-annotation of a Modelica external function.
There was a problem hiding this comment.
I have tried to make that point clearer, see below.
There was a problem hiding this comment.
@beutlich, did the added independently of Modelica tools provide sufficient clarification?
|
|
||
| \begin{nonnormative} | ||
| When building external libraries, it is not possible to rely on the tool mechanism that provides \filename{ModelicaUtilities.h} for \lstinline!Include! annotations. | ||
| Instead, an external library project may contain its own instance of \filename{ModelicaUtilities.h}, for example obtained by making a copy of the instance included within the Modelica Standard Library. |
There was a problem hiding this comment.
| Instead, an external library project may contain its own instance of \filename{ModelicaUtilities.h}, for example obtained by making a copy of the instance included within the Modelica Standard Library. | |
| Instead, an external library project may use the \filename{ModelicaUtilities.h} from the Modelica Standard Library. |
I don't think we need to specify that the project contains the file; just that it uses it. Basically "making a copy" seems bad from a project-management perspective.
(Either just have it as external include path, or have MSL as a submodule and include from it.)
There was a problem hiding this comment.
The external include path idea doesn't work since there is no standardization of how a build system should figure out the location. The MSL submodule approach seems like an utterly inefficient and perplexing way of getting hold of this one file. This is why I proposed saying may contain its own instance; it describes one way of doing it, without saying it is the only way.
There was a problem hiding this comment.
The external include path idea doesn't work since there is no standardization of how a build system should figure out the location.
Ok, I just thought that by specifying "use" we didn't have to explain any of that; whether you update the path in build-configurations in some way, copy the file, or do something else you just "use" the file.
There was a problem hiding this comment.
But I can live with this as well. Just giving beutlich a few more days to comment.
Co-authored-by: Hans Olsson <[email protected]>
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.