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

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

[alby.gamper]

Dear Ada Community 

VisualAda version 1.2.0 has been released 

New Features, fixes include the following 

- Added compiler switches syntax checking, symantic checking, code page and wide character set encoding
- Fixed bug - some compiler options were not set in GPR file, even though they were set in the vcxproj file
- Dynamically determine Target when creating new projects. Supported Targets are currently (Win32 -> i686-- and x64 -> x86_64--). ARM Targets will be forthcoming.
- Check validity of determined Target when building a project, for example the Target could have be set to a specific gcc triplet, blank or 'Unknown'. Resulting in either a info, warning or error message respectively.
- Dynamically determine root directories for each target when creating new projects (only applicable to projects that rely on the Microsoft Linker, such as Winrt/UWP based applications)
- Fixed bug - Msbuild failures caused by inadvertent references to VS 2015 dll's

Please feel free to download the free plugin from the following URL 

https://marketplace.visualstudio.com/items?itemName=AlexGamper.VisualAda 

Note: 

if you have issues with installation, please respond to this post, and I will 
endeavour to resolve as soon as possible. In the long term I intend to setup 
a specific GitHub project, where issues/improvements can be made for me to action. 

Thanks 

Alex 

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

[Greg]

Alex, oh, you're going to hate me, but not far off... seems to be just a UWP packaging thing.

This is what I did:

ON BOTH VS2017 and VS2019:
1. Uninstalled VisualAda 1.1.12 
2. Installed Visual Ada 1.2.0 

WINRT:
3. Did a fresh git clone of Ada-WinRt-Runtime and Ada-WinRT.
4. Made changes to both GPR files for BASE_INSTALLATION_DIR - in my case, "C:\msys64\mingw64\lib\gcc\x86_64-w64-mingw32\8.3.0\"
5. Built Ada-WinRt-Runtime with "Build.cmd" (you have to do the 2 link steps, README.md should be updated to reflect using "Build.cmd" for this project as well ?)
6. Build Ada-WinRt with "Build.cmd"
Success, looks like they're in the right place.

VS2017:
7. Created a new "Race1" XAML project and chose Debug/x64 configuration.
8. GNAT paths point to correct C:\MSys64 locations.
9. Interestingly, if I do a "Rebuild" straight away, I get this:

-----------------------------------
Ada.targets(175,5): error MSB4018: The "CompileTask" task failed unexpectedly.
Ada.targets(175,5): error MSB4018: System.IO.FileNotFoundException: Could not find file 'C:\home\dad\dev2\Race2\Race2Xaml\bin\x64\Debug\Race2Xaml.winmd'.
Ada.targets(175,5): error MSB4018: File name: 'C:\home\dad\dev2\Race2\Race2Xaml\bin\x64\Debug\Race2Xaml.winmd'
Ada.targets(175,5): error MSB4018:    at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
Ada.targets(175,5): error MSB4018:    at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare shar
Ada.targets(175,5): error MSB4018:    at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share)
Ada.targets(175,5): error MSB4018:    at System.IO.File.OpenRead(String path)
Ada.targets(175,5): error MSB4018:    at Winmd2Ada.Program.ConvertWinmd2Ada(String ArgsWinmd, String ArgsDir, Boolean WinRt, Boolean Core)
Ada.targets(175,5): error MSB4018:    at Ada.CompileTask.Execute()
Ada.targets(175,5): error MSB4018:    at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
Ada.targets(175,5): error MSB4018:    at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext()
-----------------------------------

10. However, doing a "Build" from there kicks it off just fine.
11. Get through compilation and binding and then this:

-----------------------------------
1>Bind
1>   [gprbind]      race1.bexch
1>   [Ada]          race1.ali
1>Race1.vcxproj -> C:\home\dad\dev2\Race1\Race1\x64\Debug\Race1.exe
1>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Microsoft\VisualStudio\v15.0\AppxPackage\Microsoft.AppXPackage.Targets(2780,5): error APPX0702: Payload file 'C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\System.ServiceModel.Http\4.1.3\lib\netcore50\System.ServiceModel.Http.dll' does not exist.
1>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Microsoft\VisualStudio\v15.0\AppxPackage\Microsoft.AppXPackage.Targets(2780,5): error APPX0702: Payload file 'C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\System.ServiceModel.NetTcp\4.1.3\lib\netcore50\System.ServiceModel.NetTcp.dll' does not exist.
1>Done building project "Race1.vcxproj" -- FAILED.
-----------------------------------

But I bet I can get this one before you can :-)

Greg

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

[Greg]

C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\System.ServiceModel.Http\4.1.3\lib\netcore50 does not exist.

Checking the VS installer to see what I could be missing...

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

[Greg]

Ah, so this is a Windows Store framework (netcore50).

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

[Greg]

"FIXED" IT!

This probably needs to be looked at, but I copied each of the 2 "netcore50" folders from NuGetPackages to the appropriate folders under UWPNuGetPackages, it linked and is now running! Woo-hoo !!!

Greg

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

[alby.gamper]

On Monday, May 6, 2019 at 2:58:20 AM UTC+10, Greg wrote:
> "FIXED" IT!
> 
> This probably needs to be looked at, but I copied each of the 2 "netcore50" folders from NuGetPackages to the appropriate folders under UWPNuGetPackages, it linked and is now running! Woo-hoo !!!
> 
> Greg

Hi Greg

Thanks for the feedback, and glad to see that its now building fine, I'll
make the following changes to ease the use of the UWP templates within ViaualAda

1) Add documentation for the Winrt_runtime and winrt build procedures (something
that I should have dome earlier)

2) Add documentation to both of the above projects to configure the gpr files
for specific compilers/targets

3) The build failure in point 9) above is caused by the <app> project having a
dependency on the <app>xml project (something that I believe cant be specified in
the project template ?) Not sure how to fix this other than showing a readme.txt
file upon project creation, which indicated this dependency and instructions on
how to setup.

4) The <app>xml project references an old version of nuget package UWP runtime
and needs to be updated to reflect the current WinRT Ada bindings (ie 19H1/1903)

5) The <app>xml project also needs to specify a more recent TargetRuntime (its 
currently set to 10.0.14393.0, which is very old, and needs to reflect runtimes
supported by default VS2017/2019 installations ? I'll need to investigate this !

Is their anything else that I can do/document to make things easier ? I am sort
of working in a vacuum wrt changes, But I do eat my own dogfood so to speak and
have so far made changes to suit my requirements and hence someone else's view
would be great

Thanks

Alex
I hope to have this release (1.2.1) soon

Alex

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

[Greg]

Alex, sorry, been hammered with deadlines and too tired at night to even look at a screen.

1) and 2) would go a long way to helping others starting down this path, and that's the point, at least from my perspective. Everyone talks about promoting the language, and to me, this is one of the more outstanding ways I've seen.

3) I can't believe you can't set dependencies as you say, but who knows, you might be right. If not, a mention in the README should certainly be sufficient.

4) Figured something like that.

5) I did monkey around with changing the target runtimes myself to more recent ones, but didn't seem to make much difference, but defaulting to more recent ones is definitely the way to go.

I guess just emphasizing that you HAVE to build THIS and THIS first (the WinRT stuff) before using Visual Ada, you know, step A, B, and C - as you said, would help a lot. 

I suppose I could start doing PRs for documentation suggestions or other issues of course, on the WinRT stuff. When/if VisualAda goes to GitHub, same thing.

I'm just having fun doing this, and hey, anything I can do to help. I have absolutely no need for GtkAda, and doing a Windows app in Ada is still to me  mind-blowing.

I did try to build a UWP DLL the other day and ran into an error, can't remember what it was exactly, but when I get a chance, I'll pass along the details.

I strongly suspect deploying a VisualAda UWP app to Xbox WILL work, just haven't had the chance to set it up yet. But will soon.

Again, thanks for all of this incredible work,
Greg

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

[Greg]

Alex,

1. Here's a tiny one ... can you default the build config in VS to x64 instead of x86, since it's not ready yet, and I'm too stupid to remember to change it every time I create a test project ;-).

2. The error I get when building a UWP DLL is:
../ld.exe: cannot find -lgnat-8

I should be able to figure that one out.

Thanks,
Greg

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

[alby.gamper]

On Thursday, May 9, 2019 at 7:57:21 AM UTC+10, Greg wrote:
> Alex,
> 
> 1. Here's a tiny one ... can you default the build config in VS to x64 instead of x86, since it's not ready yet, and I'm too stupid to remember to change it every time I create a test project ;-).
> 
> 2. The error I get when building a UWP DLL is:
> ../ld.exe: cannot find -lgnat-8
> 
> I should be able to figure that one out.
> 
> Thanks,
> Greg

Hi Greg

1) It also annoys me to no end that the default is x86 as well !!, and I also
struggle to remember to change it. Which is why I put in the MSBUILD warning/error
if VisualAda cant find a compiler/toolchain for the VS "Platform"

I did fix it at one point, but then I got other unrelated errors/warnings, so I
pulled the change out. I'll revisit when I get a chance

2) Let me check this, Its probably an issue with the project template ?

Alex

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

[alby.gamper]

On Thursday, May 9, 2019 at 7:20:14 AM UTC+10, Greg wrote:
> Alex, sorry, been hammered with deadlines and too tired at night to even look at a screen.
> 
> 1) and 2) would go a long way to helping others starting down this path, and that's the point, at least from my perspective. Everyone talks about promoting the language, and to me, this is one of the more outstanding ways I've seen.
> 
> 3) I can't believe you can't set dependencies as you say, but who knows, you might be right. If not, a mention in the README should certainly be sufficient.
> 
> 4) Figured something like that.
> 
> 5) I did monkey around with changing the target runtimes myself to more recent ones, but didn't seem to make much difference, but defaulting to more recent ones is definitely the way to go.
> 
> I guess just emphasizing that you HAVE to build THIS and THIS first (the WinRT stuff) before using Visual Ada, you know, step A, B, and C - as you said, would help a lot. 
> 
> I suppose I could start doing PRs for documentation suggestions or other issues of course, on the WinRT stuff. When/if VisualAda goes to GitHub, same thing.
> 
> I'm just having fun doing this, and hey, anything I can do to help. I have absolutely no need for GtkAda, and doing a Windows app in Ada is still to me  mind-blowing.
> 
> I did try to build a UWP DLL the other day and ran into an error, can't remember what it was exactly, but when I get a chance, I'll pass along the details.
> 
> I strongly suspect deploying a VisualAda UWP app to Xbox WILL work, just haven't had the chance to set it up yet. But will soon.
> 
> Again, thanks for all of this incredible work,
> Greg

Hi Greg

I apologise, I actually missed this post (and replied to you later post without
seeing this one). So in response to your points, which are very much appreciated

1) and 2) I have already posted some changes to the GitHub readme's for both
winrt_runtime and winrt project to reflect the dependencies and additional info.
PR's are very welcome for the documentation, But bear in mind that the winrt
source code is generated of the back of the winmd metadata, so changes to the
bindings need to be generic!. I am happy to accept PR's for winrt_runtime.

BTW, Thanks for your comment's regarding my work, I in part embarked on this
journey. because I saw a need to promote Ada outside of its traditional use
case in the safety critical/embedded/Realtime markets and I always considered
Ada as a general purpose language applicable to any environment. To this end I
saw that providing bindings to Win32, WinRT and providing "Visual Studio"
integration would encourage young graduates / IT professionals to at least be
given the tools to develop great Ada applications in a familiar development IDE
and lets face it, MS does have an impact (be it free or other wise) on the
choice of what IDE is used within an IT shop.

3) I have done some more research (ie googling) and may have found a workaround
to being able to set project dependencies for VS solutions with multiple
projects, have a look in your spare time :-) TL:DR

https://blog.tonysneed.com/2011/09/14/build-a-multi-project-visual-studio-template/

4) and 5) I have as yet not had a chance to look at this in detail yet, will
do this over the weekend, while looking at the packaging/install issue with
VisualAda.

On a side note: what's your thoughts on the following idea's

a) Use Nuget to install/reference the WinRT dependencies. But this does mean
that each UWP app has its own copy of the WinRT dependencies. Not ideal in my
view (unless of course you are diligent and update your refences regularly) and
definably / probably NOT workable in a very disciplined IT environment.

b) I am not sure that a UWP app can be distributed with a "native DLL" via
Windows Store (as opposed to statically linking to a LIB). If it cant, do you
see any value in keeping the "UWP DLL" template ? Note that apps that are side
loaded (ie within a corporate env and NOT distributed via the Windows Store) are
not under the same restriction

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

[Optikos]

