Visual Studio IDE - Integration

Visual Studio IDE - Integration

[alby.gamper]

Dear Ada Community

Is their any general interest in using Visual Studio as an IDE for ADA
development ? (Not as a replacement to GPS, but rather as an alternative
for those teams primarily working on Windows based environments)

I have a pre Alpha solution that currently operates under Visual Studio 2015 (express/community edition) which covers the following functionality.

1) Project templates for console/GUI apps and static and shared libraries
2) Project configuration for most GNAT compiler, binder, linker options
3) Rudimentary syntax/keyword highlighting
4) GPRBUILD integration (ie MSBuild uses/invokes GPR project files)
5) GDB integration

But note the following limitations/caveats apply

a) A working native GCC toolchain must already be installed (either GNAP GPL or
a Mingw32 environment should work fine)

b) Some work needs to be done to support multilib (ie x86 vs x64)

c) No GUI designer is available (ie winforms, WPF, XAML)

d) I have a rudimentary binding to WinRT, BUT this is limited to NON GUI
functionality, since XAML  and Windows Composition API's seem to require a
sandboxed/windows Store environment to run under ?

I am more than willing to show some screen shots to demonstrate the current
functionality

Your thoughts/feedback are welcome

Thanks

Alex

Re: Visual Studio IDE - Integration

[Dmitry A. Kazakov]

On 27/01/2017 13:49, alby.gamper@gmail.com wrote:

> Is their any general interest in using Visual Studio as an IDE for ADA
> development ? (Not as a replacement to GPS, but rather as an alternative
> for those teams primarily working on Windows based environments)
>
> I have a pre Alpha solution that currently operates under Visual
> Studio 2015 (express/community edition) which covers the following
> functionality.
>
> 1) Project templates for console/GUI apps and static and shared libraries
> 2) Project configuration for most GNAT compiler, binder, linker options
> 3) Rudimentary syntax/keyword highlighting
> 4) GPRBUILD integration (ie MSBuild uses/invokes GPR project files)
> 5) GDB integration
>
> But note the following limitations/caveats apply
>
> a) A working native GCC toolchain must already be installed (either GNAP GPL or
> a Mingw32 environment should work fine)
>
> b) Some work needs to be done to support multilib (ie x86 vs x64)
>
> c) No GUI designer is available (ie winforms, WPF, XAML)
>
> d) I have a rudimentary binding to WinRT, BUT this is limited to NON GUI
> functionality, since XAML  and Windows Composition API's seem to require a
> sandboxed/windows Store environment to run under ?
>
> I am more than willing to show some screen shots to demonstrate the current
> functionality
>
> Your thoughts/feedback are welcome

As for me I see no reason using Visual Studio so long MS linker and MS 
debugger are not used. Main headaches are gcc linker (becoming 
exponentially slower with each added library) and GDB (unusable).

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Visual Studio IDE - Integration

[alby.gamper]

On Saturday, January 28, 2017 at 12:12:49 AM UTC+11, Dmitry A. Kazakov wrote:
> On 27/01/2017 13:49, alby.gamper@gmail.com wrote:
> 
> > Is their any general interest in using Visual Studio as an IDE for ADA
> > development ? (Not as a replacement to GPS, but rather as an alternative
> > for those teams primarily working on Windows based environments)
> >
> > I have a pre Alpha solution that currently operates under Visual
> > Studio 2015 (express/community edition) which covers the following
> > functionality.
> >
> > 1) Project templates for console/GUI apps and static and shared libraries
> > 2) Project configuration for most GNAT compiler, binder, linker options
> > 3) Rudimentary syntax/keyword highlighting
> > 4) GPRBUILD integration (ie MSBuild uses/invokes GPR project files)
> > 5) GDB integration
> >
> > But note the following limitations/caveats apply
> >
> > a) A working native GCC toolchain must already be installed (either GNAP GPL or
> > a Mingw32 environment should work fine)
> >
> > b) Some work needs to be done to support multilib (ie x86 vs x64)
> >
> > c) No GUI designer is available (ie winforms, WPF, XAML)
> >
> > d) I have a rudimentary binding to WinRT, BUT this is limited to NON GUI
> > functionality, since XAML  and Windows Composition API's seem to require a
> > sandboxed/windows Store environment to run under ?
> >
> > I am more than willing to show some screen shots to demonstrate the current
> > functionality
> >
> > Your thoughts/feedback are welcome
> 
> As for me I see no reason using Visual Studio so long MS linker and MS 
> debugger are not used. Main headaches are gcc linker (becoming 
> exponentially slower with each added library) and GDB (unusable).
> 
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de

Dear Dmitry

