| Re: [papyrus-rt-dev] Move of the AnsiCLibrary |
Hi Peter,
the first release of designer is planned for Friday morning.
I talked to Francois (in CC) who knows build issues much better than I do: I understand that it is possible to declare additional repositories in the Papyrus-RT update site configuration. These are searched automatically when the user installs Papyrus-RT. I.e. the user does not have to add further update sites manually.
Thus, the main issue is an additional configuration in the build/update site of Papyrus-RT. While it may seem a certain additional effort for a small library, it will keep the possibility open to have more common code in the future (e.g. the reverse mechanisms)
The two alternatives are (1) keeping a separate copy (that might involve independently) and (2) keeping the Ansi C library in the Papyrus repository (and remove it from designer). Both options are in my opinion less good.
Best regards
Ansgar
On 06/04/2016 15:48, Peter Cigéhn wrote:
Hi,
When being reminded about the move of the C++ code generator from Papyrus Extras to its own repository, I wonder about move in p2 repos.
As discussed before, we did not want that end-users of Papyrus-RT should be forced to bring along anything else than the AnsiCLibrary itself. But if we now move the C++ code-generator into its own repo, do that mean that we also will move stuff into separate p2 repos?
As it has been so far, is that the plugin with the AnsiCLibrary has been installed "for free" since the user simply used the aggregated apyrus repo (which included both Maind and the Extras repos). But if we now move stuff into own repositories, do that also impact this?
Will we be forced into having an additional p2 repo, just for the purpose of getting in the AnsCLibrary? If that is the case, then maybe the placement of the AnsiCLibrary could be questioned.
Ansgar, can you please enlighten us regarding this so that we understand the conseqeunces from an end-user perspective installing Papyrus-RT directly from p2 repos.
/Peter Cigéhn
On 6 April 2016 at 15:00, Ansgar Radermacher <ansgar.radermacher@xxxxxx> wrote:
Hi Peter, Hi Christian,
as Peter already stated, there should be no dependency on the CEA C++ profile, but only on the library. We were quite careful that this library does not depend on the code generator. The library itself does not even depend on Papyrus. A separate library.ui plugin registers the library with the Papyrus extension point.
Please note that we are about to remove the C++ library from the extras plugins for neon, as tracked in Bug 486820 (if it wasn't for merge problems this would already have been done). The C++ library is now in a separate repository (org.eclipse.papyrus-designer) and is called org.eclipse.papyrus.designer.languages.cpp.library.
Please tell me, if we should delay the deletion.
Best regards
Ansgar
On 06/04/2016 14:39, Christian Damus wrote:
Hi, Peter,
I imported the C++ extra from the Papyrus setup in an attempt to get that model library. Anything else that it brought in would be incidental. I don’t actually know that anything else is required; I didn’t mean to suggest that, sorry.
BTW, I’m trying my Gerrit patch again with the ComputerSystem model commented out of the codegen test case, tracked by bug 491150.
cW
On 6 April, 2016 at 08:28:04, Peter Cigéhn (peter.cigehn@xxxxxxxxx) wrote:
_______________________________________________Hi,
I get a bit confused about these dependencies to the C++ code-generator in Papyrus Extras. Earlier when we decided which C++ primitive types library that should be used, some refactoring was made to reduce the dependencies, and ensure that the plugin containing the AnsiCLibrary (which was the library decided to be used for Papyrus-RT) was "stand-alone", and that it should not bring along any additional stuff from the C++ code generator in Papyrus Extras (since we want to avoid those dependencies, users of Papyrus-RT should not have to install any of the other stuff from the C++ code-generator in Papyrus Extras).
Please not also that it should *only* be the AnsiCLibrary that we shall depend on (in the org.eclipse.papyrus.cpp.profile plugin), and not the C++ profile. For Papyrus-RT it should only be the RTCppProperties profile that shall be used to control the generated C++ code from Papyrus-RT.
But maybe the dependencies you are talking about here is only within a developer workspace, and not the final dependencies between the resulting plugins.
/Peter Cigéhn
On 6 April 2016 at 14:19, Christian Damus <give.a.damus@xxxxxxxxx> wrote:
Well, I do feel silly. All the logging that we need is already there; I just wasn’t looking in the right place in the build logs.
There appears to be confusion in the generated code between pointer types (see below, the lines starting with “>>"). Could it be that these are due to changes in the C++ Codegen Profile from the Papyrus Extras? But that’s just a guess. Perhaps Ansgar can shed some light on it.
So, for now, we’re stuck again.
cW
Running org.eclipse.papyrusrt.codegen.cpp.test.codecompare.CodeGenCompareTest Testing PingPong.umlComparing PingPongProtocol.hh Comparing Top-connections.log Comparing PingPongProtocol.cc Comparing TopControllers.hh Comparing TopMain.cc Comparing TopControllers.cc Comparing MakefileTop.mk Comparing Makefile Comparing Top.hh Comparing Pinger.hh Comparing Pinger.cc Comparing Ponger.hh Comparing Top.cc Comparing Ponger.cc Testing ComputerSystem.uml Comparing ComputerSystem.cc Comparing Top-connections.log Comparing ResourceType.cc Comparing USBDeviceClasses.hh Comparing AppType.cc Comparing USBPrinterDriver.cc Comparing Application.hh Comparing LocalPrinter.cc >> #define umlrtparam_data ( *(const void * *)msg->getParam( 0 ) ) :: #define umlrtparam_data ( *(const void * * *)msg->getParam( 0 ) ) Comparing ResourceManager.cc Comparing AppControl.hh >> UMLRTOutSignal docID( int docID ) const; :: UMLRTOutSignal docID( void * docID ) const; Comparing ComputerSystem.hh >> bool initStatus; :: void * initStatus; Comparing Resource.hh Comparing TopControllers.hh Comparing Computer.hh Comparing User.cc Comparing ResourceManager.hh >> int printerRequestCount; :: void * printerRequestCount; Comparing USBDeviceClasses.cc Comparing ResourceType.hh Comparing AppControl.cc >> char * fileName; :: void * * fileName; Comparing USBDeviceDriver.cc Comparing TopMain.cc Comparing TopControllers.cc Comparing OSCommand.cc Comparing MakefileTop.mk Comparing USBProtocol.cc >> sizeof( void * ), :: sizeof( void * * ), Comparing USBPrinterDriver.hh Comparing WordProcessorApp.hh >> char * document; :: void * * document; Comparing Makefile Comparing USBStorageDriver.cc Comparing Top.hh Comparing USBProtocol.hh >> UMLRTOutSignal data( void * data ) const; :: UMLRTOutSignal data( void * * data ) const; Comparing LocalPrinter.hh >> bool connectionStatus; :: void * connectionStatus; Comparing User.hh >> int numSec; :: void * numSec; Comparing Computer.cc Comparing AppType.hh Comparing OSCommand.hh Comparing USBErrorCodes.hh Comparing USBErrorCodes.cc Comparing Top.cc Comparing Application.cc Comparing USBDeviceDriver.hh >> int busID; :: void * busID; Comparing ExtMassStorage.hh >> bool connectionStatus; :: void * connectionStatus; Comparing WordProcessorApp.cc >> #define umlrtparam_percent ( *(int *)msg->getParam( 0 ) ) :: #define umlrtparam_percent ( *(const void * *)msg->getParam( 0 ) ) Comparing USBStorageDriver.hh Comparing Resource.cc Comparing ExtMassStorage.cc >> #define umlrtparam_data ( *(const void * *)msg->getParam( 0 ) ) :: #define umlrtparam_data ( *(const void * * *)msg->getParam( 0 ) )
On 6 April, 2016 at 08:10:14, Christian Damus (give.a.damus@xxxxxxxxx) wrote:
Thanks, Ernesto,I’ll see whether I can’t add some logging of comparison failures in the test. Shouldn’t be difficult.
Did you also select the top-level Papyrus project for import? You need that at a minimum, and you don’t need the Infra/Views/UML in your workspace because they will be in the PDE Target. But, codegen does need stuff from the Papyrus Extras, namely the C++ Codegen feature. So try importing also that project from the Oomph setup. IIRC, it’s not actually completely self-contained, so you will additionally need to pull in some more from the Papyrus git repo (C++ profile, I think, and probably some base Qompass bundles).
Also, of course, you’ll need the latest Xtext SDK for Xbase and other bits.
I’m working on an Oomph setup model for developers for Mars and Neon in Gerrit 68693 but that can’t actually be completed until we have Neon builds of Papyrus-RT published, because the setup needs to be able to install those.
HTH,
Christian
On 5 April, 2016 at 17:30:14, Ernesto Posse (eposse@xxxxxxxxxxxxx) wrote:
Hmmm... Strange that your manual generation won't match the automated one.
Unfortunately there is no simple way to determine the diffs, as far as I know. This test is in 'org.eclipse.papyrusrt.codegen.cpp.test' (under tests/junit/umlrt/codegen) in 'codecompare.CodeGenCompareTest'. Young-Soo wrote this, and looking at the source, it only reports file names. I think the only option is a manual diff.
Maybe using the Eclipse-based generator will produce the correct expected sources.
Alternatively, we could temporarily comment-out lines 43-45 in CodeGenCompareTest.java, which would disable the tests.
I can try to help figuring this out, but I'm having trouble with my Neon setup. I get a lot of errors on the tooling projects. So I started with a fresh installation and the Papyrus Oomph setup, but after importing the Infra, Views and UML components I get errors in most projects. Is there a component that I need to select in Oomph to install besides Infra, Views or UML?
_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
_______________________________________________ papyrus-rt-dev mailing list papyrus-rt-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
-- Ansgar Radermacher CEA/DRT/DILS/LISE http://www-list.cea.fr/index.htm phone: +33 16908 3812 mailto: ansgar.radermacher@xxxxxx
_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
_______________________________________________ papyrus-rt-dev mailing list papyrus-rt-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
-- Ansgar Radermacher CEA/DRT/DILS/LISE http://www-list.cea.fr/index.htm phone: +33 16908 3812 mailto: ansgar.radermacher@xxxxxx
_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev