[great-users] FW: Visual Studio project Templates and group operator bug

[Kevin Smyth]

1. Unfortunately, the templates for the input to the tool that produces 
the .vcproj are embedded as resources in the GReAT executables. So it is 
not easy for end users to modify them. But I will add /bigobj and /MP to 
the templates. I'll think about adding a more general solution. Maybe we 
should add an attribute to UserCodeLibrary where you can specify a 
.props file (or the VS2008 equivalent).

2. I agree these are bugs, and I will fix them. The component 
responsible for this behavior is the add-on "UMTHelper", not the decorator.

The new behavior for connecting a Group: if you add a connection, it 
will not be immediately deleted (like it was trying to do), but if you 
modify the Group's GroupAction, it will delete the connection if the 
action is Bound or Delete. I believe this is the desired behavior, but 
if you think it should do something else, please let me know.

The crash is a bug in GME that I will fix, but the crash will not be 
triggered after the changes to the GReAT addon.


Thanks for the good bug reports.

Kevin

On 10/15/2014 9:21 AM, Daniel Balasubramanian wrote:
>
> -----Original Message-----
> From: Simon Görke [mailto:simon.goerke at ils.uni-stuttgart.de]
> Sent: Wednesday, October 15, 2014 7:58 AM
> To: great-users-bounces at list.isis.vanderbilt.edu
> Subject: Visual Studio project Templates and group operator bug
>
> Hi everybody,
>
> I would like to report two minor GreAt issues. Both can be avoided, however they unnececessarily complicate our every-day work with the tool.
>
> 1. Visual Studio project files (*.vcproj):
> With one of our rules, VS requires us to set the /bigobj switch for successful compilation (background:
> http://msdn.microsoft.com/de-de/library/ms173499.aspx).
> The VS projects generated by GreAt do not set this switch, so we have to set it manually after each generation. Consequently, we can not make the build process for this rule part of our continuous integration environment (Jenkins).
> Would it be possible to set the option in the GreAt-internal template? As far as we know, there are no negative implications apart from missing VS2005 compatibility (which is not supported by GreAt anyway?).
> As a nice-to-have, compilation time could be widely reduced by enabling the multi-processor switch (/MP) in the VS-project (currently a complete rebuild takes ~45min with 3 of 4 cores idling... I do not know about VS-backwards compatibility here however).
>
> 2. Some of our rules make have use of the group operator. There are two bugs in the GreAt decorator which - I hope - could be easily fixed, but sometimes make modelling a pain:
>   1st, when copying a rule containing a group operator, the "criteria for grouping"-attribute is lost, i.e. it is not copied, but set to default. As the default text contains an unconditioned positive return instruction, this causes misbehaviour which can not be detected at compile time.
> This problem seems to be a regression as older versions (which did not fill in default code) did not show this behavior.
> The 2nd thing is also connected to the decorator: when drawing a connection from a group to another FCO (for copy / move), GME crashes if the GroupAction-attribute is set to "bound". This is especially annoying, as the latter is the default value -> one has to strictly follow the sequence "create group", "modify attribute", "connect" (and not reverse).
>
> It would be nice if someone could give as a hand here. I tried to fix the first one on my own, but did not find the vcproj template within the GreAt sources.
> If generally setting the flags is not an option, maybe you could point me to the right spots in the code and help me build our individual GreAt version.
>
> Thanks in advance,
> Simon
>
>
> _________________________________________
>
> Dr.-Ing. Simon Görke
> Institut für Luftfahrtsysteme (ILS)
> Universität Stuttgart
> Pfaffenwaldring 31
> 70569 Stuttgart (Vaihingen)
> Tel.: +49 (0)711 685-64715
> Fax: +49 (0)711 685-63591
> Email: simon.goerke at ils.uni-stuttgart.de
> URL: http://www.ils.uni-stuttgart.de
>
>