As mentioned, my solution does not depend upon MS linker or debugger. It uses
the underlying GCC/GNAT toolchain. I cant comment on the GCC linker, BUT the
GDB Visual Studio integration seems ok to me (I actually use Microsoft's own
open source MIDebug engine see https://github.com/Microsoft/MIEngine )

Alex

Re: Visual Studio IDE - Integration

[Scott Loyd]

I'd be interested in such a plugin if it improves debugging, but I would have to see it to believe it. GDB is just so bad in my experience and unfortunately a better (free) tool hasn't been developed in 30 years, at least that I'm aware of. GPS makes a good editor/build environment, but the debugging interface which uses GDB is terrible.  I have to believe a similar interface to Visual Studio would have similar results, but I'm willing to try it.

Re: Visual Studio IDE - Integration

[alby.gamper]

On Tuesday, February 7, 2017 at 5:36:38 AM UTC+11, Scott Loyd wrote:
> I'd be interested in such a plugin if it improves debugging, but I would have to see it to believe it. GDB is just so bad in my experience and unfortunately a better (free) tool hasn't been developed in 30 years, at least that I'm aware of. GPS makes a good editor/build environment, but the debugging interface which uses GDB is terrible.  I have to believe a similar interface to Visual Studio would have similar results, but I'm willing to try it.

Dear Scott

Being relatively new to Ada, I had not realized GDB has such a bad reputation.
But I believe I have three possible solutions, these being

1) continue using GDB, this at least integrates most of the important VS 2015
debug related windows (ie watchpoints, locals, tasks, registers etc...)

2) investigate use of LLDB

3) convert the DWARF debug info to Microsoft PDB format, and then use the VS2015
supplied debugger. Ive done some work on this already, and the results look very
promising (step into/out work much better than GDB, and disassembly includes the
original Ada source code as well)

The only thing that bugs me :-) is that local symbols are all converted to
lowercase (both for option 1) and obviously 3) I assume this is expected ?

Is their a compiler/linker switch to preserve the case of symbols in the DWARF
debug info ?

Thanks for your feedback

Alex

Re: Visual Studio IDE - Integration

[Hadrien Grasland]

Le mardi 7 février 2017 04:47:25 UTC+1, alby....@gmail.com a écrit :
> On Tuesday, February 7, 2017 at 5:36:38 AM UTC+11, Scott Loyd wrote:
> > I'd be interested in such a plugin if it improves debugging, but I would have to see it to believe it. GDB is just so bad in my experience and unfortunately a better (free) tool hasn't been developed in 30 years, at least that I'm aware of. GPS makes a good editor/build environment, but the debugging interface which uses GDB is terrible.  I have to believe a similar interface to Visual Studio would have similar results, but I'm willing to try it.
> 
> Dear Scott
> 
> Being relatively new to Ada, I had not realized GDB has such a bad reputation.
> But I believe I have three possible solutions, these being
> 
> 1) continue using GDB, this at least integrates most of the important VS 2015
> debug related windows (ie watchpoints, locals, tasks, registers etc...)
> 
> 2) investigate use of LLDB
> 
> 3) convert the DWARF debug info to Microsoft PDB format, and then use the VS2015
> supplied debugger. Ive done some work on this already, and the results look very
> promising (step into/out work much better than GDB, and disassembly includes the
> original Ada source code as well)
> 
> The only thing that bugs me :-) is that local symbols are all converted to
> lowercase (both for option 1) and obviously 3) I assume this is expected ?
> 
> Is their a compiler/linker switch to preserve the case of symbols in the DWARF
> debug info ?
> 
> Thanks for your feedback
> 
> Alex

To clarify, GDB is actually pretty awesome as a command-line tool. But no one has ever bothered - or managed - to write a good GUI frontend for it.

Re: Visual Studio IDE - Integration

[Dmitry A. Kazakov]

On 07/02/2017 08:46, Hadrien Grasland wrote:

> To clarify, GDB is actually pretty awesome as a command-line tool.
> But  no one has ever bothered - or managed - to write a good GUI frontend 
for it.

In fact GPS has a pretty cool debugger's front end. It has a bit less 
comfortable debugging interface than Visual Studio's, but still all 
bells and whistles.

IMO GPS is far better than latter incarnations of Visual Studio. Since 
VS 2005 it goes clearly down the slope. The only thing where Studio is 
better than GPS is debugging. [*]

The problem is that it becomes usable when the project gets any larger 
and more complex.

Knowing that AdaCore has awesome software designers and that other parts 
of the tool-chain are working seamless, I put blame squarely on GDB.

-----------------
* And MS linker. GNU linker is a disaster with regard to performance. It 
takes literally an hour to link a large stand-alone relocatable library.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Visual Studio IDE - Integration

