Ray Donnelly <[email protected]> writes: > On Thu, Aug 14, 2014 at 6:45 PM, Wayne Stambaugh <[email protected]> > wrote: >> On 8/14/2014 1:13 PM, Alexey Pavlov wrote: >>> >>> 14 авг. 2014 г., в 21:04, Richard Shaw <[email protected]> написал(а): >>> >>>> I found the issue... No idea what it's not a problem on other platforms. >>>> >>>> >>>> diff -Naur cmake-3.0.1.orig/Modules/FindwxWidgets.cmake >>>> cmake-3.0.1.wxfix/Modules/FindwxWidgets.cmake >>>> --- cmake-3.0.1.orig/Modules/FindwxWidgets.cmake 2014-07-31 >>>> 10:03:56.000000000 -0500 >>>> +++ cmake-3.0.1.wxfix/Modules/FindwxWidgets.cmake 2014-08-14 >>>> 12:02:11.604331400 -0500 >>>> @@ -792,6 +792,10 @@ >>>> wxWidgets_CXX_FLAGS "${wxWidgets_CXX_FLAGS}") >>>> string(REPLACE "-I" "" >>>> wxWidgets_INCLUDE_DIRS "${wxWidgets_INCLUDE_DIRS}") >>>> + >>>> + # Flags are a string, not a list, fix it here >>>> + string(REPLACE ";" " " >>>> + wxWidgets_CXX_FLAGS "${wxWidgets_CXX_FLAGS}") >>>> >>>> DBG_MSG_V("wxWidgets_DEFINITIONS=${wxWidgets_DEFINITIONS}") >>>> DBG_MSG_V("wxWidgets_INCLUDE_DIRS=${wxWidgets_INCLUDE_DIRS}") >>>> >>>> Thanks, >>>> Richard >>> >>> Thanks, will rebuild cmake with this patch soon. >>> >>> Regards, >>> Alexey. >> >> If this is part of the CMake source, shouldn't this patch be pushed >> upstream so that it can be fixed on all platforms assuming the CMake >> developers will accept it? At least they can be made aware of the >> issue. I know it's convenient to fix it here and in the short term >> that's fine. These kinds of patches have a way of spiraling out of >> control. If you don't believe me, look at the mess required to build >> KiCad (I'm one of the lead developers) with all of the dependency >> library patching we have to do. It can quickly become a maintenance >> nightmare. > > While I agree wholeheartedly with the sentiment, this patch is a drop > in the ocean: > > $ cd MINGW-packages > $ find . -maxdepth 2 -name "*.patch" | wc -l > 1222
Each patch on that list is a burden for the project maintainers *and* the users. Adding more without a good reason is undesirable. > .. upstreaming patches is such a massive undertaking and there's only > a small handful of people who work on MSYS2 consistently; seems we > chose to spend our time adding and fixing packages rather than dealing > with sometimes ungrateful, sometimes actually hostile upstream > developers. The best results happen when people already attached to a > project who are trusted and have commit rights discover MSYS2. Ok, but has the OP *tried* to communicate with upstream at all? Just getting a confirmation that there is a bug would be an start. His patch looks very fishy to me. It seems a "works for me" hotfix without a proper understanding of the real cause. Actually, the OP claims to have found "the issue" but I see no description of what issue he is talking about, nor on this thread nor on recent ones. > If you feel that you could help reduce this number then by all means > please try upstreaming some of them and CC this mailing list when you > do. That's a worthy goal but the user who found the issue and authored the fix is the most adequate person for communicating with upstream. At least, a proper bug report should be filed on the msys2 tracker before accepting the patch. Otherwise, trying to contribute upstream would consist on "we have this patch here that fixes some problem one user had." Then don't be surprised when your "contribution" is ignored. ------------------------------------------------------------------------------ _______________________________________________ Msys2-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/msys2-users