On Friday, May 10, 2019 at 7:08:30 AM UTC-5, alby....@gmail.com wrote:
> On Thursday, May 9, 2019 at 7:20:14 AM UTC+10, Greg wrote:
> > Alex, sorry, been hammered with deadlines and too tired at night to even look at a screen.
> > 
> > 1) and 2) would go a long way to helping others starting down this path, and that's the point, at least from my perspective. Everyone talks about promoting the language, and to me, this is one of the more outstanding ways I've seen.
> > 
> > 3) I can't believe you can't set dependencies as you say, but who knows, you might be right. If not, a mention in the README should certainly be sufficient.
> > 
> > 4) Figured something like that.
> > 
> > 5) I did monkey around with changing the target runtimes myself to more recent ones, but didn't seem to make much difference, but defaulting to more recent ones is definitely the way to go.
> > 
> > I guess just emphasizing that you HAVE to build THIS and THIS first (the WinRT stuff) before using Visual Ada, you know, step A, B, and C - as you said, would help a lot. 
> > 
> > I suppose I could start doing PRs for documentation suggestions or other issues of course, on the WinRT stuff. When/if VisualAda goes to GitHub, same thing.
> > 
> > I'm just having fun doing this, and hey, anything I can do to help. I have absolutely no need for GtkAda, and doing a Windows app in Ada is still to me  mind-blowing.
> > 
> > I did try to build a UWP DLL the other day and ran into an error, can't remember what it was exactly, but when I get a chance, I'll pass along the details.
> > 
> > I strongly suspect deploying a VisualAda UWP app to Xbox WILL work, just haven't had the chance to set it up yet. But will soon.
> > 
> > Again, thanks for all of this incredible work,
> > Greg
> 
> Hi Greg
> 
> I apologise, I actually missed this post (and replied to you later post without
> seeing this one). So in response to your points, which are very much appreciated
> 
> 1) and 2) I have already posted some changes to the GitHub readme's for both
> winrt_runtime and winrt project to reflect the dependencies and additional info.
> PR's are very welcome for the documentation, But bear in mind that the winrt
> source code is generated of the back of the winmd metadata, so changes to the
> bindings need to be generic!. I am happy to accept PR's for winrt_runtime.
> 
> BTW, Thanks for your comment's regarding my work, I in part embarked on this
> journey. because I saw a need to promote Ada outside of its traditional use
> case in the safety critical/embedded/Realtime markets and I always considered
> Ada as a general purpose language applicable to any environment. To this end I
> saw that providing bindings to Win32, WinRT and providing "Visual Studio"
> integration would encourage young graduates / IT professionals to at least be
> given the tools to develop great Ada applications in a familiar development IDE
> and lets face it, MS does have an impact (be it free or other wise) on the
> choice of what IDE is used within an IT shop.
> 
> 3) I have done some more research (ie googling) and may have found a workaround
> to being able to set project dependencies for VS solutions with multiple
> projects, have a look in your spare time :-) TL:DR
> 
> https://blog.tonysneed.com/2011/09/14/build-a-multi-project-visual-studio-template/
> 
> 4) and 5) I have as yet not had a chance to look at this in detail yet, will
> do this over the weekend, while looking at the packaging/install issue with
> VisualAda.
> 
> On a side note: what's your thoughts on the following idea's
> 
> a) Use Nuget to install/reference the WinRT dependencies. But this does mean
> that each UWP app has its own copy of the WinRT dependencies. Not ideal in my
> view (unless of course you are diligent and update your refences regularly) and
> definably / probably NOT workable in a very disciplined IT environment.

This is the practice in place for all nugets.  It is not as unwise as it first appears.  This practice allows a decoupling of each project so that different projects can update to different nuget dependencies as that project sees fit internally.  If not on a per-project basis for what that project/executable/library needs for its own internal needs, then on what basis?
1) one size fits all projects resident on some developer's individual Windows 10 computer?
2) one size fits all across all developers in a software-development department?
3) one size fits all across an IT department (or per-.NET-programming-language coding-standards culture) serving multiple software-development departments?
4) one size fits all across a campus?
5) one size fits all across all campuses of an entire corporation?
6) one size fits all across the entire universe of all corporations?

Or in fewer words, there is a method to Microsoft's madness.  :-) 

> b) I am not sure that a UWP app can be distributed with a "native DLL" via
> Windows Store (as opposed to statically linking to a LIB). If it cant, do you
> see any value in keeping the "UWP DLL" template ? Note that apps that are side
> loaded (ie within a corporate env and NOT distributed via the Windows Store) are
> not under the same restriction

Although I have not personally distributed a UWP app that contains a Win32 or WoW DLL (that obeys the subset-of-the-Win32-API restrictions) in the Microsoft Store, it appears to be permitted, if enough requisites are satisfied:
https://social.msdn.microsoft.com/forums/windowsapps/en-us/c5636e14-422f-4ab0-b608-2609ad8198e4/metro-style-app-how-to-load-win32-dll

Does the DLL in question in VisualAda confine itself to the UWP-compliant subset of the Win32 API?

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

[Greg]

Quick thoughts:

a) Use Nuget to install/reference the WinRT dependencies. But this does mean 
that each UWP app has its own copy of the WinRT dependencies. Not ideal in my 
view (unless of course you are diligent and update your refences regularly) and definably / probably NOT workable in a very disciplined IT environment. 

This would be massively good, one less step (actually more than one) to get up and running with a real Ada/UWP app. Just so I'm clear ... you mean a separate NuGet package for each Win10 SDK version, i.e. 1803/17134? Not sure I've seen that methodology, but I'm sure it's used. And for example, my personal stuff is running (now) Insiders with 18362 while my work laptop is currently suffering with 16299.

b) I am not sure that a UWP app can be distributed with a "native DLL" via 
Windows Store (as opposed to statically linking to a LIB). If it cant, do you see any value in keeping the "UWP DLL" template ? Note that apps that are side loaded (ie within a corporate env and NOT distributed via the Windows Store) are not under the same restriction.

At first I thought, nah, I'd dump it because for my personal use cases (right now, anyway), I don't really have a use for it. I was just trying to break - sorry, I mean test :) - the different templates. But in enterprise situations, where you often couldn't care less about Windows Store - sure, it'd be very valuable. I mean, I build "common" DLLs (.NET) all the time, each used by 3-4 different apps. Absolutely.

... personally - and quite selfishly - I'd rather see Intellisense advance (which you've mentioned in your READMEs I know) , Object Explorer support of some kind, (probably the same thing, but then again I've never added that sort of extension support for a language before.) You know, the whole VS kind of stuff we've all come to expect and love (I've never been one to say, "hey, I'm a REAL developer - I don't NEED Intellisense" :))

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

[alby.gamper]

On Saturday, May 11, 2019 at 7:15:33 AM UTC+10, Greg wrote:
> Quick thoughts:
> 
> a) Use Nuget to install/reference the WinRT dependencies. But this does mean 
> that each UWP app has its own copy of the WinRT dependencies. Not ideal in my 
> view (unless of course you are diligent and update your refences regularly) and definably / probably NOT workable in a very disciplined IT environment. 
> 
> This would be massively good, one less step (actually more than one) to get up and running with a real Ada/UWP app. Just so I'm clear ... you mean a separate NuGet package for each Win10 SDK version, i.e. 1803/17134? Not sure I've seen that methodology, but I'm sure it's used. And for example, my personal stuff is running (now) Insiders with 18362 while my work laptop is currently suffering with 16299.
> 
> b) I am not sure that a UWP app can be distributed with a "native DLL" via 
> Windows Store (as opposed to statically linking to a LIB). If it cant, do you see any value in keeping the "UWP DLL" template ? Note that apps that are side loaded (ie within a corporate env and NOT distributed via the Windows Store) are not under the same restriction.
> 
> At first I thought, nah, I'd dump it because for my personal use cases (right now, anyway), I don't really have a use for it. I was just trying to break - sorry, I mean test :) - the different templates. But in enterprise situations, where you often couldn't care less about Windows Store - sure, it'd be very valuable. I mean, I build "common" DLLs (.NET) all the time, each used by 3-4 different apps. Absolutely.
> 
> ... personally - and quite selfishly - I'd rather see Intellisense advance (which you've mentioned in your READMEs I know) , Object Explorer support of some kind, (probably the same thing, but then again I've never added that sort of extension support for a language before.) You know, the whole VS kind of stuff we've all come to expect and love (I've never been one to say, "hey, I'm a REAL developer - I don't NEED Intellisense" :))

Hi Greg

Sounds like Nuget and Intellisense are my next priorities (Intellisense always
was, just haven't found a good solution yet) A couple of point for each

Nuget:

1) It probably makes sense for the WinRT Nuget to be versioned to the MS SDK version.
WinRT is after all is COM based, and linking in 19H1 libs when and trying to use
features of 19H1 (inadvertently) when you are running 1803 will cause problems.

I have already created a 1809 branch on Git (current master is 19H1). So I can
go back and create branches for 1803, 1709 .. etc if needed. Note 19362 SDK has
been released ahead of the official Windows 10 19H1 release

2) Or I could/should do version checking within the WinRt bindings themselves
and if their is a mismatch then raise an Ada exception before calling the actual Api

Intellisense: 

Their a few ways of doing this, all with pros and cons, these being

1) Extend the current use of ANTLR, which at the moment is just being used for
syntax colouring and Outlining (BraceMatching and BraceCompletion are handled
outside of ANTLR since the functionality does not require a full lexer/parser)

   I am not convinced the above is doable ?

