TASTE bugtrack - Taste
View Issue Details
0000662Taste[All Projects] Orchestratorpublic2017-07-27 09:322022-12-06 12:30
normalfeaturehave not tried
0000662: Support additional processor properties during the build
ocarina/resources/AADLv2/components/processors/*.aadl files contain the description of the supported processors. New properties are added: Deployment::CFlags Deploument::LDFlags Deployment::ENV allowing to define platform-specific flags and environment variables They must be parsed by buildsupport, forwarded to the orchestrator (to avoid platform-based switch-cases there) and further processed for all compilation activities.
No tags attached.
Issue History
2017-07-27 09:32maximeNew Issue
2017-07-27 09:32maximeStatusnew => assigned
2017-07-27 09:32maximeAssigned To => ttsiodras
2017-09-15 13:32ttsiodrasNote Added: 0002998
2017-10-11 12:44maximeNote Added: 0003044
2017-10-13 07:58huguesNote Added: 0003046
2018-05-13 15:54maximeNote Added: 0003323
2018-05-13 15:58huguesNote Added: 0003324
2018-05-13 20:00maximeNote Added: 0003325
2018-05-14 12:35ttsiodrasAssigned Tottsiodras => hugues
2022-12-06 12:30maximeNote Added: 0003822
2022-12-06 12:30maximeStatusassigned => resolved
2022-12-06 12:30maximeResolutionopen => fixed
2022-12-06 12:30maximeStatusresolved => closed

2017-09-15 13:32   
Using the "nodes" file that the orchestrator already parses for the ENV parts.
2017-10-11 12:44   
The three properties are now parsed by buildsupport and propagated to the "nodes" files the orchestrator is processing the EnvVars property Remaining to be done: USER_CFLAGS and USER_LDFLAGS
2017-10-13 07:58   
Note that Ocarina now supports USER_CFLAGS, USER_LDFLAGS and USER_ENV, all defined in resources/deployment.aadl in Ocarina GitHub master branch. The accessors for these properties are defined in src/backend/ocarina-properties.adb See https://github.com/OpenAADL/ocarina/issues/110 [^] https://github.com/OpenAADL/ocarina/issues/95 [^] I let you decide whether you want to use the same property for env variable.
2018-05-13 15:54   
We also need Default_Stack_Size per target
2018-05-13 15:58   
Stack_Size (default property) already applies to processor Source_Stack_Size: Size applies to (thread, subprogram, processor, device); Stack_Size: Size applies to (thread, subprogram, processor, device); So you can already apply Stack_Size to processor (aka the target) But, for the moment, we only check for thread, we may add a fall back mechanism: if not set for thread, look for processor the thread is bound to and use this value. What do you think ?
2018-05-13 20:00   
Yes, if you do that, then I'll remove the value setting from Buildsupport and let you use the default value when you create the threads. Good idea.
2022-12-06 12:30   
All these properties were added.