Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [papyrus-rt-dev] Papyrus-RT Build Problems — Blocked

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.uml
Comparing 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?



Back to the top