2) Use the Adacore ada_language_server in conjunction with the MS supplied
Nuget package "Microsoft.VisualStudio.LanguageServer.Client" (which supplies a
default implementation of a LSP client). This is fairly easy to implement, However
the experience (thru no fault of AdaCore) I believe is not ideal. This is because I believe (as a fallback)
VS adds what it thinks are valid completions based on a dictionary of words in
the current document, which pollutes intellisense.

(FYI) Note that AdaCore's implementation of Ada_Language_Server is reliant upon their
LibAdaLang/LangKit GitHub projects.

3) Develop/use a Ada-COM wrapper over the functionality provided by AdaCore's
LibAdaLang and integrate this with the VS native Intellisense interfaces. This may sound
a bit over the top, But it does allow mapping between the LibAdaLang supplied
AST to that expected by VS Intellisense native interfaces.

The only problem/issue with this approach is that VS extensions (Like VisualAda)
must target win32 (Since VS is actually a 32 bit app and It cant easily access a
64 bit app,COM dll). So building a LibAdaLang 32 bit library may be problematic.
I believe this is possible, but reliant on availability of recent GCC 32 bit
compilers.

The above points are just food for thought (so to speak)

Alex

NOTE:

Ive got a new release 1.2.1 ready which resolves the following issue you had

1)UWP DLL project - link error (libgnat-8). This is actually caused by trying to generate both
a GCC lib and a MS LIB and is caused by issue with the supplied MS ada.targets file
2) UWP XML application dependencies are now resolved, and will build the <App>XML
project before the <App> project, which is what is expected.
3) If you have not already encountered issues with install/uninstall functionality
then these are now resolved (Note it really only makes sense to install/uninstall
library based projects??

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

[alby.gamper]

On Saturday, May 11, 2019 at 12:40:37 AM UTC+10, Optikos wrote:
> On Friday, May 10, 2019 at 7:08:30 AM UTC-5, alby....@gmail.com wrote:
> > On Thursday, May 9, 2019 at 7:20:14 AM UTC+10, Greg wrote:
> > > Alex, sorry, been hammered with deadlines and too tired at night to even look at a screen.
> > > 
> > > 1) and 2) would go a long way to helping others starting down this path, and that's the point, at least from my perspective. Everyone talks about promoting the language, and to me, this is one of the more outstanding ways I've seen.
> > > 
> > > 3) I can't believe you can't set dependencies as you say, but who knows, you might be right. If not, a mention in the README should certainly be sufficient.
> > > 
> > > 4) Figured something like that.
> > > 
> > > 5) I did monkey around with changing the target runtimes myself to more recent ones, but didn't seem to make much difference, but defaulting to more recent ones is definitely the way to go.
> > > 
> > > I guess just emphasizing that you HAVE to build THIS and THIS first (the WinRT stuff) before using Visual Ada, you know, step A, B, and C - as you said, would help a lot. 
> > > 
> > > I suppose I could start doing PRs for documentation suggestions or other issues of course, on the WinRT stuff. When/if VisualAda goes to GitHub, same thing.
> > > 
> > > I'm just having fun doing this, and hey, anything I can do to help. I have absolutely no need for GtkAda, and doing a Windows app in Ada is still to me  mind-blowing.
> > > 
> > > I did try to build a UWP DLL the other day and ran into an error, can't remember what it was exactly, but when I get a chance, I'll pass along the details.
> > > 
> > > I strongly suspect deploying a VisualAda UWP app to Xbox WILL work, just haven't had the chance to set it up yet. But will soon.
> > > 
> > > Again, thanks for all of this incredible work,
> > > Greg
> > 
> > Hi Greg
> > 
> > I apologise, I actually missed this post (and replied to you later post without
> > seeing this one). So in response to your points, which are very much appreciated
> > 
> > 1) and 2) I have already posted some changes to the GitHub readme's for both
> > winrt_runtime and winrt project to reflect the dependencies and additional info.
> > PR's are very welcome for the documentation, But bear in mind that the winrt
> > source code is generated of the back of the winmd metadata, so changes to the
> > bindings need to be generic!. I am happy to accept PR's for winrt_runtime.
> > 
> > BTW, Thanks for your comment's regarding my work, I in part embarked on this
> > journey. because I saw a need to promote Ada outside of its traditional use
> > case in the safety critical/embedded/Realtime markets and I always considered
> > Ada as a general purpose language applicable to any environment. To this end I
> > saw that providing bindings to Win32, WinRT and providing "Visual Studio"
> > integration would encourage young graduates / IT professionals to at least be
> > given the tools to develop great Ada applications in a familiar development IDE
> > and lets face it, MS does have an impact (be it free or other wise) on the
> > choice of what IDE is used within an IT shop.
> > 
> > 3) I have done some more research (ie googling) and may have found a workaround
> > to being able to set project dependencies for VS solutions with multiple
> > projects, have a look in your spare time :-) TL:DR
> > 
> > https://blog.tonysneed.com/2011/09/14/build-a-multi-project-visual-studio-template/
> > 
> > 4) and 5) I have as yet not had a chance to look at this in detail yet, will
> > do this over the weekend, while looking at the packaging/install issue with
> > VisualAda.
> > 
> > On a side note: what's your thoughts on the following idea's
> > 
> > a) Use Nuget to install/reference the WinRT dependencies. But this does mean
> > that each UWP app has its own copy of the WinRT dependencies. Not ideal in my
> > view (unless of course you are diligent and update your refences regularly) and
> > definably / probably NOT workable in a very disciplined IT environment.
> 
> This is the practice in place for all nugets.  It is not as unwise as it first appears.  This practice allows a decoupling of each project so that different projects can update to different nuget dependencies as that project sees fit internally.  If not on a per-project basis for what that project/executable/library needs for its own internal needs, then on what basis?
> 1) one size fits all projects resident on some developer's individual Windows 10 computer?
> 2) one size fits all across all developers in a software-development department?
> 3) one size fits all across an IT department (or per-.NET-programming-language coding-standards culture) serving multiple software-development departments?
> 4) one size fits all across a campus?
> 5) one size fits all across all campuses of an entire corporation?
> 6) one size fits all across the entire universe of all corporations?
> 
> Or in fewer words, there is a method to Microsoft's madness.  :-) 
> 
> > b) I am not sure that a UWP app can be distributed with a "native DLL" via
> > Windows Store (as opposed to statically linking to a LIB). If it cant, do you
> > see any value in keeping the "UWP DLL" template ? Note that apps that are side
> > loaded (ie within a corporate env and NOT distributed via the Windows Store) are
> > not under the same restriction
> 
> Although I have not personally distributed a UWP app that contains a Win32 or WoW DLL (that obeys the subset-of-the-Win32-API restrictions) in the Microsoft Store, it appears to be permitted, if enough requisites are satisfied:
> https://social.msdn.microsoft.com/forums/windowsapps/en-us/c5636e14-422f-4ab0-b608-2609ad8198e4/metro-style-app-how-to-load-win32-dll
> 
> Does the DLL in question in VisualAda confine itself to the UWP-compliant subset of the Win32 API?

