We are on the verge of abandoning the Rhapsody-Simulink integration because of the paths issue.

The problem is that when the Rhapsody-Simulink integration is run, absolute paths to the Simulink code are inserted in tags in the <SimulinkBlock> class in Rhapsody. This means that the model cannot be built from a configuration management repository because the path is usually different from the path used for development. When building for a release it is unacceptable to have to make changes to a CM copy of the model. We have also tried relative paths, but these cannot be used. We're using Rhapsody 7.4 and would find it difficult to change at this stage of the project.

Has anyone found a work-around for the problem of paths?


(PS: There is another CM-related issue in 7.4 that the <SimulinkBlock> class must not be read-only: this is fixed in 7.5, but we decided we could tolerate the problem (by making the class writable before building), provided that no actual change was made to the model.)

Since this is an old post, I'm not sure if you have figured it out or abandoned it yet, but in case anyone is in the same boat. In the object you created to encapsulate the Simulink model (i.e. the one with the SimulinkBlock stereotype) there is a tag "SimulinkCodeDir." This has the absolute path in the Value for this tag. If you change this value, the absolute path goes away. There are two unfortunate things though. 1) The path to your RTW code must start at the root of your component's path. Rhapsody doesn't seem to be smart enough to understand "..\" to move up. 2) The value in this tag seems to get changed anytime you import the model so whenever you import it, you have to go back to the tag, double-click on it, and then change the value. I'm using version 7.5 and the MicroC framework.

Well, we abandoned, concluding that the integration was not yet fit to use.

Have you successfully generated and compiled using relative paths? When I tried this (on Rhapsody 7.4), I found that to code-generate correctly the relative path has to be relative to the directory containing the .rpy file, whereas for the code to compile it has to be relative to the directory containing the generated code. If you've found a way to overcome this problem, it would indeed be interesting.