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

[alby.gamper@gmail.com]

On Friday, May 3, 2019 at 9:53:00 PM UTC+10, alby....@gmail.com wrote:
> 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

Sorry, I submitted this reply before I was ready to post, Anyway Continuing on

   the clean target should work fine (this step is NOT really required, but I
   just want to make sure the expected targets are working as expected.)

f) msbuild -target:build

   this will do a build, and should be the same as the compile/bind phase in
   point a) and b) above and the try and do the steps 5) and 6) mentioned above

g) Please check all /LIBPATH command line options in the LINK target, and report
any unusual errors in using MSBUILD (except that you may see a error regarding
not being able to find MSVCRT.LIB (I believe this is a false positive as I can
build fine using VS)


Thanks

Alex