Hi OptiKos

Yes the UWP project template has a dependency on the winrt_runtime, which passes
the WACK test wrt windows Api usage. But it is obviously possible to link in
other DLL's that are not WACK compliant, which wont pass the WACK tests.

Alex

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

[Jere]

On Sunday, May 5, 2019 at 4:28:00 AM UTC-4, alby....@gmail.com wrote:
> Dear Ada Community 
> 
> VisualAda version 1.2.0 has been released 
> 
> New Features, fixes include the following 
> 
> - Added compiler switches syntax checking, symantic checking, code page and wide character set encoding
> - Fixed bug - some compiler options were not set in GPR file, even though they were set in the vcxproj file
> - Dynamically determine Target when creating new projects. Supported Targets are currently (Win32 -> i686-- and x64 -> x86_64--). ARM Targets will be forthcoming.
> - Check validity of determined Target when building a project, for example the Target could have be set to a specific gcc triplet, blank or 'Unknown'. Resulting in either a info, warning or error message respectively.
> - Dynamically determine root directories for each target when creating new projects (only applicable to projects that rely on the Microsoft Linker, such as Winrt/UWP based applications)
> - Fixed bug - Msbuild failures caused by inadvertent references to VS 2015 dll's
> 
> Please feel free to download the free plugin from the following URL 
> 
> https://marketplace.visualstudio.com/items?itemName=AlexGamper.VisualAda 
> 
> Note: 
> 
> if you have issues with installation, please respond to this post, and I will 
> endeavour to resolve as soon as possible. In the long term I intend to setup 
> a specific GitHub project, where issues/improvements can be made for me to action. 
> 
> Thanks 
> 
> Alex

As I get time, I'll mess with this and try it out.  Kids give me limited time.  
I did clone the winrt_runtime and start messing with it today.  I noticed a 
warning:

 [C]            cio.c
\winrt_runtime\cpp\cio.c:45:16: warning: '__acrt_iob_func' redeclared without dllimport attribute: previous dllimport ignored [-Wattributes]
  FILE* __cdecl __acrt_iob_func(unsigned);

Just a warning, but should I start an issue for it on your github repo 
in case it is important?  This is with msys2, GNAT/GCC 8.2.0

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

[Jere]

On Saturday, May 11, 2019 at 7:34:51 AM UTC-4, Jere wrote:
> On Sunday, May 5, 2019 at 4:28:00 AM UTC-4, alby....@gmail.com wrote:
> > Dear Ada Community 
> > 
> > VisualAda version 1.2.0 has been released 
> > 
> > New Features, fixes include the following 
> > 
> > - Added compiler switches syntax checking, symantic checking, code page and wide character set encoding
> > - Fixed bug - some compiler options were not set in GPR file, even though they were set in the vcxproj file
> > - Dynamically determine Target when creating new projects. Supported Targets are currently (Win32 -> i686-- and x64 -> x86_64--). ARM Targets will be forthcoming.
> > - Check validity of determined Target when building a project, for example the Target could have be set to a specific gcc triplet, blank or 'Unknown'. Resulting in either a info, warning or error message respectively.
> > - Dynamically determine root directories for each target when creating new projects (only applicable to projects that rely on the Microsoft Linker, such as Winrt/UWP based applications)
> > - Fixed bug - Msbuild failures caused by inadvertent references to VS 2015 dll's
> > 
> > Please feel free to download the free plugin from the following URL 
> > 
> > https://marketplace.visualstudio.com/items?itemName=AlexGamper.VisualAda 
> > 
> > Note: 
> > 
> > if you have issues with installation, please respond to this post, and I will 
> > endeavour to resolve as soon as possible. In the long term I intend to setup 
> > a specific GitHub project, where issues/improvements can be made for me to action. 
> > 
> > Thanks 
> > 
> > Alex
> 
> As I get time, I'll mess with this and try it out.  Kids give me limited time.  
> I did clone the winrt_runtime and start messing with it today.  I noticed a 
> warning:
> 
>  [C]            cio.c
> \winrt_runtime\cpp\cio.c:45:16: warning: '__acrt_iob_func' redeclared without dllimport attribute: previous dllimport ignored [-Wattributes]
>   FILE* __cdecl __acrt_iob_func(unsigned);
> 
> Just a warning, but should I start an issue for it on your github repo 
> in case it is important?  This is with msys2, GNAT/GCC 8.2.0

Not sure if related, but when I run the gprinstall command, it fails with:

$ gprinstall -f -p -P Winrt_Runtime.gpr
Install project Winrt_Runtime
gprinstall: error: file does not exist '\winrt_runtime\./lib/libother.a'

which definitely is not there, so maybe the gprbuild script missed
something?  I did configure the gpr file as instructed.  I'll look around
some of your other posts to see if someone else ran into the same thing
but you might consider updating your readme, if there is another dependency
for the runtime (maybe it is just a build error of some sort...I didn't
receive any errors though, just the warning I mentioned before).

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

[alby.gamper]

