Hi,
I'm used to compile cppcheck from sources on Windows o.s. machines.
To my knowledge it is quite as easy task but I want to point out some tricks that I do in order to compile.
I consider two scenarios, common of both scenarios is latest cmake (for the time being cmake 3.10):
1) compiling with Visual Studio 2017 Community edition
2) compiling with minGW (this case it is indeed a double case, because I consider both Lavavej's minGW and MSYS2/minGW-32(x86)/minGW-64(x64))
for
1) Visual Studio 2017 Community edition, everything is fine but a library (Shlwapi.lib) is missing when liinking cppcheck. I added Shlwapi.lib to cppcheck project with Configuraion properties -> Linker -> Added dependencies. This is because in .\cli\filelister.cpp MyDirectory function uses PathIsDirectoryA Windows API function defined in Shlwapi.lib.
2) minGW/MSYS2/minGW-32(x86)/minGW-64(x64), I changed .\cli\filelister.cpp module and its MyDirectory function in order to compile in GetFileAttributes function and compile out PathIsDirectoryA Windows API function, following panel is a recap of source modification (for MSYS2/minGW-64(x64))
///////////////////////////////////////////////////////////////////////////////////// This code is WIN32 systems ////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////#include<windows.h>#if !defined( __BORLANDC__ ) && !defined( __MINGW64__ )#include<Shlwapi.h>#endif// Here is the catch: cppcheck core is Ansi code (using char type).// When compiling Unicode targets WinAPI automatically uses *W Unicode versions// of called functions. Thus, we explicitly call *A versions of the functions.staticBOOLMyIsDirectory(conststd::string&path){#if defined( __BORLANDC__ ) || defined( __MINGW64__ )return(GetFileAttributes(path.c_str())&FILE_ATTRIBUTE_DIRECTORY);#else// See http://msdn.microsoft.com/en-us/library/bb773621(VS.85).aspxreturnPathIsDirectoryA(path.c_str());#endif}
For Your information.
Thank You all!
Giangiacomo
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I just forked from GITHUB. First build test results are:
1. source code compiles with Makefile under Lavavej's minGW
2. source code compiles with Makefile under MSYS2(minGW-x64)
3. source code compiles with cmake 3.10 Microsoft Visual Studio 2017 Community
Still I have to compile with cmake and minGW, but I will soon report.
I'm sorry that I have warned You for nothing, I have to say that I'm used to take source code from sourceforge, this is the first time that I take it from GitHub, could it be that streams are different?
Giangiacomo
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Another update:
1. source code from GitHub compiles with Visual Studio 2017 Community edition when provided .sln solution file is used
2. source code form GitHub compiles with Visual Studio 2017 Community edition when creating a solution with cmake 3.10
3. source code release 1.81 from sourceforge compiles with Visual Studio 2017 Community edition when provided .sln solution file is used
4. source code release 1.81 from sourceforge DOES NOT compile with Visual Studio 2017 Community edition when creating a solution with cmake 3.10
maybe it is all about IgnoreSpecificDefaultLibraries which changes how cppcheck is linked when cmake generates projects files, it seems to me that IgnoreSpecificDefaultLibraries is not used in released project files.
Giangiacomo
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
update:
I recompiled both released 1.81 and GitHub trunk with cmake under MSYS2(minGW-x64) and both have the problem I signaled in the beginning, that is .\cli\filelister.cpp module's MyDirectory function uses PathIsDirectoryA Windows API function, but it's unresolved reference at linking, if it were to use GetFileAttributes function it would compile right.
Giangiacomo
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I'm used to compile cppcheck from sources on Windows o.s. machines.
To my knowledge it is quite as easy task but I want to point out some tricks that I do in order to compile.
I consider two scenarios, common of both scenarios is latest cmake (for the time being cmake 3.10):
1) compiling with Visual Studio 2017 Community edition
2) compiling with minGW (this case it is indeed a double case, because I consider both Lavavej's minGW and MSYS2/minGW-32(x86)/minGW-64(x64))
for
1) Visual Studio 2017 Community edition, everything is fine but a library (Shlwapi.lib) is missing when liinking cppcheck. I added Shlwapi.lib to cppcheck project with Configuraion properties -> Linker -> Added dependencies. This is because in .\cli\filelister.cpp MyDirectory function uses PathIsDirectoryA Windows API function defined in Shlwapi.lib.
2) minGW/MSYS2/minGW-32(x86)/minGW-64(x64), I changed .\cli\filelister.cpp module and its MyDirectory function in order to compile in GetFileAttributes function and compile out PathIsDirectoryA Windows API function, following panel is a recap of source modification (for MSYS2/minGW-64(x64))
For Your information.
Thank You all!
Giangiacomo
I dont know.. but it seems to me we should try to get this into the repo. Just that we need to ensure it works with the non-cmake builds also.
do you think you could create a pull request on github?
Last edit: Daniel Marjamäki 2017-12-29
I just forked from GITHUB. First build test results are:
1. source code compiles with Makefile under Lavavej's minGW
2. source code compiles with Makefile under MSYS2(minGW-x64)
3. source code compiles with cmake 3.10 Microsoft Visual Studio 2017 Community
Still I have to compile with cmake and minGW, but I will soon report.
I'm sorry that I have warned You for nothing, I have to say that I'm used to take source code from sourceforge, this is the first time that I take it from GitHub, could it be that streams are different?
Giangiacomo
Forget about that CMake crap when using Visual Studio. There is a Visual Studio solution to build cppcheck inside the repository.
Another update:
1. source code from GitHub compiles with Visual Studio 2017 Community edition when provided .sln solution file is used
2. source code form GitHub compiles with Visual Studio 2017 Community edition when creating a solution with cmake 3.10
3. source code release 1.81 from sourceforge compiles with Visual Studio 2017 Community edition when provided .sln solution file is used
4. source code release 1.81 from sourceforge DOES NOT compile with Visual Studio 2017 Community edition when creating a solution with cmake 3.10
for case 4. this is VS Output tab
Now back to minGW+MSYS2
Ciao,
Giangiacomo
maybe it is all about IgnoreSpecificDefaultLibraries which changes how cppcheck is linked when cmake generates projects files, it seems to me that IgnoreSpecificDefaultLibraries is not used in released project files.
Giangiacomo
update:
I recompiled both released 1.81 and GitHub trunk with cmake under MSYS2(minGW-x64) and both have the problem I signaled in the beginning, that is .\cli\filelister.cpp module's MyDirectory function uses PathIsDirectoryA Windows API function, but it's unresolved reference at linking, if it were to use GetFileAttributes function it would compile right.
Giangiacomo
The Solution thats worked for me. Change in cli/CMakeList.txt:
from:
to:
please create a pull request on github.