| Re: [papyrus-rt-dev] Papyrus-RT Build Problems — Blocked |
Hi Ansgar. I assume that the library is still at org.eclipse.papyrus.cpp.profile at this moment, is that correct? Our codegen build is working now, so it must be there.Let me know when you remove it from papyrus.cpp.profile so I can update our code generator to use the one at org.eclipse.papyrus.designer.languages.cpp.library.Thanks.On Wed, Apr 6, 2016 at 9:00 AM, 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
--Ernesto PosseZeligsoft.com
_______________________________________________
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