The example projects provided with the MKL to create a customized minimal redist dll have the paths to the included LIB files hardcoded instead of using $(MKLROOT), this means once the projects are copied away from the MKL install directory they fail to build with error "LNK1131: no library file specified".
Removing the .lib file from the project and adding it to the project properties, as well as adding $(MKLROOT)\\lib to the library paths fixes the problem.
Currently these MS-projectsfor custom buildercan be used only intheir location and have relative path to lib-directory. We will consider possibilty to use MKLROOT instead but then MKL custom builder has to require correct MKLROOT vallue (setting MKL environment via mklvars)
- are they useful at all in comparison with command line interfcae of custom builder
- what is to be added in MKL custom builder from your point of view
- any suggestions/comments
I'll be honest, I used the projects because I found the documentation for those first while searching for a way to reduce the redist footprint. Using the command line interface probably would have been easier, by just making a new dedicated makefile project which calls it - the key point was, I needed some sort of VS wrapper around the creation of the dedicated DLL because our build server uses msbuild, and I did not want to add special casing on the build server side of things. Perhaps the three subprojects could be replaced with a single makefile project?
I also ended up merging the 32 and 64 bit versions of the i_malloc_dll and vml_dll_core projects, we use the same solution for 32/64 bit builds.
It would be nice if the MKL plugin for the VS project configuration could have an additional option, "use custom DLL", because right now I have to disable the use of MKL in the plugin and manually add the include paths to the project, otherwise I think the MKL default libs have priority.