see question in No GNATtest in GNAT Community Edition?
On Windows 10, using GNAT CE 2020, when I build gnattest following the guidance in the ASIS package mentioned in the link, I still get an error when trying to generate a test harness (gnattest -Pgpr-file), gnattest reports: gnat1: invalid switch: -gnatt
Anyone who knows how to proceed ?
-gnatt is the switch that dumps ASIS information, and AdaCore are moving away from ASIS (well, as far as we unsupported users are concerned, have moved).
gnattest is one of the tools supported in libadalang-tools, which depends on libadalang.
Source for both of these is available on the AdaCore Community download page, but since gnattest was only moved from work-in-progress 3 months ago and the latest versions on the download page are dated April 30 I think you’d have to bite the bullet and download from AdaCore’s Github site, and you’d need Python 3.8+ as well.
My only experience of building libadalang and -tools is on macOS, so I don’t think I can help further than that.
Related
So I have a few AdaCore github libraries I need to clone and include in my project. However; they are not being picked up by GNAT studio -- cannot cross reference or build my project with them as they are not found. The particular one I'm dealing with at the moment is aws but I have a number of others I need to use so would like to spot my error before spending yet more time trying to fix this.
Note I followed the install process on aws, and this is on Ubuntu 20.04 using the latest GPL edition of GNAT from the AdaCore site.
So I need to know the correct paths where they should be in my installation.
You can check if a library is properly installed with command gprinstall --list If aws is on the list, then everything is ok, you can go to step 2. If not, please check once more the installation documentation.
I don't remember the UI of GNAT Studio, but you can edit your project file (this one which ends with extension .gpr, for example: myproject.gpr) in a text editor too. At the top of the project file add line with aws; (if you want to add aws library to your project) so GNAT can find the library. If you want to add another libraries, just add them under with aws; in similar manner. You can find their names by using gprinstall --list command.
Anyone try using Microsoft.Identy.Client package with Xamarin.Forms in MacOS project?
I try to implement OpenUrl method according to sample: https://github.com/Azure-Samples/active-directory-xamarin-native-v2/tree/master but in AppDelegate in MacOS project VS cannot see AuthenticationContinuationHelper class. Microsoft.Identity.Client class is limited:
Microsoft.Identity.Client in MacOS Project not show all items
At .Droid and .iOS project everything work properly.
Anyone was handled with this?
So there is a video from Build 2018 as well as the Slide Deck that discuss that. You need to make sure in your nuget settings you have the "show pre-release packages" checked, and then install the Microsoft.Identity.Client. I had the same issue until I did that, installed the nugets, cleaned and rebuilt the solution.
The problem with Xaramin.mac is that the library does not currently, nor does it sound like it will any time soon support the Xaramin.mac platform. This is mentioned in Open Issue #522 on the GitHub repository, after some further reading into it. That was dated on February 20th, with no news since then, so I don't believe they have it on their roadmap. Must be something with the way MacOS handles the brewer handoff, let alone the MacOS was just recently supported by some of their services in Azure, which makes me think there is not enough market share there yet in this space?
I'm a beginner on open source world.
I can compile my own C++ code in VS 2015. but, I have little knowledge about compiling open source code. I can't even find a project file of that.
Anyway, I'd like to compile Sigil 0.9.4 version from source. My system is Windows 10 64 bit, and Qt 5.6.0 is installed. I've been looking for any basic guide for that but I haven't found yet.
I have downloaded a source code zip file from the link
https://github.com/Sigil-Ebook/Sigil/releases
And I have no idea what's the difference between Sigil-0.9.4-Code.zip and Source code (zip).
Which one should I download to compile?
Intuitively, I used 'importing project' in Qt but I get message 'no rule to make target all. stop'
Any instructions for that?
Thank you in advance!!!
For compilation you will need to use CMake. I recommend going through their web-site and read about it.
If you look at the source repository of the software you are trying to build (Sigil), you will see the root folder contains CMakeLists.txt. This is the file that will tell cmake program how to build and configure the software.
If you are planning to use Qt as your IDE, I recommend to download and install cmake first. Then make sure, Qt's toolchain is set up properly with the cmake. Then all you have to do is to open that CMakeLists.txt in Qt (see more details in the aforementioned link). Also, you can find plenty other tutorials on how to use cmake to compile your projects.
Hope this will help you get started.
I am trying to set up references to the CRM 2011 sdk
Microsoft.Xrm.Sdk.dll
Microsoft.Xrm.Portal.dll
Microsoft.Xrm.Client.dll
While trying to use the CrmSvcUtil.exe to generate the early bound types for CRM, I get an error Microsoft.Xrm.Client.CodeGeneration.dll cannot be located. I could not locate the dll in any of the packages that I downloaded using Nuget PM.
Can anybody advise on the usage and how to obtain this?
Use the Early Bound Generator in the XrmToolBox Tool Store. It contains the functionality to generate code using the Xrm.Client. Or if you really just want to use the DLL and do everything by hand, it contains the DLL in the download.
Update
As of March 2020, the EBG no longer supports the deprecated Microsoft.Xrm.Client usage. Hopefully you've transitioned off of that. You can still download older versions of the EBG on NuGet if you're stuck on that client generation.
I come from UNIX world, I'm quite familiar with Linux, Solaris, Cygwin
and MinGW development. Recently I ported one of my
big projects (cppcms) to support MSVC,
including building static and dynamic libraries with CMake.
And I get all the time absolutely weird issues:
I had CMake build issues because Windows programming
lacks naming convention
for import and static libraries.
Now I discovered that I should use different versions of ICU (debug/release builds) according to the
actual build I do (Debug/RelWithDebInfo -- should use Debug ICU, Release release ICU) and so I should
change actual conventions for searching libraries according to debug/release mode only under MSVC.
Otherwise application just would not start giving a error on missing DLL.
I don't have any such issues under Mingw or Cygwin with GCC, Open Solaris with Sun Studio or Linux with gcc or intel compilers.
And I still have numerous wired issues and wired bugs and very strange behavior -- even some trivial things do not work
under MSVC builds, when everything works absolutely fine under Solaris/Linux/Cygwin/Mingw using GCC from 3.4 up to 4.4,
Sun Studio and Intel compilers). But not under MSVC.
To be honest, I have no idea how to deal with Last one! Because it looks like for me more like environment issues.
I know that the question is not really well defined. I think I'm quite experienced
developer and I know how to write portable and good C++ code. But using Microsoft native
tools drives me crazy with issues I just don't know how to solve.
Question: What should experienced Unix programmer with quite good base in Win32 API should know when it
starts using Genuine Microsoft Tools?
P.S.: Can someone explain why "Release With Debug Info" requires Debug version of MSVC runtime? And why there two versions of runtime exist at all?
P.P.S.: Please note I don't have issues with Win32 API, in fact Windows GCC build works absolutely fine.
Clarifications:
I'm looking for pitfalls that programmer that come from Unix world would may fall into.
For example, when moving from Linux to Solaris: make sure you compile code with -mt or
-pthreads when using multi threaded programs, linking with -lpthread is not enough.
P.S.: Can someone explain why "Release
With Debug Info" requires Debug
version of MSVC runtime?
It doesn't.
And why there
two versions of runtime exist at all?
Because the debug version does more error checking.
And I still have numerous wired issues
and wired bugs and very strange
behavior -- even some trivial things
do not work under MSVC builds,
* What am I doing wrong?
Not telling us what "wired issues and wired bugs and very strange behavior" you get.
* Where should I start?
By telling us the specific errors and problems you encounter.
* What do I miss?
Reading the documentation and learning the tools.
If your question is "What do I read to become a good Windows programmer?" then my answer is: Everything from Jeff Richter, as a start.
There is no magic bullet which will automatically make you an experienced Windows developer. Windows is a very different land compared to Unix. There are lots of quirks, weird behavior, and stuff which is just plain different. The only way to get out with your sanity intact is to tackle the transition one small problem at a time. Concentrate on a specific problem and try to understand the problem. Don't just "get it to work", but really understand what is happening. A good book about Windows programming will help.
There are huge amounts of Windows knowledge and experience accumulated in the SO community, but the only way to access it is to ask concrete questions about specific problems.
The release and debug versions of DLL's use different ways of allocating memory, that is why it is not advisable to mix release and debug versions. If you allocate something in a debug mode DLL and pass it back to the application which was compiled in release mode you may get into trouble.
In the case of your naming issues you may want to have different directories where you place your static / dll's. You can do do this in visual studio by using the configuration manager, not sure how it is under the express version.
I think you need to try and actually understand the new toolset rather than just try and squish it into your current understanding of your existing tools. For that, the best way, IMHO, is for you to try and start to use Visual Studio as Microsoft intended and then once you can build a simple project in the IDE you can move to building it using your preferred make system but do so with an understanding of how the IDE is using its make system to set things up for that build (which WILL work).
So, for example, for part 1 of your question you want to create a simple static library project and a simple dll project and look at the linker options tabs. Jump to the 'Command line' view and you'll see that a DLL uses the /OUT linker option to set the name and location of the dll file and the /LIB linker option to set the name and location of the import library. With a static library only the /OUT option is used and it indicates the name of the static lib. It's true that if you're building a static lib and a DLL from the same source and you have both the /LIB for the dll set to MyCrossPlatformCode.lib and /OUT set to MyCrossPlatformCode.dll then you may have problems if you also build a static lib with an /OUT switch of MyCrossPlatformCode.lib... Simply don't do that; either build the static libs to a different output directory (which is what OpenSSL does), or, better (IMHO), mangle the names somewhat so that you have MyCrossPlatformCode.lib/.dll and MyCrossPlatformCode_static.lib (which is what STLPort does).
Note that you might also want to mangle in (or account for) building with different versions of the Microsoft tool chain (so you might end up with stlport_vc8_x64d_static.5.1, perhaps).
An alternative approach, if you really can't face the thought of understanding your toolset, is that you could take a look at some of the popular open source systems that build quite fine on Windows and Unix systems; OpenSSL and STLPort for a start, perhaps.