Search code examples
cmakebuildlinkerlibraries

CMake linking and by-products in build directory

I'm new to CMake. Therefore, I have several questions which I don't want to split into separate threads, because they are fairly small and related. Long story short, let's look at this linking invocation:

/D/Software/MinGW/bin/g++.exe   -fmessage-length=0 -mfpmath=sse -msse2 -msse3 -mssse3 -msse4 -fopenmp -g    -Wl,--whole-archive CMakeFiles/go.dir/objects.a -Wl,--no-whole-archive  -o go.exe -Wl,--out-implib,libgo.dll.a -Wl,--major-image-version,0,--minor-image-version,0  /D/Software/Qt/4.8.0/lib/libQtOpenGLd4.a /D/Software/Qt/4.8.0/lib/libQtGuid4.a /D/Software/Qt/4.8.0/lib/libQtCored4.a -lglu32 -lopengl32 -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32
  1. Why CMake tends to add compile options to link options? For instance, SSE options are simply irrelevant in this case.
  2. Why does it link me with some weird libraries kernel32, winspool, shell32, ole32, uuid, comdlg32, advapi32? When I was building the same project with QMake - there were none of these libraries. Moreover, I don't even know the purpose of these ones. So, it looks like these libraries are redundant, or am I wrong?
  3. I can't see the list of linked object files. However, I notice this -Wl,--whole-archive CMakeFiles/go.dir/objects.a -Wl,--no-whole-archive -o go.exe -Wl,--out-implib,libgo.dll.a part which is unknown to me. But, I guess that all object files are somehow archived into objects.a, and therefore this part of linking essentially is the same as the explicit list of object files, isn't it?
  4. I guess I don't have to worry about that, but I'm curious about the build folder - so much garbage out there:

enter image description here

Is it intended behavior of CMake to produce so many by-products of build process? Also I'm completely confused about a.exe - what's that? Why should it ever reside in my build directory?

Solution

  • wrt 4)

    The a.exe files (or more specifically the folders the reside in) look like binaries CMake used to determine the existence of certain compiler features.

    In any case the amount of files you have there looks perfectly fine for CMake. Some of them are really useful for advanced debugging if something in the configuration and build process failed and I think its hence a good practice of CMake to keep them alive.