Troubleshooting Common Errors while building with Conda on Windows
Often when building a new package as is, or when changing a recipe, the build will crash at some point with an error message. This is usually contained in the output conda-build gives you and which you should redirect into a file. When redirecting the output into a file, e.g. using conda build something --some-options > log.txt, remember to also redirect the error output stream, like this conda build something --some-options > log.txt 2> error.txt or, if you want both streams into one file conda build something --some-options > log.txt 2>&1.
If you have the output, you can then analyse when and why the build crashed. Here is a list of common errors while building with conda-build, as well as some steps you can try to resolve them.
Sometimes during building a window will open, telling you that the proces Patch: apply a diff file to an original is no longer working (possibly multiple times). If that happens, check whether the patch file you're trying to apply has the correct end-of-line-style (e.g. \r\n for Windows). If not, change it using an editor like Notepad++.
Sometimes conda complains about unfulfillable requirements in the recipe when creating either the build, run oder testing environment.
To make sure that the required packages are compatible, try creating a temporary environment yourself and manually installing all packages into them. Modify the required packages or versions if necessary.
If you can successfully install all the required packages, make sure that conda-build uses the correct channels during installation. If necessary, add channels using -c CHANNEL in the order of preference, or override channel preferences altogether using --override-channels.
This is an annoying bug in conda-build at the time of writing. Sometime removing the testing part from the recipe can fix this, but in other cases there is only the workaround of making sure that both builds succeed.
If only the second build is failing, that usually means that some changes were made to the conda recipe, namely the meta.yaml and/or bld.bat, which are not included in the original source files. In this case, you can create a patch that contains the changes to these files and add it to the recipe, so that the second build also uses the correct recipe file. The build will still complete twice, creating two (more or less) identical files.
First make sure, that the required library is actually included in the build requirements in meta.yaml and locate it in the environment temporarily created by conda-build.
Ensure that the recipe requires a sufficiently new version of CMake, e.g., in the meta.yaml under build, and in the CMakeLists.txt using cmake_minimum_required (VERSION X.Y FATAL_ERROR).
Give hints to CMake regarding the install location of the package. Which flags exactly work depends on the packages. For example, for hinting the location of boost you can use the flags BOOST_ROOT, BOOSTROOT, BOOST_INCLUDEDIR or BOOST_LIBRARYDIR by adding them to the CMake command in the bld.bat with -DBOOST_ROOT=PATH\TO\FOLDER.
In the CMakeLists.txt files search for find_package( Boost REQUIRED COMPONENTS python ) and correct it to find_package( Boost REQUIRED COMPONENTS python3 ).
This is a very common error and it rarely ever means that the dll could not be opened, but rather that it was not found.
First locate the dll in the temporary build directory (conda/conda-bld/PACKAGE_1234567890/_h_env) to make sure, it actually exists, and note it's relative path (e.g. /libs/python35.dll). Also make sure you have the correct version, e.g., python3.dll =/= python35.dll.
Next you have to verify that Visual Studio's Linker includes the dll. Open the project file that was created by CMake (usually in the /work/build subdirectory) using Visual Studio. Navigate to the Property Manager-Sheet (usually on the right side, next to the Solution Explorer) and look at the properties of the project that fails to build (rebuild, if you're not sure, but remember to change the build type to Release).
Under Linker -> Input -> Additional Dependencies , there is a list of dll files. Check if the library that could not be opened is also included.
If the library is missing, you need to add or modify the target_link_libraries command in the CMakeLists.txt files (see also Creating Patches).
To check whether your modification to the CMakeLists.txt worked, you can run the ZERO_NO_CHECK project which calls CMake and updates the Visual Studio project.
If the library is included but cannot be found, it means that Visual Studio is searching for it in the wrong places. You need to modify the PATH variable to include the path to the library. This is best done in the bld.bat using set PATH=%PATH%;%LIBRARY_PREFIX%\bin or similar. You can test whether changing the variable works either by setting it temporarily (e.g. via User Macros in Visual Studio; remember to remove it again), or by running the bld.bat again in the /work/ subdirectory after calling activate ..\_h_env\.