Re: ANN: VisualAda (Ada Integration for Visual Studio 2017 & 2019) release 1.1.12

[alby.gamper@gmail.com]

On Thursday, May 2, 2019 at 2:45:37 AM UTC+10, Greg wrote:
> Alex,
> 
> ABSOLUTELY no worries. I switched over to MSYS2 because that was what you were using. My personal preference is GNAT CE, but either way is fine. No rush at all, I never thought I'd be able to do something like WinRT or UWP/XAML in Ada (and I'm trying to relearn Ada, a lot has changed since I took classes and monkeyed with it in the 80's!).
> 
> The reason my project is called "RaceDirector" is because I'm rewriting all of our timing & scoring software (and adding some hardware, like the STM32F769NIH6 microcontroller (embedded Ada!)) for our Soap Box Derby track (if you're curious, http://ghsbd.org). I thought it'd be a cool way to do it.
> 
> 
> We're done with our Spring events, and won't start up again until late Summer, early Fall (too !*&@# hot in Texas during the summer.)
> 
> Side note: I'm assuming that since these are true Windows Store apps, that they could also run on Xbox, but its been a while since I messed around with that. I'd love to explore that as well (I also occasionally write some small apps for my autistic teenager to help him in a few areas.)
> 
> Let me know how I can help, test, maybe add some stuff to the extension (Intellisense ?), whatever.
> 
> Regards,
> Greg

Hi Greg

Your RaceDirector software sounds like an excellent candidate for the "Make with Ada competition" sponsored/run by AdaCore.
Not sure about Xbox integration, but when I get some spare time I'll look into it.

Now onto your original problem. Firstly some background info, which will help us
in finding the root cause of build failure. The VisualAda extension works as follows.

1) When you create a new project, a .vcxproj is created from a project template supplied by the VisualAda extension

2) This .vcxproj is essentially a C/C++ project, primarily because it has a compile AND link phase/target, unlike C# or VB, and I needed the link target for UWP apps

3) The .vcxproj has additional targets to comply with the normal Ada build procedure (ie compile, BIND and link)

4) The MSBUILD engine is used to co-ordinate the build, and invokes specific
targets that end up calling GPRBUILD with either the -c (compile), -b (bind)
or -l (link) command line options.

5) if building UWP/WinrRT based apps, then the final GPRBUILD link is replaced
by a Microsoft linker command

6) If the project "property Use Microsoft Linker" is set to YES (as is the case for
UWP/WinRT based projects) then their is an intervening step between the BIND and
Microsoft LINK phase which converts the GCC dwarf based debug information into
PDB format, so that you can debug the final app using Visual Studio.

7) Note: An equivalent GPR file (to that of the above .vcxproj) is maintained
and re-generated when ever changes to the .vcxproj file are made.

Ok, with that knowledge in hand, lets try and isolate the build failure with the
following, using a VS x64 native command prompt, since this gives us a bit more
flexibility in running individual phase/targets in the build process.

(note I made some minor changes on GitHub, so you may want to do a git pull for
the winrt-runtime project, But I am not entirely convinced that these changes
ae the root cause) 

a) cd into the directory where your <project>.gpr file exists

b) gprbuild -f -c -p -aPC:\msys64\mingw64\lib\gcc\x86_64-w64-mingw32\8.3.0\rts-Winrt_Runtime\share\gpr -P <project>.gpr

   this will only do the compilation phase, and should succeed, NOTE I am using
   the default MSYS2 install directories above in the -aP argument, which just
   tells GPRBUILD additional Project directories

   You should see the usual GPRBUILD compile phase output at this stage

c) gprbuild -f -b -p -aPC:\msys64\mingw64\lib\gcc\x86_64-w64-mingw32\8.3.0\rts-Winrt_Runtime\share\gpr -P <project>.gpr

   This will then do the bind phase, and should succeed. If this fails, then
   please re-run, but ADD a -vh flag to the gprbuild cmd (ie gpbuild -vh -f …)
   this will give us some additional diagnostics that we can work with

d) If you got this far great, that means gcc/gnat is fine and we need to dig a
bit further. But now since gcc/gnat is out of the picture we need to use the
MSBUILD to diagnose the rest of the build cycle.

e) msbuild -target:clean