On Saturday, May 11, 2019 at 9:42:06 PM UTC+10, Jere wrote:
> On Saturday, May 11, 2019 at 7:34:51 AM UTC-4, Jere wrote:
> > On Sunday, May 5, 2019 at 4:28:00 AM UTC-4, alby....@gmail.com wrote:
> > > Dear Ada Community 
> > > 
> > > VisualAda version 1.2.0 has been released 
> > > 
> > > New Features, fixes include the following 
> > > 
> > > - Added compiler switches syntax checking, symantic checking, code page and wide character set encoding
> > > - Fixed bug - some compiler options were not set in GPR file, even though they were set in the vcxproj file
> > > - Dynamically determine Target when creating new projects. Supported Targets are currently (Win32 -> i686-- and x64 -> x86_64--). ARM Targets will be forthcoming.
> > > - Check validity of determined Target when building a project, for example the Target could have be set to a specific gcc triplet, blank or 'Unknown'. Resulting in either a info, warning or error message respectively.
> > > - Dynamically determine root directories for each target when creating new projects (only applicable to projects that rely on the Microsoft Linker, such as Winrt/UWP based applications)
> > > - Fixed bug - Msbuild failures caused by inadvertent references to VS 2015 dll's
> > > 
> > > Please feel free to download the free plugin from the following URL 
> > > 
> > > https://marketplace.visualstudio.com/items?itemName=AlexGamper.VisualAda 
> > > 
> > > Note: 
> > > 
> > > if you have issues with installation, please respond to this post, and I will 
> > > endeavour to resolve as soon as possible. In the long term I intend to setup 
> > > a specific GitHub project, where issues/improvements can be made for me to action. 
> > > 
> > > Thanks 
> > > 
> > > Alex
> > 
> > As I get time, I'll mess with this and try it out.  Kids give me limited time.  
> > I did clone the winrt_runtime and start messing with it today.  I noticed a 
> > warning:
> > 
> >  [C]            cio.c
> > \winrt_runtime\cpp\cio.c:45:16: warning: '__acrt_iob_func' redeclared without dllimport attribute: previous dllimport ignored [-Wattributes]
> >   FILE* __cdecl __acrt_iob_func(unsigned);
> > 
> > Just a warning, but should I start an issue for it on your github repo 
> > in case it is important?  This is with msys2, GNAT/GCC 8.2.0
> 
> Not sure if related, but when I run the gprinstall command, it fails with:
> 
> $ gprinstall -f -p -P Winrt_Runtime.gpr
> Install project Winrt_Runtime
> gprinstall: error: file does not exist '\winrt_runtime\./lib/libother.a'
> 
> which definitely is not there, so maybe the gprbuild script missed
> something?  I did configure the gpr file as instructed.  I'll look around
> some of your other posts to see if someone else ran into the same thing
> but you might consider updating your readme, if there is another dependency
> for the runtime (maybe it is just a build error of some sort...I didn't
> receive any errors though, just the warning I mentioned before).

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

[alby.gamper]

On Saturday, May 11, 2019 at 9:42:06 PM UTC+10, Jere wrote:
> On Saturday, May 11, 2019 at 7:34:51 AM UTC-4, Jere wrote:
> > On Sunday, May 5, 2019 at 4:28:00 AM UTC-4, alby....@gmail.com wrote:
> > > Dear Ada Community 
> > > 
> > > VisualAda version 1.2.0 has been released 
> > > 
> > > New Features, fixes include the following 
> > > 
> > > - Added compiler switches syntax checking, symantic checking, code page and wide character set encoding
> > > - Fixed bug - some compiler options were not set in GPR file, even though they were set in the vcxproj file
> > > - Dynamically determine Target when creating new projects. Supported Targets are currently (Win32 -> i686-- and x64 -> x86_64--). ARM Targets will be forthcoming.
> > > - Check validity of determined Target when building a project, for example the Target could have be set to a specific gcc triplet, blank or 'Unknown'. Resulting in either a info, warning or error message respectively.
> > > - Dynamically determine root directories for each target when creating new projects (only applicable to projects that rely on the Microsoft Linker, such as Winrt/UWP based applications)
> > > - Fixed bug - Msbuild failures caused by inadvertent references to VS 2015 dll's
> > > 
> > > Please feel free to download the free plugin from the following URL 
> > > 
> > > https://marketplace.visualstudio.com/items?itemName=AlexGamper.VisualAda 
> > > 
> > > Note: 
> > > 
> > > if you have issues with installation, please respond to this post, and I will 
> > > endeavour to resolve as soon as possible. In the long term I intend to setup 
> > > a specific GitHub project, where issues/improvements can be made for me to action. 
> > > 
> > > Thanks 
> > > 
> > > Alex
> > 
> > As I get time, I'll mess with this and try it out.  Kids give me limited time.  
> > I did clone the winrt_runtime and start messing with it today.  I noticed a 
> > warning:
> > 
> >  [C]            cio.c
> > \winrt_runtime\cpp\cio.c:45:16: warning: '__acrt_iob_func' redeclared without dllimport attribute: previous dllimport ignored [-Wattributes]
> >   FILE* __cdecl __acrt_iob_func(unsigned);
> > 
> > Just a warning, but should I start an issue for it on your github repo 
> > in case it is important?  This is with msys2, GNAT/GCC 8.2.0
> 
> Not sure if related, but when I run the gprinstall command, it fails with:
> 
> $ gprinstall -f -p -P Winrt_Runtime.gpr
> Install project Winrt_Runtime
> gprinstall: error: file does not exist '\winrt_runtime\./lib/libother.a'
> 
> which definitely is not there, so maybe the gprbuild script missed
> something?  I did configure the gpr file as instructed.  I'll look around
> some of your other posts to see if someone else ran into the same thing
> but you might consider updating your readme, if there is another dependency
> for the runtime (maybe it is just a build error of some sort...I didn't
> receive any errors though, just the warning I mentioned before).

Hi Jere

Can you do a git pull to get the latest version ? Your gpr file for winrt_runtime
should look like the following fragmaent for the Install section

    package Install is
        for Prefix use Install_Prefix;
        for Required_Artifacts ("") use ("runtime.xml", "ada_source_path", "ada_object_path");
        for Required_Artifacts ("adalib") use ("./lib/libother.a", "./libgnarl/libgnarl.a");
        for Sources_Subdir use "adainclude";
        for Lib_Subdir use "adalib";
        for Install_Project use "false";
    end Install;

Alex

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

[Jere]

