-
Notifications
You must be signed in to change notification settings - Fork 84
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Text improvements to 2.4 and 2.5 #1702
Text improvements to 2.4 and 2.5 #1702
Conversation
This PR reflects @TorstenBlochwitz and my (@andreas-junghanns) changes of the last 2 days. |
@@ -185,7 +185,7 @@ The following table lists the most common platform tuples for shared libraries a | |||
|
|||
If runtime libraries are needed by the FMU that have to be present on the target machine and cannot be shipped within the FMU (e.g., due to licensing issues), then automatic processing is likely impossible. | |||
In such cases special handling is needed, for example, by providing the runtime libraries at appropriate places by the receiver. | |||
The requirements and the expected processing should be documented in the `documentation` directory in this case. + | |||
The requirements and the expected processing must be documented in the `documentation` directory in the file `externalDependencies.{txt|html}`. + |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure if we should have "must" here. This boils down to "you should not ship poorly documented FMUs"...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The alternative is to say: "Let´s not define things, people will not do it right anyway."
Poorly documented FMUs that are not running because the user does not know what to do should be blamed on the exporter - and this "must" is a blame distribution mechanism.
In the end, we express our expectation, knowing about the reality...
Co-authored-by: Klaus Schuch <klaus.schuch@avl.com>
No description provided.