Community
Participate
Working Groups
Currently if a model imports a package from a user model, and uses some element from that package, code is not generated for that element, and if code for that element has already been generated elsewhere, the generated Makefile doesn't point to the folder where code for the external element resides. The code generator must support one of two things: 1) Code for external elements is generated inside the model being generated or 2) Code for external elements is generated elsewhere or 3) Code for external elements is not generated, but it is assumed to have been generated and the Makefile should point to it. After a discussion with Charles, it seems like option #1 is the one that makes the most sense.
I'm not sure if this one is still valid, but we should investigate it.
Yes, this probably needs more investigation. This is not only a question for the code generator itself, but for Papyrus in general, i.e. how do you structure and scale really large (multi-)models, and how shall the corresponding generated code be handled. It is also related to the configuration of transformation, where you should be able to specify some build dependencies/hierarchies as well. So I am not fully sure that option #1 really makes most sense, since when you have large (multi-)models you can potentially have package imports importing the same library on several other models. So you really want to have option #3. But you probably should not rely on package import (I am still not convinced that we must force the use of package imports, and instead allow more implicit dependencies between different models). Probably it is the configuration of the transformations (and its dependencies/hierarchies) that controls build dependencies and handles the aspect of establishing the corresponding relations between Makefiles.
I think what we need is actually a combination of options. I agree that Option #1 makes sense in some cases, but not all. As Peter rightly points out, this option fails in some (potentially large) distributed development and build environment. I'm not sure about about the difference between options #2 and #3. Instead, let me define #4 and #5, below. If the code is generated elsewhere, there are two cases to consider: 4) the model library is just a (potentially incomplete) representation of the actual "linkable" library, similar to what we have done for the RTS library. In such a case, the library only exists so that its element can be used within and referenced from the the client model, but code generation should never happen since the code is provided in another form. We would then need a way to state that this library should not be generated and provide a location where it can be found (workspace reference?). 5) The library is actually fully generated from another Papyrus-RT UML-RT model. In contrast to the case above, the mode for this library is being used for code generation and either objects (".o") or library (".a") are available for linking. In this case, the client model would not generate the code but would require a location where the sources or library can be found (workspace reference?) so that it can be reference by a make file. Thoughts?
(In reply to Charles Rivet from comment #3) I agree that this should be specified by the transformation configuration. Is there a document somewhere describing everything that the transformation configuration needs to specify? If not, perhaps we should start one. > I think what we need is actually a combination of options. > > I agree that Option #1 makes sense in some cases, but not all. As Peter > rightly points out, this option fails in some (potentially large) > distributed development and build environment. > > I'm not sure about about the difference between options #2 and #3. Instead, Option 2 means we generate the code for external elements. Option 3 means someone else generated that code (or is written manually). > let me define #4 and #5, below. > > If the code is generated elsewhere, there are two cases to consider: > > 4) the model library is just a (potentially incomplete) representation of > the actual "linkable" library, similar to what we have done for the RTS > library. > > In such a case, the library only exists so that its element can be used > within and referenced from the the client model, but code generation should > never happen since the code is provided in another form. We would then need > a way to state that this library should not be generated and provide a > location where it can be found (workspace reference?). This is already taken care of. The code generation does not generate code for elements from the model library. > 5) The library is actually fully generated from another Papyrus-RT UML-RT > model. > > In contrast to the case above, the mode for this library is being used for > code generation and either objects (".o") or library (".a") are available > for linking. In this case, the client model would not generate the code but > would require a location where the sources or library can be found > (workspace reference?) so that it can be reference by a make file. > Thoughts? I assume that in this case you mean that we generate the model library only once (per release, that is). Otherwise, generating it with each model would be wasteful. I understand this alternative as a kind of bootstrapping. The generated code in this case would replace the hand-written code (by Barry and Andrew). Are there any benefits in doing this? In any case, the original post was meant to address "really external" elements, elements from other models, packages and libraries. I think of our RTS library as being, in some sense, built-in, rather than external. So to me #4 and #5 are orthogonal issues.
(In reply to Ernesto Posse from comment #4) > Option 2 means we generate the code for external elements. Option 3 means > someone else generated that code (or is written manually). OK. This wasn't clear from the description for option 2 ("generated elsewhere") > > > let me define #4 and #5, below. > > > > If the code is generated elsewhere, there are two cases to consider: > > > > 4) the model library is just a (potentially incomplete) representation of > > the actual "linkable" library, similar to what we have done for the RTS > > library. > > > > In such a case, the library only exists so that its element can be used > > within and referenced from the the client model, but code generation should > > never happen since the code is provided in another form. We would then need > > a way to state that this library should not be generated and provide a > > location where it can be found (workspace reference?). > > This is already taken care of. The code generation does not generate code > for elements from the model library. Granted, but that is the one we distribute. What about other model libraries provided by either user or third-party vendors? I am discussing a more general scenario. > > > 5) The library is actually fully generated from another Papyrus-RT UML-RT > > model. > > > > In contrast to the case above, the mode for this library is being used for > > code generation and either objects (".o") or library (".a") are available > > for linking. In this case, the client model would not generate the code but > > would require a location where the sources or library can be found > > (workspace reference?) so that it can be reference by a make file. > > > Thoughts? > > I assume that in this case you mean that we generate the model library only > once (per release, that is). Otherwise, generating it with each model would > be wasteful. The model library would be generated on its own schedule depending on required changes. The number of generation could be multiple by release or even once for multiple releases. I don't see how the frequency of update is relevant to this discussion on how to refer and incorporate the library's artifacts in the build. > I understand this alternative as a kind of bootstrapping. The generated code > in this case would replace the hand-written code (by Barry and Andrew). Are > there any benefits in doing this? That was not my intent when I wrote this. I did not mean to replace anything in code generation or runtime. This is just a way of "linking" (used in a broad way) common libraries, possibly build from Papyrus-RT, to a Papyrus-RT system. > In any case, the original post was meant to address "really external" > elements, elements from other models, packages and libraries. I think of our > RTS library as being, in some sense, built-in, rather than external. So to > me #4 and #5 are orthogonal issues. I disagree. Unless you exclude user-created or third-party libraries (model-generated or not).
OK, I see. It was not clear to me that you were talking about third-party model libraries, as your original post talked about "the" model library, rather than "a" model library. Yes, in the general case, your options 4 and 5 are relevant and related, but I would say there is still something different. Options 4 and 5 are about model libraries, which as you say, would be generated "in their own schedule", rather than with the model being generated. Options 1-3, as I originally thought, are about model elements which are not library elements. Simply elements that belong to some other model or package. In that case, the options still stand. Do we generate them? Do we assume they are generated elsewhere by someone else?
(In reply to Ernesto Posse from comment #6) > ... Options 4 and 5 are about > model libraries ... Option 4 is about a library that has a model representation (like our runtime), and therefore needs to be "imported" into another model for it to use the its constructs as part of the modeling exercise (i.e., outside of opaque expressions). Such a model library could have been used to generate its code or could just refer to existing code (like the runtime library vs. the actual runtime. Option 5 is about a library that does not need a model model library, such as either a library archive (e.g., ".a") or a set of objects (e.g., ".o"). The generation method is unspecified. The generation manner doesn't matter in this case. The code could have been model-generated (e.g., from an API generator) or it could have been hand-generated. There is no "model library" associated with this (think 3rd party C++ library). This case may need a representation in the model for traceability purpose, e.g., represented by an "artifact". If it does not need a representation, there would still be a need to specify how its code would be incorporated in the build. > ... In that case, > the options still stand. Do we generate them? Do we assume they are > generated elsewhere by someone else? Yes, the options still stand (which is why I numbered my addition starting at 4). And I did not address whether they should be generated or not in all cases. Some cases are obvious, others are not. I just added two scenarios (sorry...). I think we need to make sure we define the right scenarios to be able to make good decision as to whether they need to be generated or not, and not have a "it depends" answer, e.g., focus on usage so we can better understand the applicable solutions.
Does not gate the June release 1.0 Papyrus-RT release
This is currently assigned to "MVP3" in the product plan.
This is (either partially or completely) addressed by the work planned for MVP3 (build it and they will come). The discussion in this bug is useful, but long - a summary of the approach taken must be provided. Moving to 0.9.0 so a solution can be defined and elaborated. Revisit this bug's milestone assignment once a solution is proposed (e.g., assigned to MVP3's release if everything can be done as part of the transformation and build configuration).
This is rather comprehensive area, including the aspect of something similar to the transformation configuration files in the legacy tooling. I am not sure that we will have the time to dig into the details of this for 0.9 release. Since this is part of MVP3, I suggest that a plan is made for some workshop or similar where we can focus on discussing the multitude of aspects that must be considered when it comes to multi-models, multi-projects, sub-models, and how such large models are supposed to be code-generated and built/compiled/linked. As discussed in other bugs, I suggest that we limit the code-generator to focus only single-models for 0.9.0. Probably this should also be made clear in some release notes regarding limitations to single-model code-generation and building. Can we re-plan this for something else than 0.9.0?
(In reply to Peter Cigehn from comment #11) > This is rather comprehensive area, including the aspect of something similar > to the transformation configuration files in the legacy tooling. I am not > sure that we will have the time to dig into the details of this for 0.9 > release. Since this is part of MVP3, I suggest that a plan is made for some > workshop or similar where we can focus on discussing the multitude of > aspects that must be considered when it comes to multi-models, > multi-projects, sub-models, and how such large models are supposed to be > code-generated and built/compiled/linked. > > As discussed in other bugs, I suggest that we limit the code-generator to > focus only single-models for 0.9.0. Probably this should also be made clear > in some release notes regarding limitations to single-model code-generation > and building. > > Can we re-plan this for something else than 0.9.0? Absolutely. Reading this whole bug again, I also think we need to further break down MVP3 into more achievable goals for 1.0 (on Oxygen). I'll put something together in the next couple of week and send out for review and comments...
(In reply to Charles Rivet from comment #12) > Absolutely. > > Reading this whole bug again, I also think we need to further break down > MVP3 into more achievable goals for 1.0 (on Oxygen). I'll put something > together in the next couple of week and send out for review and comments... Did you forget to update the Target Milestone field for this bug, or did you plan to do that later? It is still planned for 0.9.0.
Moving from assigned to new as there is no assignee...yet.
I see that this one was assigned to Ernesto. I am not sure what the scope of this bug will be, but may I suggest that this is also a candidate for bringing out of 1.0. I am not sure that we will be able to take the aspects of multi-models, including the building aspects (including something similar to the transformation configuration files in the legacy tooling) into consideration for 1.0 either, as indicated already in Comment 11. Or do we plan on having such a work-shop prior to 1.0 were we more focused can discuss the multitude of aspects to consider in this area? Since we have MVP3 with a focus on building, I suggest to also make a limitation that 1.0 is only supporting single-models, and that support for multi-models will be part of MVP3 (and future).
Moving to Future as suggested by Peter and agreed by Simon.
Option 1 is already supported. So the remaining, complicated cases for multi-models are left for Future.
