According to the documentation a full compile of the UE4 source shouldn't take longer than 40 minutes.
I am trying to compile UE 4.27 using VS 2017 in Windows and its taking all day!
The instructions simply say to select the UE4 project in Solution Explorer, right click and select 'Build.
I can see every single module being compiled ie
455/4705] Module.SequenceRecorder.gen.cpp
How can I speed up compilation times?
Unreal Engine is a massive piece of software.
Your compile times will depend on a lot of factors, most importantly the hardware your compiling with.
The 40 minutes compile time is only a guideline estimate, they cannot guarantee that across all specs.
https://answers.unrealengine.com/questions/3647/how-to-improve-compile-times-for-a-c-project.html
I want a latest version of GCC for Windows.
Now the latest version is 9.2 but for Windows via MinGW it is just 8.1...
I have tried to build from source for Windows 10 include WSL, but have not found how to do it exactly, I do not want use via CygWin or other emulater, just real on Windows as clang and MSVC.
Note: I have Windows 10 latest version with WSL.
The latest version of GCC (9.2.0) compiler combined with the latest MinGW-w64 (7.0.0) headers and libraries can be found in the standalone build at http://winlibs.com/
Oh the pain, getting a working GCC for Windows.
build your own?
Building is a fun experience, or a no-fun experience, depending on how you look at it.
I've spent literally weeks of time building GCC successfully and unsuccessfully (native and cross). Follow the instructions to the letter, and it works. And then, another day, it doesn't work (with the slightest different sub-sub-release or revision, or the tiniest little change that is entirely "harmless", or to the best of your knowledge no change at all, and you never get it to build again).
Save everything you've done (copy console), keep the build tree, and repeat the build (paste text) 6 months later after first doing a svn update. Compiles fine for 15-20 minutes, then fails. Start from scratch, and spend a day or two until it works, and you cannot tell why it works now.
Use a build script by someone who offers binary builds (so the assumption is that it must work, otherwise where do the binaries come from). The build script more or less does exactly what you've done by hand anyway, and it works, or maybe doesn't work. If you are only interested in actually having a compiler that works for compiling under Windows, and not in spending your life fiddling around, that's not a lot of fun.
use a pre-built binary?
There exists serval binary distros from a variety of sources.
Although downloading binaries is of course always a tidbid risky (even when scanning everything before you run it, malware scanners are nowhere near perfect, or even good or halfway reliable), compilers are particularly high-risk. That's because compilers are a very interesting target for malware distributors as they get free redistribution with everything you build.
I've actually seen GCC builds with malware built-in on apparently harmless sites (forgot the name, but one such example was a site offering GCC builds for several architectures, which looked very nice).
Now... there exists a distro which supports GCC 9.2 since some time built by someone under the pseudonym "nuwen".
It turns out, that "nuwen" is actually Stephan T. Lavavej, so... chances are that this is a distro that you actually want to use (I'm using it anyway). It's unlikely that you will be able build one yourself that's substantially better (also that one has a lot of useful support libs already coming with it), and it's unlikely that it is harmful.
https://nuwen.net/mingw.html
Note that MSYS2 will also allow you to install a very recent GCC (9.1 or 9.2, not sure) via pacman, very fast and very trouble-free. MSYS2 is nice insofar as you get a 95% working Unix-like working environment with 95% of the tools.
And 95% of the time, it works fine in every practical respect. Until then, one day, it doesn't, usually related to some configure script messing up pathnames, or something with environment variables. Or something else very subtle. For example, it is very much possible to successfully build GCC with MSYS2 (I've done it), and it works "perfectly fine" until some weeks later you discover that something doesn't work in your custom build, so some old project of yours now suddenly doesn't build any more when it did with the old stock compiler.
That's probably issues that one could fix, if determined (I'm however too lazy, for me a compiler is something that simply must work).
There are two well known distributions of the GCC bundle for Windows. The first one is by equation.com
http://www.equation.com/servlet/equation.cmd?fa=fortran
and the second one is by winlibs.com
http://winlibs.com/
I have a program that takes a lot of memory and time to compile. I measured that without debugging symbols, compilation takes much less resources, but I would like to always have them, even for "release" builds so that I crash dumps are meaningful.
Is it possible to create debugging symbols (-ggdb3) with either gcc or clang for an executable that has not been originally compiled with them? I've been told that just recompiling the program with -ggdb3 works, but I don't know how much this is reliable.
Assuming the build chain is deterministic, which is a highly desirable goal for tool chains, and assuming you have not changed the source in any meaningful way (which practically means in any way at all), then running it again will be reliable. However, I am sure it is possible to demonstrate examples when this doesn't go as planned. So, as your intuition suggests, building the debugging symbols simultaneously should be considered a Good Thing.
(I am using Codeblocks on Debian Linux with the GNU GCC Compiler)
I created a game with sfml and everything works really well unless i implement the usual
while (window->pollEvent(event)){
//optional code
}
loop.
I have tried the same code on Windows with MS Visual Studio and it worked perfectly fine. The game still laggs a lot even when I only execute the
window->pollEvent(event);
line only once, even if there is no event at all. Why does that line of code take so much time? (It takes as much time as about 10 frames would take without it).
Try doing window.pollEvent(event) instead of window->pollEvent, I have never seen this form of using pollEvent until now..
Why does making a C/C++ app take very long compared to other apps (Java for example).
I am trying to build Ubuntu Unity, and it takes about 4 minutes on my local machine.
I think the process of Generating object files is the one that take most time.
Any advice?
If you want to speed up code generation you can use ccache. Also you can take a look at gcc version as older versions are known to lag behind. Clang also supersede them a lot.
I'm not touching compilation speed bacause this is a HUGE topic. Starting from that C/C++ is a fully compilable languages, while in Java you never compile to the machine codes, you just generate a bytecode leaving everything else to the VM.