Building errors and solutions on Windows

[aperfidia]

Environment:

• CMake x64
• Windows 10 x64 Chinese
• Visual studio 2015 or Visual studio 2017
• Generated as x64 VS solustion
• Lastest livAV download from http://builds.libav.org/windows/release-lgpl/libav-x86_64-w64-mingw32-11.7.7z

Problems:

• Could not find libAV resource in CMake ==> Force comment out the last 4 lines of /musly/cmake/FindLibAV.cmake and comment out version requirement of root CMakeList.txt

• Lack of M_PI_2 Definitions ==> Manually define _USE_MATH_DEFINES in VS

• Conflicts of win32's min/max macro ==> Manually define NOMINMAX in VS

• /libmusly/method.cpp line 66, VS mark as "Non-const array length buffer_size" ==> Add `const ` qualifier to `buffer_size`'s declaration

• After define NOMINMAX, all std::min/std::max in /libmusly/resampler.cpp are invalid then. ==> Add nessesary header, i.e. #include <algorithm> at begin of this file

• /libmusly/decoders/libav.cpp line 290, VS mark as "unrecognized identifer `and`" ==> Use `&&` instead

• Redefinition of uint8_t in /libmusly/lib.cpp line 15 and VS's stdint.h header. ==> Comment out the former

• When CMake option BUILD_STATIC is selected, the output libmusly.lib cannot be recognize in my project, VS hint unresolved symbol ....jukebox_poweron.., am I wrong? When this option is unselected, the output contains only 'libmusly.dll' and generate an error that musly_resample.lib not found. ==> No solution

[f0k]

Thank you for your report! First of all, is there a specific reason you need to build this with VS? The README file includes a guide for compiling with mingw: https://github.com/dominikschnitzer/musly#installation

Otherwise, your list is a mix of things we can or should change universally (const buffer_size, && instead of and, not defining uint8_t, #include <algorithm>), and things that are specific to VS (_USE_MATH_DEFINES, NOMINMAX). The latter would require some CMake magic to automatically add those defines if compiling with VS. Or actually, NOMINMAX should probably just be defined before include <windows.h>. Would you be willing to send a PR with the required changes to make it work in VS (without breaking compilation on Linux -- I can check that)?

About the BUILD_STATIC option, does #32 help?