Slow gprbuild on windows - compilation

When I run a project build of an Ada project (gpr) on windows using gprbuild (whether in GNAT GPL or cygwin), it is very slow. Even a simple project compilation takes minutes. The same project compilation under Linux takes a few seconds. Is there a way to speed compilation up under Windows?

My experience is that compilation time is similar. However, I have noticed with updates to my antivirus on Windows this last year, that it now scans each and every program before allowing it to run. This slowed down my compilation drastically. I had to go into my antivirus and whitelist all the GNAT programs (gnatmake, gprconfig, etc.) or each step took several seconds.
It might be something to look at. With everything whitelisted, compilation time is about the same using GNAT GPL 2016, GNAT GPL 2017, and GNAT FSF 7.2 on mingw64 on windows and using the OS supplied GNAT on linux

Related

VisualStudio/Fortran parallelization causing "This app can’t run on this PC" Error?

I have Visual Studio 2015 installed on a modeling workstation, along with Portland Group’s PVF fortran (PGI Visual Fortran) version 18.7.
The code is written in Fortran, and I have converted some of it to F95 syntax.
The workstation has x64 OS, and I am trying to compile in x64.
I am not sure of all of the settings I need in compiling. I added a subroutine in which I want to start experimenting with parallelization. However, the current problem is that I compile successfully, but when I try to run the code, I get the error: “This app can’t run on this PC.” It is possible that the minimal parallelization directives that I included cause a problem, but online searches talk about x64 and x32 compatibility issues. I am not sure that those items are pertinent because they talk about installing and running commercial software.
Has anyone ever run into this error in compiling code in whatever language? If so, do you have a clue about the cause?

why does MSVC 2015 takes too much space

I have an installation of visual studio 2015 (french version). The installation itself take a lot of disk space. I have only C++ compiler installed without .net, C#, web and mobile developer toolkit.
Does anybody know what is the actual reason for too much disk space requirement compared to other C/C++ compiler toolkits (GCC, Clang).
another point:
Installing a language pack for english demands 4GB of disk space. Why it requires that much space where I am installing only a different language. I mean compiler executable remains same in this case. Just the internationalization parameters needs to be changed.
Is there any technical or commercial reasons to why Visual Studio do this.?
The installation itself take a lot of disk space. ... Does anybody know what is the actual reason for too much disk space requirement compared to other C/C++ compiler toolkits (GCC, Clang).
Because Visual Studio installs a heck of a lot more stuff than just a compiler toolkit like GCC or Clang. For example, it includes an IDE, an interactive debugger, a bunch of libraries, the source code for all of the included libraries, profiling and other tools, etc.
If you just want the compiler toolchain and not the IDE or anything else, download the standalone C++ build tools.
Or, for an earlier version of the build tools, just download the Windows SDK. (The build tools are no longer included starting with the Windows 8.1 SDK. Therefore, you'll need to get an older version, like the Windows 7 SDK.)

GNAT GPL 2016 Installation Hassle On Windows XP SP3

About 2 weeks ago I installed the new 2016 version of the GNAT GPL Ada/SPARK compiler and associated software tools.
But the damn thing won't work right.
Running existing projects on it, it just won't compile and shows some errors with Python files.
Anyone else experience this problem ?
I'm (still) using Win XP as the platform for the GNAT GPL dev tools.
EDIT
Just saw this on a ReadMe file : This version of GNAT GPL is officially supported on the following hosts. Please see the "Special Notes" section immediately following the targets section for special instructions relevant to specific platforms. PC/x86 and x86_64 - Windows Vista Business, 7, 8, 8.1, and 10 So it looks like GNAT 2016 won't run any longer on Win XP machines.
The errors seem to be in the jedi library, part of python.
Did you install in a new directory, or over an existing install ? I would recommend the former, so you likely should redo the install from scratch, and in a new directory.
I simply disable "jedi support" plugin inside Tools/Plugins and everything works perfectly. This plugin is completion for python editor, maybe you don't need it for ada.

dll dependency issue in windows with msvc runtime

I am trying to run a program that depends on Matlab 2010 binaries. Those depend on msvc80 dlls.
It worked fine a couple of days ago. Then I installed a new version of Matlab, and all hell broke loose. Note that I am still trying to run the same program depending on the same Matlab binaries.
I have :
Installed and uninstalled the latest msvc 2005 redistributable package.
Removed all occurence of Matlab 2014 from my path.
When I run dependency walker, it finds MSVCR80.DLL, but not always, I wonder if it is looking for another version?
http://imgur.com/jj2mUAV
I have tried copying the version it finds in the winsxs folder, but it leads to a runtime error saying I am trying to load the C runtime library the wrong way...
Where should I go now?

Windows Qt with MinGw or Visual Studios?

I am trying to compile qt, and am faced with two choices whether use MinGw or Visual Studio compiler? What is the difference between them, and are there any advantages/disadvantages of using one or the other?
They are both fine tools. The important thing to know is that they don't necessarily play well together. That is, as you link libraries together, they must all use the same tool chain. For this reason, in my opinion, it is better to use the Visual Studio compiler (MSVC), as it is the "first class citizen" on Windows; the others are treated somewhat as second class.
What I mean is that you can pretty much count on third party libraries being available in binary form using MSVC, or at least build instructions being available using MSVC. We had lots of problems with third-party libraries not being able to build in MinGW or having nonexistent build instructions and having to do a lot of manual Makefile editing, etc. You are much more likely to have things "just work" if using MSVC.
That is just our experience (we started with MinGW); your mileage may vary.
MinGW uses GCC, and GCC has one significant advantage to MSVC - it is portable. MSVC is limited to Microsoft platforms, GCC supports pretty much everything, including 8bit embedded CPUs. Meaning that you can use the same directives and compile extensions across different platforms.
Also, MinGW is compact, quick to install, and a version is even bundled with Qt. Unlike MSVC, which is not even available standalone, you have to install visual studio, which itself installs a bunch of garbage you don't need but can't opt out of.
UPDATE
It is now possible to get the MS compiler without VS, a.k.a MS Build Tools. Also, If you want to build chromium (a.k.a the QtWebEngine) for windows you have to use MSVC, that's a limitation imposed by google, as they only support building with the platform-native compiler.
Last but not least, you can get MSYS2, which has a repository with MinGW and a ton of ready to use static and dynamic libraries build for it, so you can avoid the arduous and often failure prone build process.
UPDATE
Just for the sake of reference, for VS build tools 2019, the C++ compiler alone takes up about 4.5 gigabytes of space, or about 8 if you just click "C++ build tools" and leave it at the default. For comparison, GCC 9.x is about 150 mb. In fact, the MSVC compiler alone is larger than the entire extensive collection of packages that I adopted for use throughout the years, plus their dependencies, for a total of over 200 packages. Additionally, I'd say MSYS had packages for about 98% of the libraries and tools I've found myself in need of, and those remaining 2% include libraries it had but were not configured in a way, suitable for my use case. And it goes without saying, the packet manager makes it trivial to keep versions up to date.

Resources