On Saturday, May 11, 2019 at 8:32:18 AM UTC-4, alby....@gmail.com wrote:
> On Saturday, May 11, 2019 at 9:42:06 PM UTC+10, Jere wrote:
> > On Saturday, May 11, 2019 at 7:34:51 AM UTC-4, Jere wrote:
> > > On Sunday, May 5, 2019 at 4:28:00 AM UTC-4, alby....@gmail.com wrote:
> > > > Dear Ada Community 
> > > > 
> > > > VisualAda version 1.2.0 has been released 
> > > > 
> > > > New Features, fixes include the following 
> > > > 
> > > > - Added compiler switches syntax checking, symantic checking, code page and wide character set encoding
> > > > - Fixed bug - some compiler options were not set in GPR file, even though they were set in the vcxproj file
> > > > - Dynamically determine Target when creating new projects. Supported Targets are currently (Win32 -> i686-- and x64 -> x86_64--). ARM Targets will be forthcoming.
> > > > - Check validity of determined Target when building a project, for example the Target could have be set to a specific gcc triplet, blank or 'Unknown'. Resulting in either a info, warning or error message respectively.
> > > > - Dynamically determine root directories for each target when creating new projects (only applicable to projects that rely on the Microsoft Linker, such as Winrt/UWP based applications)
> > > > - Fixed bug - Msbuild failures caused by inadvertent references to VS 2015 dll's
> > > > 
> > > > Please feel free to download the free plugin from the following URL 
> > > > 
> > > > https://marketplace.visualstudio.com/items?itemName=AlexGamper.VisualAda 
> > > > 
> > > > Note: 
> > > > 
> > > > if you have issues with installation, please respond to this post, and I will 
> > > > endeavour to resolve as soon as possible. In the long term I intend to setup 
> > > > a specific GitHub project, where issues/improvements can be made for me to action. 
> > > > 
> > > > Thanks 
> > > > 
> > > > Alex
> > > 
> > > As I get time, I'll mess with this and try it out.  Kids give me limited time.  
> > > I did clone the winrt_runtime and start messing with it today.  I noticed a 
> > > warning:
> > > 
> > >  [C]            cio.c
> > > \winrt_runtime\cpp\cio.c:45:16: warning: '__acrt_iob_func' redeclared without dllimport attribute: previous dllimport ignored [-Wattributes]
> > >   FILE* __cdecl __acrt_iob_func(unsigned);
> > > 
> > > Just a warning, but should I start an issue for it on your github repo 
> > > in case it is important?  This is with msys2, GNAT/GCC 8.2.0
> > 
> > Not sure if related, but when I run the gprinstall command, it fails with:
> > 
> > $ gprinstall -f -p -P Winrt_Runtime.gpr
> > Install project Winrt_Runtime
> > gprinstall: error: file does not exist '\winrt_runtime\./lib/libother.a'
> > 
> > which definitely is not there, so maybe the gprbuild script missed
> > something?  I did configure the gpr file as instructed.  I'll look around
> > some of your other posts to see if someone else ran into the same thing
> > but you might consider updating your readme, if there is another dependency
> > for the runtime (maybe it is just a build error of some sort...I didn't
> > receive any errors though, just the warning I mentioned before).
> 
> Hi Jere
> 
> Can you do a git pull to get the latest version ? Your gpr file for winrt_runtime
> should look like the following fragmaent for the Install section
> 
>     package Install is
>         for Prefix use Install_Prefix;
>         for Required_Artifacts ("") use ("runtime.xml", "ada_source_path", "ada_object_path");
>         for Required_Artifacts ("adalib") use ("./lib/libother.a", "./libgnarl/libgnarl.a");
>         for Sources_Subdir use "adainclude";
>         for Lib_Subdir use "adalib";
>         for Install_Project use "false";
>     end Install;
> 
> Alex

I had already one the pull today (prior to posting the issue).  Here is the
gpr file:

