I would like to share a result that I got when compiling Kicad for Windows.
Kicad depends on several thirdy party libraries.
One of these is HarfBuzz.
HarfBuzz can be compiled for using unicode support from external libraries, GLIB and ICU.
This is a good choice because it is useless to reinvent the wheel every time.
However, if those libraries are not available, HarfBuzz can be compiled for using its internal, fully featured Unicode support.
Typically, this may be not required, but on Windows it would be worth to evaluate some benefits.
By recompiling HarfBuzz without GLIB and ICU support, the Windows version can avoid to provide these libraries and all their dependencies.
Since libgobject-2.0-0.dll is not included into the installer, it also seems to me that some extra DLLs are just useless.
In short: according to Dependency Walker tool, GLIB and ICU are required only by HarfBuzz. By recompiling Harfbuzz without GLIB and ICU, I was able to trash about 45 MEGABYTES of shared libraries and dependencies from the installation directory, without any effect on Kicad.
I understand that Kicad is currently using pre-compiled libraries from MINGW-W64.
Evidently, those libraries are compiled to be used in all possible conditions.
However, after looking this result, perhaps it would be worth to think if Harfbuzz can be compiled by You for saving a waste of disk and memory usage.
Of course, the binary files of Kicad are not affected and the action is totally tranparent for the user: they will work with libraries from MINGW-W64 repository or with your libraries without distinction.
I’m reporting these results with the hope that it could be helpful.
Sincerely.
PS: Do you think it would be worth to file an issue for this?
Harfbuzz is not the only package we depend on that needs ICU or GLIB, Boost needs ICU and Cairo needs GLIB. Also, rebuilding Harfbuzz would necessitate rebuilding Freetype and Cairo, which could open up more possible issues for us. In general, we try to avoid having custom builds of dependencies if at all possible.
Two modules of Boost are linked to ICU:
libboost_locale-mt.dll
libboost_regex-mt.dll
But I have to say that I have not found any error when using Kicad.
Evidently, not all Boost libraries are used, I think.
It is not clear to me the reason because you wrote “rebuilding Harfbuzz would necessitate rebuilding Freetype and Cairo”.
However, as I have written, I understand that you prefer to use precompiled libraries, Kicad is an already complex task and rebuilding dependencies should be avoided if not strictly necessary. I just wanted to share my results.
It is not clear to me the reason because you wrote “rebuilding Harfbuzz would necessitate rebuilding Freetype and Cairo”.
It isn’t very obvious and you have to dive into the build scripts to see this. There is a circular dependency between Harfbuzz and Freetype, and then Cairo depends on Freetype (and also Harfbuzz can depend on Cairo…).
If you modify one of them, you should really build the others again in case there was some subtle change, so you can see how complicated this can get.
Cairo does not need GLIB
I misread it, that is a build-time dependency on Cairo, not a run-time dependency.
It isn’t very obvious and you have to dive into the build scripts to see this. There is a circular dependency between Harfbuzz and Freetype, and then Cairo depends on Freetype (and also Harfbuzz can depend on Cairo…).
Yes, I knew it. So you were talking about that, but actually, it not too difficult to rebuild properly, at least in my opinion.
However, I have to say that this strange thing on Boost left me suspicious, so I tried to do some experiments. By looking the official executables with an hex viewer, I can clearly see the use of Boost into the code (look this for example):
I hope that you will excuse my (perhaps) stupid question but… are you sure that you linked with import libraries instead of static libraries of boost?
Try to do this experiment: go into your program files directory, enter into Kicad\bin and move all libboost*.dll files outside this location. Finally, run Kicad again and try to do the usual things, like opening a schematic and so on. Everything still works, even without the DLLs that you just moved.
Hmm, so we might not be depending on any of the non-header functions in Boost for normal users. A lot of Boost is a header-library, with only small parts of it actually requiring shared libraries. In the past I think we depended on some of the non-header portions, but that may have changed.
