Hi! Sorry, for my late reply, but I wasn't "available" over the weekend.
>> ... Also, I do not see this issue for MinGW/MSYS so it is probably >> due to some weird interaction between our D language support, the >> find module for wxwidgets (also our responsibility although the >> modifications from the official CMake module are pretty small), and the >> Visual Studio type generators that you and Thorsten are using. This issue is indeed somewhat strange, and I haven't really found the exact background of the side effects, but I was able to track it down a bit further. The general cause of all trouble is within the file CMakeDInformation.cmake (which is burried deep inside the path \cmake\modules\language_support\cmake). As far as I understand it, this module is intended to define several CMake variables/properties for the different environments the project might be built under. In lines 178-204 some variables/properties regarding OS and D compiler used are set up. *Only* if the OS is Windows and the compiler is not GDC, then CMAKE_LINK_LIBRARY_FLAG is set to "-L+"). Now, I don't know which compiler/linker environment uses this special prefix to introduce an additionally linked in library, but if we are able to find out, which one this is, we could just guard this assignment with an if-statement and everything should be fine. This might be much easier than trying to find the reason why everything is fine too, if I add an explicit path to the libraries needed for wxWidgets (line 447 of FindwxWidgets.cmake). This must be due a strange side effect when evaluating library related variables and setting up the built environment by CMake. I have built PLplot with the following command lines 1) cmake -G "Visual Studio 10" <path-to-PLplot-source> 2) cmake -G "Visual Studio 10" -DENABLE_d=OFF <path-to-PLplot-source> 3) cmake -G "Visual Studio 10" -DBUILD_TEST=OFF <path-to-PLplot-source> 4) cmake -G "Visual Studio 10" -DBUILD_TEST=ON <path-to-PLplot-source> 5) cmake -G "Visual Studio 10" -DENABLE_d=OFF -DBUILD_TEST=OFF <path-to-PLplot-source> 6) cmake -G "Visual Studio 10" -DENABLE_d=OFF -DBUILD_TEST=ON <path-to-PLplot-source> 7) cmake -G "Visual Studio 10" -DBUILD_TEST=ON -DwxWidgets_LIB_DIR=%WXWINDLL% <path-to-PLplot-source> 8) cmake -G "Visual Studio 10" -DBUILD_TEST=OFF -DwxWidgets_LIB_DIR=%WXWINDLL% <path-to-PLplot-source> 9) cmake -G "Visual Studio 10" -DENABLE_d=OFF -DBUILD_TEST=OFF -DwxWidgets_LIB_DIR=%WXWINDLL% <path-to-PLplot-source> 10) cmake -G "Visual Studio 10" -DENABLE_d=OFF -DBUILD_TEST=ON -DwxWidgets_LIB_DIR=%WXWINDLL% <path-to-PLplot-source> and all of these compile find as soon as I just change that given line in CMakeDInformation.cmake (line 193) into a comment. Something else strikes me odd with this CMAKE_LINK_LIBRARY_FLAG variable. Most other variables being set in that block of code contain an explicit reference to the D language ... and because of this most probably do not interfere with other languages. Only the variables CMAKE_LINK_LIBRARY_FLAG, CMAKE_LIBRARY_PATH_FLAG and CMAKE_LIBRARY_PATH_TERMINATOR do not refer specifically to the D language. Perhaps, when introducing language support for D, it was forgotten to make these variables language dependent? In a next step I will look at the history of CMakeDInformation.cmake (if that is available in the archives) and try to understand why this might have been added here. Perhaps this gives a better insight on the issue. >> So for this and the other reasons I mentioned, this is going to be >> a really difficult bug to deal with so I am putting off that effort >> indefinitely and instead working around the issue by using a >> default of -DENABLE_d=OFF for the Windows case. (I considered only >> specifying that OFF default for just the Visual Studio type of >> generators, but there is very little call for D language support on >> Windows, and I don't really have a clue about what exactly is going >> on so I am applying that broader workaround for now.) > > Well, the workaround is definitely simpler than adding the logic to > handle exactly this build case. I had a look at the other SDK > versions I have on my machine - 8.0 and 8.0A - they have a completely > different content, so they probably have a different purpose > altogether. Well, the workaround by turning off the D language makes > it easier: we can ignore these issues. I agree with you, that it is indeed quite easy to just use a big hammer for this small nail, but this might cause bigger problems for whoever needs PLplot using the D language. The SDK versions of the libraries used by the wxWidget-modules are in my eyes just another kettle of fish ... unluckily these interfere with just the D language support. For whatever reason some functions were needed by wxWidgets and whoever needed these functions found them in the libraries comctl32.lib and rpcrt4.lib of this SDK. In a next step I will try to find out which functions calls are missing, if these libraries are not present. Perhaps these have just moved to other libraries in newer versions of the SDK. -- Best regards, Thorsten ------------------------------------------------------------------------------ Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees_APR _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