project Winrt_Runtime is

    Base_Source_Dir       := Project'Project_Dir;
    Base_Installation_Dir := "lib\gcc\x86_64-pc-mingw32\8.2.0/";
    Default_Prefix        := Base_Installation_Dir & "rts-Winrt_Runtime";
    Install_Prefix        := external ("PREFIX", Default_Prefix);

    for Languages use ("Ada", "C", "Asm");
    for Library_Auto_Init use "False";
    for Library_Name use "gnat";
    for Library_Kind use "static";
    for Library_Dir use "adalib";
    for Object_Dir use "build";
    for Source_Dirs use ("adainclude", "cpp");  
    for Target use "x86_64-w64-mingw32 ";

    type Build_Type is ("Production", "Debug");

    Build : Build_Type := external ("BUILD", "Debug");

    package Builder is
        for Switches ("Ada") use ("--RTS=" & Project'Project_dir);
    end Builder;

    package Compiler is
        CFLAGS := ("");
        
        case Build is
            when "Production" =>
                CFLAGS := CFLAGS & ("-O2");
            when "Debug" =>
                CFLAGS := CFLAGS & ("-O0");
        end case;
        
        ALL_CFLAGS := ("-fexceptions") & CFLAGS;
        for Switches ("C") use ALL_CFLAGS;

        ALL_ADAFLAGS := ("-g", "-gnatpg", "-nostdinc") & CFLAGS;
        for Switches ("Ada") use ALL_ADAFLAGS;
    end Compiler;

    package Binder is
    end Binder;

    package Linker is
    end Linker;

    package Install is
        for Prefix use Install_Prefix;
        for Required_Artifacts ("") use ("runtime.xml", "ada_source_path", "ada_object_path");
        for Required_Artifacts ("adalib") use ("./lib/libother.a", "./libgnarl/libgnarl.a");
        for Sources_Subdir use "adainclude";
        for Lib_Subdir use "adalib";
        for Install_Project use "false";
    end Install;

end Winrt_Runtime;

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

[Jere]

On Saturday, May 11, 2019 at 9:50:26 AM UTC-4, Jere wrote:
> On Saturday, May 11, 2019 at 8:32:18 AM UTC-4, alby....@gmail.com wrote:
> > On Saturday, May 11, 2019 at 9:42:06 PM UTC+10, Jere wrote:
> > > On Saturday, May 11, 2019 at 7:34:51 AM UTC-4, Jere wrote:
> > > > On Sunday, May 5, 2019 at 4:28:00 AM UTC-4, alby....@gmail.com wrote:
> > > > > Dear Ada Community 
> > > > > 
> > > > > VisualAda version 1.2.0 has been released 
> > > > > 
> > > > > New Features, fixes include the following 
> > > > > 
> > > > > - Added compiler switches syntax checking, symantic checking, code page and wide character set encoding
> > > > > - Fixed bug - some compiler options were not set in GPR file, even though they were set in the vcxproj file
> > > > > - Dynamically determine Target when creating new projects. Supported Targets are currently (Win32 -> i686-- and x64 -> x86_64--). ARM Targets will be forthcoming.
> > > > > - Check validity of determined Target when building a project, for example the Target could have be set to a specific gcc triplet, blank or 'Unknown'. Resulting in either a info, warning or error message respectively.
> > > > > - Dynamically determine root directories for each target when creating new projects (only applicable to projects that rely on the Microsoft Linker, such as Winrt/UWP based applications)
> > > > > - Fixed bug - Msbuild failures caused by inadvertent references to VS 2015 dll's
> > > > > 
> > > > > Please feel free to download the free plugin from the following URL 
> > > > > 
> > > > > https://marketplace.visualstudio.com/items?itemName=AlexGamper.VisualAda 
> > > > > 
> > > > > Note: 
> > > > > 
> > > > > if you have issues with installation, please respond to this post, and I will 
> > > > > endeavour to resolve as soon as possible. In the long term I intend to setup 
> > > > > a specific GitHub project, where issues/improvements can be made for me to action. 
> > > > > 
> > > > > Thanks 
> > > > > 
> > > > > Alex
> > > > 
> > > > As I get time, I'll mess with this and try it out.  Kids give me limited time.  
> > > > I did clone the winrt_runtime and start messing with it today.  I noticed a 
> > > > warning:
> > > > 
> > > >  [C]            cio.c
> > > > \winrt_runtime\cpp\cio.c:45:16: warning: '__acrt_iob_func' redeclared without dllimport attribute: previous dllimport ignored [-Wattributes]
> > > >   FILE* __cdecl __acrt_iob_func(unsigned);
> > > > 
> > > > Just a warning, but should I start an issue for it on your github repo 
> > > > in case it is important?  This is with msys2, GNAT/GCC 8.2.0
> > > 
> > > Not sure if related, but when I run the gprinstall command, it fails with:
> > > 
> > > $ gprinstall -f -p -P Winrt_Runtime.gpr
> > > Install project Winrt_Runtime
> > > gprinstall: error: file does not exist '\winrt_runtime\./lib/libother.a'
> > > 
> > > which definitely is not there, so maybe the gprbuild script missed
> > > something?  I did configure the gpr file as instructed.  I'll look around
> > > some of your other posts to see if someone else ran into the same thing
> > > but you might consider updating your readme, if there is another dependency
> > > for the runtime (maybe it is just a build error of some sort...I didn't
> > > receive any errors though, just the warning I mentioned before).
> > 
> > Hi Jere
> > 
> > Can you do a git pull to get the latest version ? Your gpr file for winrt_runtime
> > should look like the following fragmaent for the Install section
> > 
> >     package Install is
> >         for Prefix use Install_Prefix;
> >         for Required_Artifacts ("") use ("runtime.xml", "ada_source_path", "ada_object_path");
> >         for Required_Artifacts ("adalib") use ("./lib/libother.a", "./libgnarl/libgnarl.a");
> >         for Sources_Subdir use "adainclude";
> >         for Lib_Subdir use "adalib";
> >         for Install_Project use "false";
> >     end Install;
> > 
> > Alex
> 
> I had already one the pull today (prior to posting the issue).  Here is the
> gpr file:
> 

*I had already done the pull*

If it helps, I did the following steps this morning:
fresh clone of the repo
change the gpr to point to my GCC install
.\gprbuild -p -P Winrt_runtime.gpr (which gave the warning I mentioned)
.\gprclean -P Winnrt_runtime.gpr (which gave the install error)

So all of this is fresh as of this morning

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

[alby.gamper]

On Saturday, May 11, 2019 at 9:34:51 PM UTC+10, Jere wrote:
> On Sunday, May 5, 2019 at 4:28:00 AM UTC-4, alby....@gmail.com wrote:
> > Dear Ada Community 
> > 
> > VisualAda version 1.2.0 has been released 
> > 
> > New Features, fixes include the following 
> > 
> > - Added compiler switches syntax checking, symantic checking, code page and wide character set encoding
> > - Fixed bug - some compiler options were not set in GPR file, even though they were set in the vcxproj file
> > - Dynamically determine Target when creating new projects. Supported Targets are currently (Win32 -> i686-- and x64 -> x86_64--). ARM Targets will be forthcoming.
> > - Check validity of determined Target when building a project, for example the Target could have be set to a specific gcc triplet, blank or 'Unknown'. Resulting in either a info, warning or error message respectively.
> > - Dynamically determine root directories for each target when creating new projects (only applicable to projects that rely on the Microsoft Linker, such as Winrt/UWP based applications)
> > - Fixed bug - Msbuild failures caused by inadvertent references to VS 2015 dll's
> > 
> > Please feel free to download the free plugin from the following URL 
> > 
> > https://marketplace.visualstudio.com/items?itemName=AlexGamper.VisualAda 
> > 
> > Note: 
> > 
> > if you have issues with installation, please respond to this post, and I will 
> > endeavour to resolve as soon as possible. In the long term I intend to setup 
> > a specific GitHub project, where issues/improvements can be made for me to action. 
> > 
> > Thanks 
> > 
> > Alex
> 
> As I get time, I'll mess with this and try it out.  Kids give me limited time.  
> I did clone the winrt_runtime and start messing with it today.  I noticed a 
> warning:
> 
>  [C]            cio.c
> \winrt_runtime\cpp\cio.c:45:16: warning: '__acrt_iob_func' redeclared without dllimport attribute: previous dllimport ignored [-Wattributes]
>   FILE* __cdecl __acrt_iob_func(unsigned);
> 
> Just a warning, but should I start an issue for it on your github repo 
> in case it is important?  This is with msys2, GNAT/GCC 8.2.0

Hi Jere

   Yes , please raise an issue on GitHub, so we can keep track. Note I did see
   something similar to this and was caused by using an earlier version of MSYS2
   but 8.2 should be fine. Try a clean git pull and build ? Note yo should see


Alex

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

[Jere]

On Saturday, May 11, 2019 at 8:23:08 AM UTC-4, alby....@gmail.com wrote:
> On Saturday, May 11, 2019 at 9:34:51 PM UTC+10, Jere wrote:
> > On Sunday, May 5, 2019 at 4:28:00 AM UTC-4, alby....@gmail.com wrote:
> > > Dear Ada Community 
> > > 
> > > VisualAda version 1.2.0 has been released 
> > > 
> > > New Features, fixes include the following 
> > > 
> > > - Added compiler switches syntax checking, symantic checking, code page and wide character set encoding
> > > - Fixed bug - some compiler options were not set in GPR file, even though they were set in the vcxproj file
> > > - Dynamically determine Target when creating new projects. Supported Targets are currently (Win32 -> i686-- and x64 -> x86_64--). ARM Targets will be forthcoming.
> > > - Check validity of determined Target when building a project, for example the Target could have be set to a specific gcc triplet, blank or 'Unknown'. Resulting in either a info, warning or error message respectively.
> > > - Dynamically determine root directories for each target when creating new projects (only applicable to projects that rely on the Microsoft Linker, such as Winrt/UWP based applications)
> > > - Fixed bug - Msbuild failures caused by inadvertent references to VS 2015 dll's
> > > 
> > > Please feel free to download the free plugin from the following URL 
> > > 
> > > https://marketplace.visualstudio.com/items?itemName=AlexGamper.VisualAda 
> > > 
> > > Note: 
> > > 
> > > if you have issues with installation, please respond to this post, and I will 
> > > endeavour to resolve as soon as possible. In the long term I intend to setup 
> > > a specific GitHub project, where issues/improvements can be made for me to action. 
> > > 
> > > Thanks 
> > > 
> > > Alex
> > 
> > As I get time, I'll mess with this and try it out.  Kids give me limited time.  
> > I did clone the winrt_runtime and start messing with it today.  I noticed a 
> > warning:
> > 
> >  [C]            cio.c
> > \winrt_runtime\cpp\cio.c:45:16: warning: '__acrt_iob_func' redeclared without dllimport attribute: previous dllimport ignored [-Wattributes]
> >   FILE* __cdecl __acrt_iob_func(unsigned);
> > 
> > Just a warning, but should I start an issue for it on your github repo 
> > in case it is important?  This is with msys2, GNAT/GCC 8.2.0
> 
> Hi Jere
> 
>    Yes , please raise an issue on GitHub, so we can keep track. Note I did see
>    something similar to this and was caused by using an earlier version of MSYS2
>    but 8.2 should be fine. Try a clean git pull and build ? Note yo should see
> 
> 
> Alex

I raised both the warning and the install as issues on github.  I didn't
know if they were related, so I split them as separate issues.  Hopefully
that is ok.