[alby.gamper]

On Tuesday, February 7, 2017 at 7:37:18 PM UTC+11, Dmitry A. Kazakov wrote:
> On 07/02/2017 08:46, Hadrien Grasland wrote:
> 
> > To clarify, GDB is actually pretty awesome as a command-line tool.
> > But  no one has ever bothered - or managed - to write a good GUI frontend 
> for it.
> 
> In fact GPS has a pretty cool debugger's front end. It has a bit less 
> comfortable debugging interface than Visual Studio's, but still all 
> bells and whistles.
> 
> IMO GPS is far better than latter incarnations of Visual Studio. Since 
> VS 2005 it goes clearly down the slope. The only thing where Studio is 
> better than GPS is debugging. [*]
> 
> The problem is that it becomes usable when the project gets any larger 
> and more complex.
> 
> Knowing that AdaCore has awesome software designers and that other parts 
> of the tool-chain are working seamless, I put blame squarely on GDB.
> 
> -----------------
> * And MS linker. GNU linker is a disaster with regard to performance. It 
> takes literally an hour to link a large stand-alone relocatable library.
> 
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de

Dear Dmitry

I've looked at using gcc to compile a simple hello world app in "C" and then
link using the MS linker. This does work (after a bit of tweaking. However
Ada/gnat is a bit harder due to the additional RTS/mingw dependencies and
VC 2015 runtime has dropped of support for some legacy routines (for example
__iob_func ...)

I believe the best approach may be to built the RTS using gcc and then link
using MS linker. Once that is done, then linking normal apps against this new
RTS should be straight forward.

Problem is I have little documentation available on how to rebuild the actual
RTS (I can compile the Ada sources, but their is a bunch of "C" files that also
need to be compiled, and subsequently linked to produce the RTS (ie libgnat.a)

Thanks

Alex

Re: Visual Studio IDE - Integration

[alby.gamper]

On Wednesday, February 8, 2017 at 2:41:15 PM UTC+11, alby....@gmail.com wrote:
> On Tuesday, February 7, 2017 at 7:37:18 PM UTC+11, Dmitry A. Kazakov wrote:
> > On 07/02/2017 08:46, Hadrien Grasland wrote:
> > 
> > > To clarify, GDB is actually pretty awesome as a command-line tool.
> > > But  no one has ever bothered - or managed - to write a good GUI frontend 
> > for it.
> > 
> > In fact GPS has a pretty cool debugger's front end. It has a bit less 
> > comfortable debugging interface than Visual Studio's, but still all 
> > bells and whistles.
> > 
> > IMO GPS is far better than latter incarnations of Visual Studio. Since 
> > VS 2005 it goes clearly down the slope. The only thing where Studio is 
> > better than GPS is debugging. [*]
> > 
> > The problem is that it becomes usable when the project gets any larger 
> > and more complex.
> > 
> > Knowing that AdaCore has awesome software designers and that other parts 
> > of the tool-chain are working seamless, I put blame squarely on GDB.
> > 
> > -----------------
> > * And MS linker. GNU linker is a disaster with regard to performance. It 
> > takes literally an hour to link a large stand-alone relocatable library.
> > 
> > -- 
> > Regards,
> > Dmitry A. Kazakov
> > http://www.dmitry-kazakov.de
> 
> Dear Dmitry
> 
> I've looked at using gcc to compile a simple hello world app in "C" and then
> link using the MS linker. This does work (after a bit of tweaking. However
> Ada/gnat is a bit harder due to the additional RTS/mingw dependencies and
> VC 2015 runtime has dropped of support for some legacy routines (for example
> __iob_func ...)
> 
> I believe the best approach may be to built the RTS using gcc and then link
> using MS linker. Once that is done, then linking normal apps against this new
> RTS should be straight forward.
> 
> Problem is I have little documentation available on how to rebuild the actual
> RTS (I can compile the Ada sources, but their is a bunch of "C" files that also
> need to be compiled, and subsequently linked to produce the RTS (ie libgnat.a)
> 
> Thanks
> 
> Alex

Dear Dmitry

I have managed to build a new RTS (libgnat) using the MS linker and a small test
Ada application that links against this RTS using the MS Linker. The bad news is
that all debug info is lost in the process. I believe the info is still in the
final exe, but the relevant DWARF ".debug_xxx" sections get renamed to 8 chars
by the MS linker and no longer usable/convertable !

Alex

Re: Visual Studio IDE - Integration

[Dmitry A. Kazakov]

On 2017-02-12 01:49, alby.gamper@gmail.com wrote:

> I have managed to build a new RTS (libgnat) using the MS linker and a small test
> Ada application that links against this RTS using the MS Linker. The bad news is
> that all debug info is lost in the process. I believe the info is still in the
> final exe, but the relevant DWARF ".debug_xxx" sections get renamed to 8 chars
> by the MS linker and no longer usable/convertable !

Sorry, I don't know much about MS internals, but isn't it a pdb file 
that contains debug information?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Visual Studio IDE - Integration

[alby.gamper]

On Sunday, February 12, 2017 at 7:25:13 PM UTC+11, Dmitry A. Kazakov wrote:
> On 2017-02-12 01:49, alby.gamper@gmail.com wrote:
> 
> > I have managed to build a new RTS (libgnat) using the MS linker and a small test
> > Ada application that links against this RTS using the MS Linker. The bad news is
> > that all debug info is lost in the process. I believe the info is still in the
> > final exe, but the relevant DWARF ".debug_xxx" sections get renamed to 8 chars
> > by the MS linker and no longer usable/convertable !
> 
> Sorry, I don't know much about MS internals, but isn't it a pdb file 
> that contains debug information?
> 
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de

Yes the PDB does contain the debug information, However it, as I understand it
produced by the linker (be it LD or MS link) based on both the symbolic info
in the underlying "o"/"obj" files and other debug info available in the O/obj
files such as source line number -> address translation/mapping (used to set
breakpoints etc...)

The issue with using MS Linker is that it does not understand the DWARF debug
info produced by the GCC compiler (and hence ignores it)

Their is a utility (open source) called cv2pdb that can take a GCC compiled and
linked app and produce a PDB, but the app must have been compiled/linked with
GCC as a starting point.

I believe a possible solution is

1) enable GCC to natively support/produce PDB debug info. The MS documentation
on the PDB format is now publically available, and as I understand it the LVVM
project (ie CLANG) can already produce either DWARF, CV or PDB debug info. This would entail developing a "debug hook" provider within the GCC source. Not a
trivial task

Your thoughts are welcome

Thanks Alex

Visual Studio IDE - Integration

[Leff Ivanov]

I'd rather be interested in having Visual Studio Code plugin for Ada development, which is a quite good crossplatform editor based on Electron shell.

Re: Visual Studio IDE - Integration

[alby.gamper]

On Saturday, February 4, 2017 at 5:09:31 AM UTC+11, Leff Ivanov wrote:
> I'd rather be interested in having Visual Studio Code plugin for Ada development, which is a quite good crossplatform editor based on Electron shell.

Dear Leff

I had briefly looked at "Visual Studio Code", but felt that "Visual Studio 2015"
offered facilities for deeper integration. Being cross platform capable was not
the main criteria in selecting VS 2015. Also VS 2017 will be available on OSX and
I suspect a Unix/Linux port may follow ?

Alex

Re: Visual Studio IDE - Integration

[Aurele]

The only time I'll use the Window's Visual Studio IDE is when creating and/or maintaining Resource (RES) files which I can then use directly with the GNAT GPS Ada compiler/linker. 

Re: Visual Studio IDE - Integration

[Ivan Levashev]

27.01.2017 19:49, alby.gamper@gmail.com пишет:
> Dear Ada Community
> 
> Is their any general interest in using Visual Studio as an IDE for ADA
> development ? (Not as a replacement to GPS, but rather as an alternative
> for those teams primarily working on Windows based environments)

I used to want Ada in Delphi IDE (BDS, RAD) as yet another language in
addition to C++ and Delphi. But for good developer experience that also
implies embedding cross-platform GUI builder which is always a hard
choice. Personally I'm Cocoa proponent. And I'm neither FireMonkey nor
VCL propoment. Cocoa is ARC, and VCL and FireMonkey are unconvenient
single referenced frameworks.

> d) I have a rudimentary binding to WinRT, BUT this is limited to NON GUI
> functionality, since XAML  and Windows Composition API's seem to require a
> sandboxed/windows Store environment to run under ?

Recent Delphi and C++ Builder solved this via Centennial loophole. They
are distributing Starter keys for free currently so you can investigate
how do they handle WinRT. There is a report on their work:

https://community.embarcadero.com/blogs/entry/windows-10-from-winrt-to-centennial-with-marco-cantu

Those dirty secrets Microsoft is not going to tell you, only 3rd party
vendords are, and just as always we are step behind Delphi when it takes
to UI stuff, so they are exploring WinRT and Cocoa before us.

Marco Cantu got to the Windows Store with Delphi program, so with Ada
it's also possible.

Best Regards,
Ivan Levashev,
Barnaul

--
If you want to get to the top, you have to start at the bottom