From konstantin at podsvirov.pro  Tue Apr  4 15:33:58 2017
From: konstantin at podsvirov.pro (Konstantin Podsvirov)
Date: Tue, 04 Apr 2017 22:33:58 +0300
Subject: [cmake-developers] [Discussion] Down with discrimination CPack!
In-Reply-To: <4844054.IMnhrRRUBi@linux-l7nd>
References: <422801484767214@web29m.yandex.ru> <4844054.IMnhrRRUBi@linux-l7nd>
Message-ID: <3649401491334438@web27g.yandex.ru>

Hello all!

19.01.2017, 00:16, "Alexander Neundorf" <neundorf at kde.org>:
> On 2017 M01 18, Wed 22:20:14 CET Konstantin Podsvirov wrote:
>> ?What about add to CMake language new packaging problematic scopes:
>>
>> ?- COMPONENT;
>> ?- COMPONENT_GROUP;

- INSTALL_TYPE;

>> ?- PACKAGE;
>> ?- INSTALLER;
>> ?- REPOSITORY?
>
> that's a quite terse proposal...
>
> Alex
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers

The topic was not actively supported (except for one person), but I decided to give a new life at GitLab:

https://gitlab.kitware.com/cmake/cmake/issues/16777

--
Regards,
Konstantin Podsvirov

From rcdailey.lists at gmail.com  Thu Apr  6 16:28:18 2017
From: rcdailey.lists at gmail.com (Robert Dailey)
Date: Thu, 6 Apr 2017 15:28:18 -0500
Subject: [cmake-developers] find_program() not using PATH on Windows?
In-Reply-To: <975fcc7c-e492-bda5-32f2-a28ffabdc6ad@kitware.com>
References: <CAHd499DG8_rAEkr28MFSRs1rr758v2pGH-5Xz751ORV+Nk_u6w@mail.gmail.com>
 <83c2b0af-f8ae-aa62-2503-d112d8fc87a2@kitware.com>
 <CAHd499BU6gVKNkXLE2tktQ=8cbdqMd9bfKzMcjYyDv_1NkqGXQ@mail.gmail.com>
 <975fcc7c-e492-bda5-32f2-a28ffabdc6ad@kitware.com>
Message-ID: <CAHd499BF=uq9biXy4qULkwAeJB3Bi07o8fq=5g8hP=yhfKi9nQ@mail.gmail.com>

Brad,

I debugged the issue and so far I'm seeing very weird behavior in the
cmFindCommon::SearchPaths vector when used from cmFindProgramCommand.
It goes into FindNormalProgramDirsPerName(), where the wrong "prefix"
to each path in PATH environment variable is used. Looks like the NDK
toolchain file is affecting find_program() behavior somehow?

Attached the debug output of the SearchPaths vector to this email. In
this case, note I'm doing this:

find_program( PYTHON_EXECUTABLE python )

And in the SearchPaths vector, the path to Python is shown as:

E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/bin/Python35/

The real location of it (and what is visible in PATH itself) is:

E:/Python35/

On Mon, Mar 20, 2017 at 9:20 AM, Brad King <brad.king at kitware.com> wrote:
> On 03/20/2017 10:17 AM, Robert Dailey wrote:
>> What can I do to help you guys diagnose this problem? I could try
>> getting a reproducible script for you, but this is so dependent on
>> environment I'm not sure if it will serve as a good test case.
>
> Please build CMake from source with debugging enabled.  Then you
> can step through the search process.
>
> Thanks,
> -Brad
>
-------------- next part --------------
-		this->SearchPaths	{ size=235 }	std::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >
		[capacity]	316	int
+		[allocator]	allocator	std::_Compressed_pair<std::_Wrap_alloc<std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >,std::_Vector_val<std::_Simple_types<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >,1>
+		[0]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/bin/ProgramData/Oracle/Java/javapath/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[1]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/bin/Windows/System32/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[2]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/bin/Windows/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[3]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/bin/Windows/System32/wbem/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[4]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/bin/Windows/System32/WindowsPowerShell/v1.0/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[5]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/bin/Program Files/Beyond Compare 4/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[6]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/bin/ant/bin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[7]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/bin/android/sdk/tools/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[8]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/bin/android/sdk/platform-tools/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[9]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/bin/code/ziosk-scripts/device-scripts/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[10]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/bin/tools/ninja/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[11]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/bin/Ruby22/bin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[12]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/bin/Python35/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[13]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/bin/Python35/Scripts/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[14]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/bin/Program Files/CMake/bin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[15]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/bin/Program Files (x86)/Notepad++/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[16]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/bin/Git/cmd/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[17]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/bin/Program Files (x86)/Microsoft Emulator Manager/1.0/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[18]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/bin/Program Files/TortoiseSVN/bin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[19]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/bin/Program Files (x86)/Windows Kits/10/Windows Performance Toolkit/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[20]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/bin/Users/robert/AppData/Local/Microsoft/WindowsApps/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[21]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/bin/eclipse_workspaces/frontend/cmake-eclipse-android-build/_current/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[22]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/bin/Program Files (x86)/Microsoft Visual Studio 14.0/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[23]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/bin/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[24]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/bin/usr/local/bin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[25]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/bin/usr/local/sbin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[26]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/bin/usr/local/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[27]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/bin/usr/bin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[28]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/bin/usr/sbin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[29]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/bin/usr/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[30]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/bin/bin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[31]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/bin/sbin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[32]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/bin/bin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[33]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/bin/sbin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[34]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/bin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[35]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/bin/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/bin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[36]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/bin/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/sbin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[37]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/bin/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[38]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/bin/usr/X11R6/bin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[39]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/bin/usr/X11R6/sbin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[40]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/bin/usr/X11R6/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[41]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/bin/usr/pkg/bin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[42]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/bin/usr/pkg/sbin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[43]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/bin/usr/pkg/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[44]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/bin/opt/bin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[45]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/bin/opt/sbin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[46]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/bin/opt/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[47]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/arm-linux-androideabi/ProgramData/Oracle/Java/javapath/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[48]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/arm-linux-androideabi/Windows/System32/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[49]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/arm-linux-androideabi/Windows/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[50]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/arm-linux-androideabi/Windows/System32/wbem/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[51]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/arm-linux-androideabi/Windows/System32/WindowsPowerShell/v1.0/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[52]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/arm-linux-androideabi/Program Files/Beyond Compare 4/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[53]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/arm-linux-androideabi/ant/bin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[54]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/arm-linux-androideabi/android/sdk/tools/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[55]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/arm-linux-androideabi/android/sdk/platform-tools/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[56]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/arm-linux-androideabi/code/ziosk-scripts/device-scripts/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[57]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/arm-linux-androideabi/tools/ninja/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[58]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/arm-linux-androideabi/Ruby22/bin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[59]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/arm-linux-androideabi/Python35/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[60]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/arm-linux-androideabi/Python35/Scripts/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[61]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/arm-linux-androideabi/Program Files/CMake/bin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[62]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/arm-linux-androideabi/Program Files (x86)/Notepad++/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[63]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/arm-linux-androideabi/Git/cmd/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[64]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/arm-linux-androideabi/Program Files (x86)/Microsoft Emulator Manager/1.0/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[65]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/arm-linux-androideabi/Program Files/TortoiseSVN/bin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[66]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/arm-linux-androideabi/Program Files (x86)/Windows Kits/10/Windows Performance Toolkit/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[67]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/arm-linux-androideabi/Users/robert/AppData/Local/Microsoft/WindowsApps/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[68]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/arm-linux-androideabi/eclipse_workspaces/frontend/cmake-eclipse-android-build/_current/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[69]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/arm-linux-androideabi/Program Files (x86)/Microsoft Visual Studio 14.0/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[70]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/arm-linux-androideabi/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[71]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/arm-linux-androideabi/usr/local/bin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[72]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/arm-linux-androideabi/usr/local/sbin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[73]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/arm-linux-androideabi/usr/local/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[74]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/arm-linux-androideabi/usr/bin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[75]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/arm-linux-androideabi/usr/sbin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[76]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/arm-linux-androideabi/usr/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[77]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/arm-linux-androideabi/bin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[78]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/arm-linux-androideabi/sbin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[79]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/arm-linux-androideabi/bin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[80]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/arm-linux-androideabi/sbin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[81]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/arm-linux-androideabi/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[82]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/arm-linux-androideabi/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/bin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[83]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/arm-linux-androideabi/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/sbin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[84]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/arm-linux-androideabi/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[85]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/arm-linux-androideabi/usr/X11R6/bin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[86]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/arm-linux-androideabi/usr/X11R6/sbin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[87]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/arm-linux-androideabi/usr/X11R6/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[88]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/arm-linux-androideabi/usr/pkg/bin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[89]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/arm-linux-androideabi/usr/pkg/sbin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[90]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/arm-linux-androideabi/usr/pkg/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[91]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/arm-linux-androideabi/opt/bin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[92]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/arm-linux-androideabi/opt/sbin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[93]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/arm-linux-androideabi/opt/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[94]	"E:/android/ndk/platforms/android-15/arch-arm/ProgramData/Oracle/Java/javapath/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[95]	"E:/android/ndk/platforms/android-15/arch-arm/Windows/System32/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[96]	"E:/android/ndk/platforms/android-15/arch-arm/Windows/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[97]	"E:/android/ndk/platforms/android-15/arch-arm/Windows/System32/wbem/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[98]	"E:/android/ndk/platforms/android-15/arch-arm/Windows/System32/WindowsPowerShell/v1.0/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[99]	"E:/android/ndk/platforms/android-15/arch-arm/Program Files/Beyond Compare 4/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[100]	"E:/android/ndk/platforms/android-15/arch-arm/ant/bin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[101]	"E:/android/ndk/platforms/android-15/arch-arm/android/sdk/tools/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[102]	"E:/android/ndk/platforms/android-15/arch-arm/android/sdk/platform-tools/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[103]	"E:/android/ndk/platforms/android-15/arch-arm/code/ziosk-scripts/device-scripts/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[104]	"E:/android/ndk/platforms/android-15/arch-arm/tools/ninja/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[105]	"E:/android/ndk/platforms/android-15/arch-arm/Ruby22/bin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[106]	"E:/android/ndk/platforms/android-15/arch-arm/Python35/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[107]	"E:/android/ndk/platforms/android-15/arch-arm/Python35/Scripts/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[108]	"E:/android/ndk/platforms/android-15/arch-arm/Program Files/CMake/bin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[109]	"E:/android/ndk/platforms/android-15/arch-arm/Program Files (x86)/Notepad++/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[110]	"E:/android/ndk/platforms/android-15/arch-arm/Git/cmd/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[111]	"E:/android/ndk/platforms/android-15/arch-arm/Program Files (x86)/Microsoft Emulator Manager/1.0/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[112]	"E:/android/ndk/platforms/android-15/arch-arm/Program Files/TortoiseSVN/bin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[113]	"E:/android/ndk/platforms/android-15/arch-arm/Program Files (x86)/Windows Kits/10/Windows Performance Toolkit/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[114]	"E:/android/ndk/platforms/android-15/arch-arm/Users/robert/AppData/Local/Microsoft/WindowsApps/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[115]	"E:/android/ndk/platforms/android-15/arch-arm/eclipse_workspaces/frontend/cmake-eclipse-android-build/_current/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[116]	"E:/android/ndk/platforms/android-15/arch-arm/Program Files (x86)/Microsoft Visual Studio 14.0/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[117]	"E:/android/ndk/platforms/android-15/arch-arm/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[118]	"E:/android/ndk/platforms/android-15/arch-arm/usr/local/bin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[119]	"E:/android/ndk/platforms/android-15/arch-arm/usr/local/sbin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[120]	"E:/android/ndk/platforms/android-15/arch-arm/usr/local/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[121]	"E:/android/ndk/platforms/android-15/arch-arm/usr/bin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[122]	"E:/android/ndk/platforms/android-15/arch-arm/usr/sbin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[123]	"E:/android/ndk/platforms/android-15/arch-arm/usr/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[124]	"E:/android/ndk/platforms/android-15/arch-arm/bin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[125]	"E:/android/ndk/platforms/android-15/arch-arm/sbin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[126]	"E:/android/ndk/platforms/android-15/arch-arm/bin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[127]	"E:/android/ndk/platforms/android-15/arch-arm/sbin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[128]	"E:/android/ndk/platforms/android-15/arch-arm/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[129]	"E:/android/ndk/platforms/android-15/arch-arm/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/bin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[130]	"E:/android/ndk/platforms/android-15/arch-arm/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/sbin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[131]	"E:/android/ndk/platforms/android-15/arch-arm/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[132]	"E:/android/ndk/platforms/android-15/arch-arm/usr/X11R6/bin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[133]	"E:/android/ndk/platforms/android-15/arch-arm/usr/X11R6/sbin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[134]	"E:/android/ndk/platforms/android-15/arch-arm/usr/X11R6/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[135]	"E:/android/ndk/platforms/android-15/arch-arm/usr/pkg/bin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[136]	"E:/android/ndk/platforms/android-15/arch-arm/usr/pkg/sbin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[137]	"E:/android/ndk/platforms/android-15/arch-arm/usr/pkg/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[138]	"E:/android/ndk/platforms/android-15/arch-arm/opt/bin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[139]	"E:/android/ndk/platforms/android-15/arch-arm/opt/sbin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[140]	"E:/android/ndk/platforms/android-15/arch-arm/opt/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[141]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/ProgramData/Oracle/Java/javapath/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[142]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/Windows/System32/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[143]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/Windows/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[144]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/Windows/System32/wbem/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[145]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/Windows/System32/WindowsPowerShell/v1.0/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[146]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/Program Files/Beyond Compare 4/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[147]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/ant/bin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[148]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/android/sdk/tools/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[149]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/android/sdk/platform-tools/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[150]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/code/ziosk-scripts/device-scripts/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[151]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/tools/ninja/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[152]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/Ruby22/bin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[153]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/Python35/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[154]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/Python35/Scripts/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[155]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/Program Files/CMake/bin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[156]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/Program Files (x86)/Notepad++/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[157]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/Git/cmd/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[158]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/Program Files (x86)/Microsoft Emulator Manager/1.0/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[159]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/Program Files/TortoiseSVN/bin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[160]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/Program Files (x86)/Windows Kits/10/Windows Performance Toolkit/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[161]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/Users/robert/AppData/Local/Microsoft/WindowsApps/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[162]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/eclipse_workspaces/frontend/cmake-eclipse-android-build/_current/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[163]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/Program Files (x86)/Microsoft Visual Studio 14.0/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[164]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[165]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/usr/local/bin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[166]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/usr/local/sbin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[167]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/usr/local/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[168]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/usr/bin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[169]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/usr/sbin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[170]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/usr/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[171]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/bin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[172]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/sbin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[173]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/bin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[174]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/sbin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[175]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[176]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/bin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[177]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/sbin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[178]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[179]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/usr/X11R6/bin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[180]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/usr/X11R6/sbin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[181]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/usr/X11R6/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[182]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/usr/pkg/bin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[183]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/usr/pkg/sbin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[184]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/usr/pkg/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[185]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/opt/bin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[186]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/opt/sbin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[187]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/opt/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[188]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/share/ProgramData/Oracle/Java/javapath/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[189]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/share/Windows/System32/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[190]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/share/Windows/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[191]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/share/Windows/System32/wbem/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[192]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/share/Windows/System32/WindowsPowerShell/v1.0/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[193]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/share/Program Files/Beyond Compare 4/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[194]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/share/ant/bin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[195]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/share/android/sdk/tools/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[196]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/share/android/sdk/platform-tools/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[197]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/share/code/ziosk-scripts/device-scripts/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[198]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/share/tools/ninja/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[199]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/share/Ruby22/bin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[200]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/share/Python35/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[201]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/share/Python35/Scripts/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[202]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/share/Program Files/CMake/bin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[203]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/share/Program Files (x86)/Notepad++/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[204]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/share/Git/cmd/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[205]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/share/Program Files (x86)/Microsoft Emulator Manager/1.0/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[206]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/share/Program Files/TortoiseSVN/bin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[207]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/share/Program Files (x86)/Windows Kits/10/Windows Performance Toolkit/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[208]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/share/Users/robert/AppData/Local/Microsoft/WindowsApps/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[209]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/share/eclipse_workspaces/frontend/cmake-eclipse-android-build/_current/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[210]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/share/Program Files (x86)/Microsoft Visual Studio 14.0/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[211]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/share/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[212]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/share/usr/local/bin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[213]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/share/usr/local/sbin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[214]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/share/usr/local/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[215]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/share/usr/bin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[216]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/share/usr/sbin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[217]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/share/usr/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[218]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/share/bin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[219]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/share/sbin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[220]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/share/bin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[221]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/share/sbin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[222]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/share/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[223]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/share/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/bin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[224]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/share/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/sbin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[225]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/share/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[226]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/share/usr/X11R6/bin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[227]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/share/usr/X11R6/sbin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[228]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/share/usr/X11R6/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[229]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/share/usr/pkg/bin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[230]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/share/usr/pkg/sbin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[231]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/share/usr/pkg/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[232]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/share/opt/bin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[233]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/share/opt/sbin/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >
+		[234]	"E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/share/opt/"	std::basic_string<char,std::char_traits<char>,std::allocator<char> >

From rcdailey.lists at gmail.com  Thu Apr  6 16:32:27 2017
From: rcdailey.lists at gmail.com (Robert Dailey)
Date: Thu, 6 Apr 2017 15:32:27 -0500
Subject: [cmake-developers] find_program() not using PATH on Windows?
In-Reply-To: <CAHd499BF=uq9biXy4qULkwAeJB3Bi07o8fq=5g8hP=yhfKi9nQ@mail.gmail.com>
References: <CAHd499DG8_rAEkr28MFSRs1rr758v2pGH-5Xz751ORV+Nk_u6w@mail.gmail.com>
 <83c2b0af-f8ae-aa62-2503-d112d8fc87a2@kitware.com>
 <CAHd499BU6gVKNkXLE2tktQ=8cbdqMd9bfKzMcjYyDv_1NkqGXQ@mail.gmail.com>
 <975fcc7c-e492-bda5-32f2-a28ffabdc6ad@kitware.com>
 <CAHd499BF=uq9biXy4qULkwAeJB3Bi07o8fq=5g8hP=yhfKi9nQ@mail.gmail.com>
Message-ID: <CAHd499BWssaYbteqQh9Nn04k1Oo4aQZ0id4y4BPFQFGCv=JXOA@mail.gmail.com>

Looking further: in cmFindCommon::RerootPaths(), the passed in paths
look correct as far as what PATH shows, and then when this line of
code happens:

const char* rootPath = this->Makefile->GetDefinition("CMAKE_FIND_ROOT_PATH");

it returns a "root path" of:

E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/bin;E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/arm-linux-androideabi;E:/android/ndk/platforms/android-15/arch-arm;E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user;E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/user/share

This is affected by CMAKE_FIND_ROOT_PATH I guess, which the Crystax
NDK toolchain file is mucking with maybe? I do find it bizarre that
directories coming from PATH can be "rerooted" like this, it makes
things very confusing... maybe there is a reason for it, but I'd never
want this personally, and I find it concerning that a toolchain file
can break this for the whole project.

What should I do?

On Thu, Apr 6, 2017 at 3:28 PM, Robert Dailey <rcdailey.lists at gmail.com> wrote:
> Brad,
>
> I debugged the issue and so far I'm seeing very weird behavior in the
> cmFindCommon::SearchPaths vector when used from cmFindProgramCommand.
> It goes into FindNormalProgramDirsPerName(), where the wrong "prefix"
> to each path in PATH environment variable is used. Looks like the NDK
> toolchain file is affecting find_program() behavior somehow?
>
> Attached the debug output of the SearchPaths vector to this email. In
> this case, note I'm doing this:
>
> find_program( PYTHON_EXECUTABLE python )
>
> And in the SearchPaths vector, the path to Python is shown as:
>
> E:/android/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/bin/Python35/
>
> The real location of it (and what is visible in PATH itself) is:
>
> E:/Python35/
>
> On Mon, Mar 20, 2017 at 9:20 AM, Brad King <brad.king at kitware.com> wrote:
>> On 03/20/2017 10:17 AM, Robert Dailey wrote:
>>> What can I do to help you guys diagnose this problem? I could try
>>> getting a reproducible script for you, but this is so dependent on
>>> environment I'm not sure if it will serve as a good test case.
>>
>> Please build CMake from source with debugging enabled.  Then you
>> can step through the search process.
>>
>> Thanks,
>> -Brad
>>

From brad.king at kitware.com  Thu Apr  6 16:38:09 2017
From: brad.king at kitware.com (Brad King)
Date: Thu, 6 Apr 2017 16:38:09 -0400
Subject: [cmake-developers] find_program() not using PATH on Windows?
In-Reply-To: <CAHd499BWssaYbteqQh9Nn04k1Oo4aQZ0id4y4BPFQFGCv=JXOA@mail.gmail.com>
References: <CAHd499DG8_rAEkr28MFSRs1rr758v2pGH-5Xz751ORV+Nk_u6w@mail.gmail.com>
 <83c2b0af-f8ae-aa62-2503-d112d8fc87a2@kitware.com>
 <CAHd499BU6gVKNkXLE2tktQ=8cbdqMd9bfKzMcjYyDv_1NkqGXQ@mail.gmail.com>
 <975fcc7c-e492-bda5-32f2-a28ffabdc6ad@kitware.com>
 <CAHd499BF=uq9biXy4qULkwAeJB3Bi07o8fq=5g8hP=yhfKi9nQ@mail.gmail.com>
 <CAHd499BWssaYbteqQh9Nn04k1Oo4aQZ0id4y4BPFQFGCv=JXOA@mail.gmail.com>
Message-ID: <c928d461-d8a1-d082-c3ea-6a9c8f369a7c@kitware.com>

On 04/06/2017 04:32 PM, Robert Dailey wrote:
> directories coming from PATH can be "rerooted" like this, it makes
> things very confusing... maybe there is a reason for it, but I'd never
> want this personally, and I find it concerning that a toolchain file
> can break this for the whole project.

The toolchain file is using CMAKE_FIND_ROOT_PATH to prevent find
commands from searching outside of those directories.  That is
why everything is rerooted.

Often one doesn't want this for programs, so the toolchain file
should set CMAKE_FIND_ROOT_PATH_MODE_PROGRAM to NEVER or BOTH.
If it has some reason for not doing that then one can always use
NO_CMAKE_FIND_ROOT_PATH in the individual find_program call.

-Brad


From rcdailey.lists at gmail.com  Thu Apr  6 16:41:28 2017
From: rcdailey.lists at gmail.com (Robert Dailey)
Date: Thu, 6 Apr 2017 15:41:28 -0500
Subject: [cmake-developers] find_program() not using PATH on Windows?
In-Reply-To: <c928d461-d8a1-d082-c3ea-6a9c8f369a7c@kitware.com>
References: <CAHd499DG8_rAEkr28MFSRs1rr758v2pGH-5Xz751ORV+Nk_u6w@mail.gmail.com>
 <83c2b0af-f8ae-aa62-2503-d112d8fc87a2@kitware.com>
 <CAHd499BU6gVKNkXLE2tktQ=8cbdqMd9bfKzMcjYyDv_1NkqGXQ@mail.gmail.com>
 <975fcc7c-e492-bda5-32f2-a28ffabdc6ad@kitware.com>
 <CAHd499BF=uq9biXy4qULkwAeJB3Bi07o8fq=5g8hP=yhfKi9nQ@mail.gmail.com>
 <CAHd499BWssaYbteqQh9Nn04k1Oo4aQZ0id4y4BPFQFGCv=JXOA@mail.gmail.com>
 <c928d461-d8a1-d082-c3ea-6a9c8f369a7c@kitware.com>
Message-ID: <CAHd499CkJnc_xR+MJfH7ZJ82EywHKfk-3MbQR_tfH9nprsmPwg@mail.gmail.com>

Unsetting these at the bottom of the toolchain file fixes it:

unset( CMAKE_FIND_ROOT_PATH )
unset( CMAKE_FIND_ROOT_PATH_MODE_PROGRAM )
unset( CMAKE_FIND_ROOT_PATH_MODE_LIBRARY )
unset( CMAKE_FIND_ROOT_PATH_MODE_INCLUDE )

However I'm not sure if this is the right solution. They do for some
reason specify PROGRAM to ONLY. Should these values propagate outside
of the toolchain file?

On Thu, Apr 6, 2017 at 3:38 PM, Brad King <brad.king at kitware.com> wrote:
> On 04/06/2017 04:32 PM, Robert Dailey wrote:
>> directories coming from PATH can be "rerooted" like this, it makes
>> things very confusing... maybe there is a reason for it, but I'd never
>> want this personally, and I find it concerning that a toolchain file
>> can break this for the whole project.
>
> The toolchain file is using CMAKE_FIND_ROOT_PATH to prevent find
> commands from searching outside of those directories.  That is
> why everything is rerooted.
>
> Often one doesn't want this for programs, so the toolchain file
> should set CMAKE_FIND_ROOT_PATH_MODE_PROGRAM to NEVER or BOTH.
> If it has some reason for not doing that then one can always use
> NO_CMAKE_FIND_ROOT_PATH in the individual find_program call.
>
> -Brad
>

From rcdailey.lists at gmail.com  Thu Apr  6 16:43:49 2017
From: rcdailey.lists at gmail.com (Robert Dailey)
Date: Thu, 6 Apr 2017 15:43:49 -0500
Subject: [cmake-developers] find_program() not using PATH on Windows?
In-Reply-To: <CAHd499CkJnc_xR+MJfH7ZJ82EywHKfk-3MbQR_tfH9nprsmPwg@mail.gmail.com>
References: <CAHd499DG8_rAEkr28MFSRs1rr758v2pGH-5Xz751ORV+Nk_u6w@mail.gmail.com>
 <83c2b0af-f8ae-aa62-2503-d112d8fc87a2@kitware.com>
 <CAHd499BU6gVKNkXLE2tktQ=8cbdqMd9bfKzMcjYyDv_1NkqGXQ@mail.gmail.com>
 <975fcc7c-e492-bda5-32f2-a28ffabdc6ad@kitware.com>
 <CAHd499BF=uq9biXy4qULkwAeJB3Bi07o8fq=5g8hP=yhfKi9nQ@mail.gmail.com>
 <CAHd499BWssaYbteqQh9Nn04k1Oo4aQZ0id4y4BPFQFGCv=JXOA@mail.gmail.com>
 <c928d461-d8a1-d082-c3ea-6a9c8f369a7c@kitware.com>
 <CAHd499CkJnc_xR+MJfH7ZJ82EywHKfk-3MbQR_tfH9nprsmPwg@mail.gmail.com>
Message-ID: <CAHd499C8CDTz43odxM_dM94cFvmVM-Qvz4aSKyoTmJob9Aat_A@mail.gmail.com>

Even worse, they seem to acknowledge this problem and created "proxy"
macros for the use by the host OS (code at the bottom)

Is it just me or is this really nasty?


# macro to find packages on the host OS
macro( find_host_package )
 set( CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER )
 set( CMAKE_FIND_ROOT_PATH_MODE_LIBRARY NEVER )
 set( CMAKE_FIND_ROOT_PATH_MODE_INCLUDE NEVER )
 if( CMAKE_HOST_WIN32 )
  SET( WIN32 1 )
  SET( UNIX )
 elseif( CMAKE_HOST_APPLE )
  SET( APPLE 1 )
  SET( UNIX )
 endif()
 find_package( ${ARGN} )
 SET( WIN32 )
 SET( APPLE )
 SET( UNIX 1 )
 set( CMAKE_FIND_ROOT_PATH_MODE_PROGRAM ONLY )
 set( CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY )
 set( CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY )
endmacro()


# macro to find programs on the host OS
macro( find_host_program )
 set( CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER )
 set( CMAKE_FIND_ROOT_PATH_MODE_LIBRARY NEVER )
 set( CMAKE_FIND_ROOT_PATH_MODE_INCLUDE NEVER )
 if( CMAKE_HOST_WIN32 )
  SET( WIN32 1 )
  SET( UNIX )
 elseif( CMAKE_HOST_APPLE )
  SET( APPLE 1 )
  SET( UNIX )
 endif()
 find_program( ${ARGN} )
 SET( WIN32 )
 SET( APPLE )
 SET( UNIX 1 )
 set( CMAKE_FIND_ROOT_PATH_MODE_PROGRAM ONLY )
 set( CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY )
 set( CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY )
endmacro()

On Thu, Apr 6, 2017 at 3:41 PM, Robert Dailey <rcdailey.lists at gmail.com> wrote:
> Unsetting these at the bottom of the toolchain file fixes it:
>
> unset( CMAKE_FIND_ROOT_PATH )
> unset( CMAKE_FIND_ROOT_PATH_MODE_PROGRAM )
> unset( CMAKE_FIND_ROOT_PATH_MODE_LIBRARY )
> unset( CMAKE_FIND_ROOT_PATH_MODE_INCLUDE )
>
> However I'm not sure if this is the right solution. They do for some
> reason specify PROGRAM to ONLY. Should these values propagate outside
> of the toolchain file?
>
> On Thu, Apr 6, 2017 at 3:38 PM, Brad King <brad.king at kitware.com> wrote:
>> On 04/06/2017 04:32 PM, Robert Dailey wrote:
>>> directories coming from PATH can be "rerooted" like this, it makes
>>> things very confusing... maybe there is a reason for it, but I'd never
>>> want this personally, and I find it concerning that a toolchain file
>>> can break this for the whole project.
>>
>> The toolchain file is using CMAKE_FIND_ROOT_PATH to prevent find
>> commands from searching outside of those directories.  That is
>> why everything is rerooted.
>>
>> Often one doesn't want this for programs, so the toolchain file
>> should set CMAKE_FIND_ROOT_PATH_MODE_PROGRAM to NEVER or BOTH.
>> If it has some reason for not doing that then one can always use
>> NO_CMAKE_FIND_ROOT_PATH in the individual find_program call.
>>
>> -Brad
>>

From brad.king at kitware.com  Fri Apr  7 08:16:32 2017
From: brad.king at kitware.com (Brad King)
Date: Fri, 7 Apr 2017 08:16:32 -0400
Subject: [cmake-developers] find_program() not using PATH on Windows?
In-Reply-To: <CAHd499C8CDTz43odxM_dM94cFvmVM-Qvz4aSKyoTmJob9Aat_A@mail.gmail.com>
References: <CAHd499DG8_rAEkr28MFSRs1rr758v2pGH-5Xz751ORV+Nk_u6w@mail.gmail.com>
 <83c2b0af-f8ae-aa62-2503-d112d8fc87a2@kitware.com>
 <CAHd499BU6gVKNkXLE2tktQ=8cbdqMd9bfKzMcjYyDv_1NkqGXQ@mail.gmail.com>
 <975fcc7c-e492-bda5-32f2-a28ffabdc6ad@kitware.com>
 <CAHd499BF=uq9biXy4qULkwAeJB3Bi07o8fq=5g8hP=yhfKi9nQ@mail.gmail.com>
 <CAHd499BWssaYbteqQh9Nn04k1Oo4aQZ0id4y4BPFQFGCv=JXOA@mail.gmail.com>
 <c928d461-d8a1-d082-c3ea-6a9c8f369a7c@kitware.com>
 <CAHd499CkJnc_xR+MJfH7ZJ82EywHKfk-3MbQR_tfH9nprsmPwg@mail.gmail.com>
 <CAHd499C8CDTz43odxM_dM94cFvmVM-Qvz4aSKyoTmJob9Aat_A@mail.gmail.com>
Message-ID: <d3d43f73-0d7b-9949-76c4-737eeaacd016@kitware.com>

On 04/06/2017 04:43 PM, Robert Dailey wrote:
> Even worse, they seem to acknowledge this problem and created "proxy"
> macros for the use by the host OS (code at the bottom)

Interesting.  That approach depends on all projects using their
macros instead of the normal `find_package`, requiring explicit
porting to use their toolchain file.

Typically toolchain files should do this:

```
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)
```

so that packages for the target platform are found in the
re-rooted locations but programs are found on the host.

-Brad


From rcdailey.lists at gmail.com  Fri Apr  7 09:32:13 2017
From: rcdailey.lists at gmail.com (Robert Dailey)
Date: Fri, 7 Apr 2017 08:32:13 -0500
Subject: [cmake-developers] find_program() not using PATH on Windows?
In-Reply-To: <d3d43f73-0d7b-9949-76c4-737eeaacd016@kitware.com>
References: <CAHd499DG8_rAEkr28MFSRs1rr758v2pGH-5Xz751ORV+Nk_u6w@mail.gmail.com>
 <83c2b0af-f8ae-aa62-2503-d112d8fc87a2@kitware.com>
 <CAHd499BU6gVKNkXLE2tktQ=8cbdqMd9bfKzMcjYyDv_1NkqGXQ@mail.gmail.com>
 <975fcc7c-e492-bda5-32f2-a28ffabdc6ad@kitware.com>
 <CAHd499BF=uq9biXy4qULkwAeJB3Bi07o8fq=5g8hP=yhfKi9nQ@mail.gmail.com>
 <CAHd499BWssaYbteqQh9Nn04k1Oo4aQZ0id4y4BPFQFGCv=JXOA@mail.gmail.com>
 <c928d461-d8a1-d082-c3ea-6a9c8f369a7c@kitware.com>
 <CAHd499CkJnc_xR+MJfH7ZJ82EywHKfk-3MbQR_tfH9nprsmPwg@mail.gmail.com>
 <CAHd499C8CDTz43odxM_dM94cFvmVM-Qvz4aSKyoTmJob9Aat_A@mail.gmail.com>
 <d3d43f73-0d7b-9949-76c4-737eeaacd016@kitware.com>
Message-ID: <CAHd499C3X=AxU1qOeFr=Wmy5iMFGSLJPCjsBbbmyi6iLCJAstw@mail.gmail.com>

Thanks for the feedback Brad, as always. Really appreciate your
continued help. Sorry for continuing the discussion on the dev list.

To close out the discussion just wanted to share (for others that may
run into this issue) that I went ahead and just added this line to my
root CMakeLists.txt file:

set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)

This at least disables the root path for programs. I didn't add it to
the toolchain itself since I don't know the impact of doing it, nor do
I really care to support it. I'm slowly trying to move away from
Crystax at my workplace in favor of official NDK since that has built
in support in CMake and also is run a little better (Crystax has been
a fat mess to use; we originally only chose to use it for the prebuilt
libraries, but not worth it)

Thanks again!!

On Fri, Apr 7, 2017 at 7:16 AM, Brad King <brad.king at kitware.com> wrote:
> On 04/06/2017 04:43 PM, Robert Dailey wrote:
>> Even worse, they seem to acknowledge this problem and created "proxy"
>> macros for the use by the host OS (code at the bottom)
>
> Interesting.  That approach depends on all projects using their
> macros instead of the normal `find_package`, requiring explicit
> porting to use their toolchain file.
>
> Typically toolchain files should do this:
>
> ```
> set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
> set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
> set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
> set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)
> ```
>
> so that packages for the target platform are found in the
> re-rooted locations but programs are found on the host.
>
> -Brad
>

From florent.castelli at gmail.com  Fri Apr  7 13:33:49 2017
From: florent.castelli at gmail.com (Florent Castelli)
Date: Fri, 7 Apr 2017 18:33:49 +0100
Subject: [cmake-developers] find_program() not using PATH on Windows?
In-Reply-To: <CAHd499C3X=AxU1qOeFr=Wmy5iMFGSLJPCjsBbbmyi6iLCJAstw@mail.gmail.com>
References: <CAHd499DG8_rAEkr28MFSRs1rr758v2pGH-5Xz751ORV+Nk_u6w@mail.gmail.com>
 <83c2b0af-f8ae-aa62-2503-d112d8fc87a2@kitware.com>
 <CAHd499BU6gVKNkXLE2tktQ=8cbdqMd9bfKzMcjYyDv_1NkqGXQ@mail.gmail.com>
 <975fcc7c-e492-bda5-32f2-a28ffabdc6ad@kitware.com>
 <CAHd499BF=uq9biXy4qULkwAeJB3Bi07o8fq=5g8hP=yhfKi9nQ@mail.gmail.com>
 <CAHd499BWssaYbteqQh9Nn04k1Oo4aQZ0id4y4BPFQFGCv=JXOA@mail.gmail.com>
 <c928d461-d8a1-d082-c3ea-6a9c8f369a7c@kitware.com>
 <CAHd499CkJnc_xR+MJfH7ZJ82EywHKfk-3MbQR_tfH9nprsmPwg@mail.gmail.com>
 <CAHd499C8CDTz43odxM_dM94cFvmVM-Qvz4aSKyoTmJob9Aat_A@mail.gmail.com>
 <d3d43f73-0d7b-9949-76c4-737eeaacd016@kitware.com>
 <CAHd499C3X=AxU1qOeFr=Wmy5iMFGSLJPCjsBbbmyi6iLCJAstw@mail.gmail.com>
Message-ID: <4BCCA61F-DCEA-4408-996F-B7C4E38AC896@gmail.com>

What you mentioned is a classic problem of that famous Android toolchain. When I used it, I just patched it and set the CMAKE_FIND_ROOT_PATH_MODE_PROGRAM to NEVER directly, and removed some harmful pieces in there (like that find macro and some other bug fix for macOS builds, libc++ and recent NDK support?).

Have you considered switching to the upstream support in either CMake or the one provided by Google with Gradle?
You can probably just upgrade to the first one and get rid of similar issues by just tweaking the CMake command line.

For the other issues you mentioned of compiling for multiple architectures, the Gradle CMake plugin should handle that and build all the ones you specify.
That one will be a bit more complicated to implement as you need to transition from Ant to Gradle, but I remember the ant tooling being deprecated now, so it should improve the situation a little bit.

/Florent

> On 7 Apr 2017, at 14:32, Robert Dailey <rcdailey.lists at gmail.com> wrote:
> 
> Thanks for the feedback Brad, as always. Really appreciate your
> continued help. Sorry for continuing the discussion on the dev list.
> 
> To close out the discussion just wanted to share (for others that may
> run into this issue) that I went ahead and just added this line to my
> root CMakeLists.txt file:
> 
> set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
> 
> This at least disables the root path for programs. I didn't add it to
> the toolchain itself since I don't know the impact of doing it, nor do
> I really care to support it. I'm slowly trying to move away from
> Crystax at my workplace in favor of official NDK since that has built
> in support in CMake and also is run a little better (Crystax has been
> a fat mess to use; we originally only chose to use it for the prebuilt
> libraries, but not worth it)
> 
> Thanks again!!
> 
> On Fri, Apr 7, 2017 at 7:16 AM, Brad King <brad.king at kitware.com> wrote:
>> On 04/06/2017 04:43 PM, Robert Dailey wrote:
>>> Even worse, they seem to acknowledge this problem and created "proxy"
>>> macros for the use by the host OS (code at the bottom)
>> 
>> Interesting.  That approach depends on all projects using their
>> macros instead of the normal `find_package`, requiring explicit
>> porting to use their toolchain file.
>> 
>> Typically toolchain files should do this:
>> 
>> ```
>> set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
>> set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
>> set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
>> set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)
>> ```
>> 
>> so that packages for the target platform are found in the
>> re-rooted locations but programs are found on the host.
>> 
>> -Brad
>> 
> -- 
> 
> Powered by www.kitware.com
> 
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
> 
> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
> 
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
> 
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
> 
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers


From rcdailey.lists at gmail.com  Fri Apr  7 15:50:19 2017
From: rcdailey.lists at gmail.com (Robert Dailey)
Date: Fri, 7 Apr 2017 14:50:19 -0500
Subject: [cmake-developers] find_program() not using PATH on Windows?
In-Reply-To: <4BCCA61F-DCEA-4408-996F-B7C4E38AC896@gmail.com>
References: <CAHd499DG8_rAEkr28MFSRs1rr758v2pGH-5Xz751ORV+Nk_u6w@mail.gmail.com>
 <83c2b0af-f8ae-aa62-2503-d112d8fc87a2@kitware.com>
 <CAHd499BU6gVKNkXLE2tktQ=8cbdqMd9bfKzMcjYyDv_1NkqGXQ@mail.gmail.com>
 <975fcc7c-e492-bda5-32f2-a28ffabdc6ad@kitware.com>
 <CAHd499BF=uq9biXy4qULkwAeJB3Bi07o8fq=5g8hP=yhfKi9nQ@mail.gmail.com>
 <CAHd499BWssaYbteqQh9Nn04k1Oo4aQZ0id4y4BPFQFGCv=JXOA@mail.gmail.com>
 <c928d461-d8a1-d082-c3ea-6a9c8f369a7c@kitware.com>
 <CAHd499CkJnc_xR+MJfH7ZJ82EywHKfk-3MbQR_tfH9nprsmPwg@mail.gmail.com>
 <CAHd499C8CDTz43odxM_dM94cFvmVM-Qvz4aSKyoTmJob9Aat_A@mail.gmail.com>
 <d3d43f73-0d7b-9949-76c4-737eeaacd016@kitware.com>
 <CAHd499C3X=AxU1qOeFr=Wmy5iMFGSLJPCjsBbbmyi6iLCJAstw@mail.gmail.com>
 <4BCCA61F-DCEA-4408-996F-B7C4E38AC896@gmail.com>
Message-ID: <CAHd499Cp6rVkUVnkP_wYyN+gvdYcdOBmSGdrabq+Z2TzXas3DA@mail.gmail.com>

Yeah I've wanted to use built in support for NDK, but it doesn't work
with Crystax for a number of reasons. Just had no luck with it.
Crystax provides its toolchain file that I have to use.

I'm trying to get away from Crystax, but in the meantime I'm stuck
fixing this obscure issue the same way you did.

On Fri, Apr 7, 2017 at 12:33 PM, Florent Castelli
<florent.castelli at gmail.com> wrote:
> What you mentioned is a classic problem of that famous Android toolchain. When I used it, I just patched it and set the CMAKE_FIND_ROOT_PATH_MODE_PROGRAM to NEVER directly, and removed some harmful pieces in there (like that find macro and some other bug fix for macOS builds, libc++ and recent NDK support?).
>
> Have you considered switching to the upstream support in either CMake or the one provided by Google with Gradle?
> You can probably just upgrade to the first one and get rid of similar issues by just tweaking the CMake command line.
>
> For the other issues you mentioned of compiling for multiple architectures, the Gradle CMake plugin should handle that and build all the ones you specify.
> That one will be a bit more complicated to implement as you need to transition from Ant to Gradle, but I remember the ant tooling being deprecated now, so it should improve the situation a little bit.
>
> /Florent
>
>> On 7 Apr 2017, at 14:32, Robert Dailey <rcdailey.lists at gmail.com> wrote:
>>
>> Thanks for the feedback Brad, as always. Really appreciate your
>> continued help. Sorry for continuing the discussion on the dev list.
>>
>> To close out the discussion just wanted to share (for others that may
>> run into this issue) that I went ahead and just added this line to my
>> root CMakeLists.txt file:
>>
>> set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
>>
>> This at least disables the root path for programs. I didn't add it to
>> the toolchain itself since I don't know the impact of doing it, nor do
>> I really care to support it. I'm slowly trying to move away from
>> Crystax at my workplace in favor of official NDK since that has built
>> in support in CMake and also is run a little better (Crystax has been
>> a fat mess to use; we originally only chose to use it for the prebuilt
>> libraries, but not worth it)
>>
>> Thanks again!!
>>
>> On Fri, Apr 7, 2017 at 7:16 AM, Brad King <brad.king at kitware.com> wrote:
>>> On 04/06/2017 04:43 PM, Robert Dailey wrote:
>>>> Even worse, they seem to acknowledge this problem and created "proxy"
>>>> macros for the use by the host OS (code at the bottom)
>>>
>>> Interesting.  That approach depends on all projects using their
>>> macros instead of the normal `find_package`, requiring explicit
>>> porting to use their toolchain file.
>>>
>>> Typically toolchain files should do this:
>>>
>>> ```
>>> set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
>>> set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
>>> set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
>>> set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)
>>> ```
>>>
>>> so that packages for the target platform are found in the
>>> re-rooted locations but programs are found on the host.
>>>
>>> -Brad
>>>
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>
>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/cmake-developers
>

From robert.maynard at kitware.com  Mon Apr 10 15:19:10 2017
From: robert.maynard at kitware.com (Robert Maynard)
Date: Mon, 10 Apr 2017 15:19:10 -0400
Subject: [cmake-developers] [ANNOUNCE] CMake 3.8.0 available for download
Message-ID: <CAFzjYVpoAJEvfotAJvsALJG3jxNGK1g=z+yq0gcApm0Z=9KTMQ@mail.gmail.com>

I am proud to announce that CMake 3.8.0 is now available for download at:
  https://cmake.org/download/

Documentation is available at:
  https://cmake.org/cmake/help/v3.8

Release notes appear below and are also published at
  https://cmake.org/cmake/help/v3.8/release/3.8.html

Some of the more significant changes in CMake 3.8 are:

* CMake now supports "CSharp" (C#) as a first-class language. It is
  currently supported by the Visual Studio Generators for VS 2010
  and above.

* CMake now supports "CUDA" as a first-class language. It is
  currently supported by the Makefile Generators and the
  "Ninja" generator on Linux, macOS, and Windows. Support for the
  Visual Studio IDE is under development but not included in this
  release.

* The "Compile Features" functionality now offers meta-features that
  request compiler modes for specific language standard levels (e.g.
  "cxx_std_11").  See "CMAKE_C_KNOWN_FEATURES" and
  "CMAKE_CXX_KNOWN_FEATURES".

* The "Compile Features" functionality is now aware of C++ 17.  No
  specific features are yet enumerated besides the "cxx_std_17" meta-
  feature.

* The Visual Studio Generators for VS 2013 and above learned to
  support a "host=x64" option in the "CMAKE_GENERATOR_TOOLSET" value
  (e.g.  via the "cmake(1)" "-T" option) to request use of a VS 64-bit
  toolchain on 64-bit hosts.

* The Visual Studio Generators learned to treat files passed to
  "target_link_libraries()" whose names end in ".targets" as MSBuild
  "targets" files to be imported into generated project files.

* The "try_compile()" command source file signature gained new
  options to specify the language standard to use in the generated
  test project.

* The "try_compile()" command source file signature now honors
  language standard variables like "CMAKE_CXX_STANDARD". See policy
  "CMP0067".

* A "BUILD_RPATH" target property and corresponding
  "CMAKE_BUILD_RPATH" variable were added to support custom "RPATH"
  locations to be added to binaries in the build tree.

* The "COMPILE_FLAGS" source file property learned to support
  "generator expressions".

* A new generator expression "$<IF:cond,true-value,false-value>" was
  added. It resolves to the true-value if the condition is "1" and
  resolves to the false-value if the condition is "0".

* The "Compile Features" functionality is now aware of features
  supported by Intel C++ compilers versions 12.1 through 17.0 on UNIX
  and Windows platforms.

* The Visual Studio Generators for VS 2010 and above now place per-
  source file flags after target-wide flags when they are classified
  as raw flags with no project file setting ("AdditionalOptions").
  This behavior is more consistent with the ordering of flags produced
  by other generators, and allows flags on more-specific properties
  (per-source) to override those on more general ones (per-target).

* The precompiled Windows binary MSI package provided on "cmake.org"
  now records the installation directory in the Windows Registry under
  the key "HKLM\Software\Kitware\CMake" with a value named
  "InstallDir".


CMake 3.8 Release Notes
***********************

Changes made since CMake 3.7 include the following.


New Features
============


Languages
---------


C#
~~

* CMake learned to support "CSharp" (C#) as a first-class language
  that can be enabled via the "project()" and "enable_language()"
  commands.  It is currently supported by the Visual Studio Generators
  for VS 2010 and above.

  C# assemblies and programs can be added just like common C++ targets
  using the "add_library()" and "add_executable()" commands.
  References between C# targets in the same source tree may be
  specified by "target_link_libraries()" like for C++.  References to
  system or 3rd-party assemblies may be specified by the target
  properties "VS_DOTNET_REFERENCE_<refname>" and
  "VS_DOTNET_REFERENCES".

* More fine tuning of C# targets may be done using target and source
  file properties.  Specifically the target properties related to
  Visual Studio ("VS_*") are worth a look (for setting toolset
  versions, root namespaces, assembly icons, ...).


CUDA
~~~~

* CMake learned to support "CUDA" as a first-class language that can
  be enabled via the "project()" and "enable_language()" commands.

* "CUDA" is currently supported by the Makefile Generators and the
  "Ninja" generator on Linux, macOS, and Windows. Support for the
  Visual Studio IDE is under development but not included in this
  release.

* The NVIDIA CUDA Toolkit compiler ("nvcc") is supported.


C & C++
~~~~~~~

* The "Compile Features" functionality now offers meta-features that
  request compiler modes for specific language standard levels (e.g.
  "cxx_std_11").  See "CMAKE_C_KNOWN_FEATURES" and
  "CMAKE_CXX_KNOWN_FEATURES".

* The "Compile Features" functionality is now aware of C++ 17.  No
  specific features are yet enumerated besides the "cxx_std_17" meta-
  feature.

* The "Compile Features" functionality is now aware of the
  availability of C99 in gcc since version 3.4.


Platforms
---------

* A new minimal platform file for "Fuchsia" was added.


Generators
----------

* The "CodeBlocks" extra generator may now be used to generate with
  "NMake Makefiles JOM".

* The Visual Studio Generators for VS 2013 and above learned to
  support a "host=x64" option in the "CMAKE_GENERATOR_TOOLSET" value
  (e.g.  via the "cmake(1)" "-T" option) to request use of a VS 64-bit
  toolchain on 64-bit hosts.

* The Visual Studio Generators learned to treat files passed to
  "target_link_libraries()" whose names end in ".targets" as MSBuild
  "targets" files to be imported into generated project files.


Commands
--------

* The "add_custom_command()" and "add_custom_target()" commands
  learned the option "COMMAND_EXPAND_LISTS" which causes lists in the
  "COMMAND" argument to be expanded, including lists created by
  generator expressions.

* The "execute_process()" command gained an "ENCODING" option to
  specify on Windows which encoding is used for output from child
  process.

* The "math(EXPR)" command gained support for unary "+" and "-"
  operators.

* The "source_group()" command gained "TREE" and "PREFIX" options to
  add groups following source tree directory structure.

* The "string(TIMESTAMP)" command learned to treat "%%" as a way to
  encode plain "%".

* The "string(TIMESTAMP)" command will now honor the
  "SOURCE_DATE_EPOCH" environment variable and use its value instead
  of the current time.

* The "try_compile()" command source file signature gained new
  options to specify the language standard to use in the generated
  test project.

* The "try_compile()" command source file signature now honors
  language standard variables like "CMAKE_CXX_STANDARD". See policy
  "CMP0067".


Variables
---------

* A "CMAKE_CODELITE_USE_TARGETS" variable was added to tell the
  "CodeLite" extra generator to change the generated project to have
  target-centric organization. The "build", "rebuild", and "clean"
  operations within "CodeLite" then work on a selected target rather
  than the whole workspace. (Note that the "Ninja" clean operation on
  a target includes its dependencies, though.)

* The "CMAKE_SUBLIME_TEXT_2_ENV_SETTINGS" variable was added to tell
  the "Sublime Text 2" extra generator to place specified environment
  variables in the generated ".sublime-project".

* The "CMAKE_SUBLIME_TEXT_2_EXCLUDE_BUILD_TREE" variable was added
  to tell the "Sublime Text 2" extra generator whether to exclude the
  build tree from the ".sublime-project" when it is inside the source
  tree.

* A "CMAKE_VS_INCLUDE_PACKAGE_TO_DEFAULT_BUILD" variable was added
  to tell Visual Studio Generators for VS 2010 and above to include
  the "PACKAGE" target in the default build, similar to the existing
  "CMAKE_VS_INCLUDE_INSTALL_TO_DEFAULT_BUILD" variable for the
  "INSTALL" target.


Properties
----------

* A "BUILD_RPATH" target property and corresponding
  "CMAKE_BUILD_RPATH" variable were added to support custom "RPATH"
  locations to be added to binaries in the build tree.

* The "COMPILE_FLAGS" source file property learned to support
  "generator expressions".

* The "FRAMEWORK" target property may now also be applied to static
  libraries on Apple targets.  It will result in a proper Framework
  but with a static library inside.

* Imported Interface Libraries learned new "IMPORTED_LIBNAME" and
  "IMPORTED_LIBNAME_<CONFIG>" target properties to specify a link
  library name since interface libraries do not build their own
  library files.

* A "<LANG>_CPPLINT" target property and supporting
  "CMAKE_<LANG>_CPPLINT" variable were introduced to tell the Makefile
  Generators and the "Ninja" generator to run the "cpplint" style
  checker along with the compiler for "C" and "CXX" languages.

* A "MANUALLY_ADDED_DEPENDENCIES" target property has been added. It
  provides a read-only list of dependencies that have been added with
  the "add_dependencies()" command.

* The "MAP_IMPORTED_CONFIG_<CONFIG>" target property learned to
  interpret empty list elements as referring to the configuration-less
  imported location specified by "IMPORTED_LOCATION".

* The "NO_SYSTEM_FROM_IMPORTED" target property is now supported on
  Imported Interface Libraries.

* New source file properties "SKIP_AUTOMOC", "SKIP_AUTOUIC",
  "SKIP_AUTORCC", and "SKIP_AUTOGEN" were added to allow source files
  to be excluded from processing by "AUTOMOC", "AUTOUIC", and
  "AUTORCC" target properties.

* A "VS_COPY_TO_OUT_DIR" source file property was added to tell
  Visual Studio Generators for VS 2010 and above whether or not a file
  should e copied to the output directory.

* A "VS_DEBUGGER_WORKING_DIRECTORY" target property was added to
  tell Visual Studio Generators for VS 2010 and above what debugger
  working directory should be set for the target.

* A "VS_DOTNET_REFERENCES_COPY_LOCAL" target property was added to
  specify whether to copy referenced assemblies to the output
  directory.

* A "VS_DOTNET_REFERENCE_<refname>" target property was added to
  tell Visual Studio Generators for VS 2010 and above to add a .NET
  reference with a given hint path.

* A "VS_INCLUDE_IN_VSIX" source file property was added to tell
  Visual Studio Generators for VS 2010 and above whether to include
  the file in a Visual Studio extension package.

* A "VS_RESOURCE_GENERATOR" source file property was added to give
  Visual Studio Generators for VS 2010 and above a setting for the
  resource generator ("C#" only).

* A "VS_USER_PROPS" target property was added to tell Visual Studio
  Generators for VS 2010 and above to use a custom MSBuild user
  ".props" file.

* A "XCODE_EMIT_EFFECTIVE_PLATFORM_NAME" global property was added
  to tell the "Xcode" generator whether to emit the
  "EFFECTIVE_PLATFORM_NAME" variable.  This is useful when building
  with multiple SDKs like "macosx" and "iphoneos" in parallel.

* New "XCODE_PRODUCT_TYPE" and "XCODE_EXPLICIT_FILE_TYPE" target
  properties were created to tell the "Xcode" generator to use custom
  values of the corresponding attributes for a target in the generated
  Xcode project.


Modules
-------

* A "CSharpUtilities" module was added to aid parameterization of
  Visual Studio C# targets.  It provides functions to allow automated
  setting of source file properties to support Windows Forms, WPF/XAML
  or other technologies as needed.

* The "ExternalData" module learned to support multiple content
  links for one data file using different hashes, e.g.
  "img.png.sha256" and "img.png.sha1".  This allows objects to be
  fetched from sources indexed by different hash algorithms.

* The "ExternalProject" module gained the "GIT_PROGRESS" option to
  force Git to show progress when cloning repositories.

* The "ExternalProject" module gained a "GIT_CONFIG" option to pass
  " --config" options to Git when cloning repositories.

* The "FeatureSummary" module "feature_summary()" command now
  accepts a new "QUIET_ON_EMPTY" option that suppresses the output
  when the list of packages that belong to the selected category is
  empty.

* The "FeatureSummary" module "add_feature_info()" command now
  accepts lists of dependencies for deciding whether a feature is
  enabled or not.

* The package types accepted by the "FeatureSummary" module can now
  be tweaked by changing the "FeatureSummary_PKG_TYPES",
  "FeatureSummary_REQUIRED_PKG_TYPES" and
  "FeatureSummary_DEFAULT_PKG_TYPE" global properties.

* The "FindOpenGL" module now provides imported targets "OpenGL::GL"
  and "OpenGL::GLU" when the libraries are found.

* The "UseSWIG" module gained a "swig_add_library" command to give
  more flexibility over the old "swig_add_module" command.

* The "UseSWIG" module "swig_add_source_to_module" command learned a
  new "SWIG_OUTFILE_DIR" option to control the output file location
  ("swig -o").

* The "WriteCompilerDetectionHeader" module gained the
  "ALLOW_UNKNOWN_COMPILERS" and "ALLOW_UNKNOWN_COMPILER_VERSIONS"
  options that allow creation of headers that will work also with
  unknown or old compilers by simply assuming they do not support any
  of the requested features.


CTest
-----

* The "ctest_memcheck()" command gained a "DEFECT_COUNT <var>"
  option to capture the number of memory defects detected.

* The "ctest_memcheck()" command learned to read the location of
  suppressions files for sanitizers from the
  "CTEST_MEMORYCHECK_SUPPRESSIONS_FILE" variable.

* The "ctest_memcheck()" command learned to support "LeakSanitizer"
  independently from "AddressSanitizer".

* The "ctest_update()" command "CDASH_UPLOAD" signature was taught
  to honor the "RETRY_COUNT", "RETRY_DELAY", and "QUIET" options.


CPack
-----

* The "CPackIFWConfigureFile" module was added to define a new
  "cpack_ifw_configure_file()" command to configure file templates
  prepared in QtIFW/SDK/Creator style.

* The "CPackIFW" module "cpack_ifw_configure_component()" and
  "cpack_ifw_configure_component_group()" commands gained a new
  "DEFAULT", "VIRTUAL", "FORCED_INSTALLATION",
  "REQUIRES_ADMIN_RIGHTS", "DISPLAY_NAME", "UPDATE_TEXT",
  "DESCRIPTION", "RELEASE_DATE", "AUTO_DEPEND_ON" and "TRANSLATIONS"
  options to more specific configuration.

* The "CPackIFW" module "cpack_ifw_configure_component()" command
  gained a new "DEPENDENCIES" alias for "DEPENDS" option.

* The "CPackIFW" module "cpack_ifw_configure_component_group()"
  command gained a new "DEPENDS" option. The "DEPENDENCIES" alias also
  added.

* The "CPackIFW" module "cpack_ifw_configure_component()" and
  "cpack_ifw_configure_component_group()" commands "PRIORITY" option
  now is deprecated and will be removed in a future version of CMake.
  Please use new "SORTING_PRIORITY" option instead.

* The "CPackIFW" module gained new "CPACK_IFW_PACKAGE_WATERMARK",
  "CPACK_IFW_PACKAGE_BANNER", "CPACK_IFW_PACKAGE_BACKGROUND",
  "CPACK_IFW_PACKAGE_WIZARD_STYLE",
  "CPACK_IFW_PACKAGE_WIZARD_DEFAULT_WIDTH",
  "CPACK_IFW_PACKAGE_WIZARD_DEFAULT_HEIGHT", and
  "CPACK_IFW_PACKAGE_TITLE_COLOR" variables to customize a QtIFW
  installer look.

* The "CPackProductBuild" module gained options to sign packages.
  See the variables "CPACK_PRODUCTBUILD_IDENTITY_NAME",
  "CPACK_PRODUCTBUILD_KEYCHAIN_PATH", "CPACK_PKGBUILD_IDENTITY_NAME",
  and "CPACK_PKGBUILD_KEYCHAIN_PATH".

* The "CPackRPM" module learned to omit tags that are not supported
  by provided "rpmbuild" tool. If unsupported tags are set they are
  ignored and a developer warning is printed out.

* The "CPackRPM" module learned to generate main component package
  which forces generation of a rpm for defined component without
  component suffix in filename and package name. See
  "CPACK_RPM_MAIN_COMPONENT" variable.

* The "CPackRPM" module learned to generate a single "debuginfo"
  package on demand even if components packaging is used. See
  "CPACK_RPM_DEBUGINFO_SINGLE_PACKAGE" variable.

* The "CPackRPM" module learned to support multiple directives per
  file when using "CPACK_RPM_USER_FILELIST" variable.


Other
-----

* CMake functionality using cryptographic hashes now supports SHA-3
  algorithms.

* A new generator expression "$<IF:cond,true-value,false-value>" was
  added. It resolves to the true-value if the condition is "1" and
  resolves to the false-value if the condition is "0".


Deprecated and Removed Features
===============================

* The "FeatureSummary" module commands "set_package_info()",
  "set_feature_info()", "print_enabled_features()", and
  "print_disabled_features()" are now deprecated.

* The "UseSWIG" module "swig_add_module" command is now deprecated
  in favor of "swig_add_library".


Other Changes
=============

* If a command specified by the "<LANG>_CLANG_TIDY" target property
  returns non-zero at build time this is now treated as an error
  instead of silently ignored.

* The "ctest_memcheck()" command no longer automatically adds
  "leak_check=1" to the options used by "AddressSanitizer". The
  default behavior of "AddressSanitizer" is to run *LeakSanitizer* to
  check leaks unless "leak_check=0".

* The "ctest_memcheck()" command was fixed to correctly append extra
  sanitizer options read from the
  "CTEST_MEMORYCHECK_SANITIZER_OPTIONS" variable to the environment
  variables used internally by the sanitizers.

* The "FeatureSummary" module "set_package_properties()" command no
  longer forces the package type to "OPTIONAL" when the type is not
  explicitly set.

* The "Compile Features" functionality is now aware of features
  supported by Intel C++ compilers versions 12.1 through 17.0 on UNIX
  and Windows platforms.

* Calls to the "FindPkgConfig" module "pkg_check_modules()" command
  following a successful call learned to re-evaluate the cached values
  for a given prefix after changes to the parameters to the command
  for that prefix.

* When using "AUTOMOC" or "AUTOUIC", generated "moc_*", "*.moc" and
  "ui_*" are placed in the
  "<CMAKE_CURRENT_BINARY_DIR>/<TARGETNAME>_autogen/include" directory
  which is automatically added to the target's "INCLUDE_DIRECTORIES".
  It is therefore not necessary anymore to have
  "CMAKE_CURRENT_BINARY_DIR" in the target's "INCLUDE_DIRECTORIES".

* The "Sublime Text 2" generator no longer runs the native build
  command (e.g. "ninja" or "make") with verbose build output enabled.

* The "try_compile()" command source file signature now honors the
  "CMAKE_WARN_DEPRECATED" variable value in the generated test
  project.

* The Visual Studio Generators for VS 2010 and above now place per-
  source file flags after target-wide flags when they are classified
  as raw flags with no project file setting ("AdditionalOptions").
  This behavior is more consistent with the ordering of flags produced
  by other generators, and allows flags on more-specific properties
  (per-source) to override those on more general ones (per-target).

* The precompiled Windows binary MSI package provided on "cmake.org"
  now records the installation directory in the Windows Registry under
  the key "HKLM\Software\Kitware\CMake" with a value named
  "InstallDir".

----------------------------------------------------------------------------
Changes made since CMake 3.8.0-rc4:

Brad King (7):
      ExternalProject: Fix regression in GIT_TAG with remote branch name
      Tests: Fix spurious CTestTestParallel failures
      Features: Update features for Intel C++ 17.0.2 on UNIX
      CMakeParseImplicitLinkInfo: Ignore ld -lto_library flag
      Tests: Avoid generating .pyc files during Server test
      RC: Mark CMAKE_RC_FLAGS_<CONFIG> cache entries as advanced
      CMake 3.8.0

Craig Scott (3):
      Help: Clarify what the -f option does for the remove command
      Help: Cross compile variable used as initial value for target property
      Help: Clarify file(GENERATE) only writes output file at generation phase

Konstantin Podsvirov (1):
      QtIFW: Improved packaging as part of the QtSDK

Vadim Zeitlin (1):
      FindwxWidgets: link with the new required libs under MSW

From eike at sf-mail.de  Mon Apr 10 17:56:23 2017
From: eike at sf-mail.de (Rolf Eike Beer)
Date: Mon, 10 Apr 2017 23:56:23 +0200
Subject: [cmake-developers] Mirror CMake release files on GitHub?
In-Reply-To: <ea2cb101-4fc5-7857-651e-62a6a8385805@kitware.com>
References: <994afa24-2904-186f-b8ee-309b6639e03d@googlemail.com>
 <ea2cb101-4fc5-7857-651e-62a6a8385805@kitware.com>
Message-ID: <1571569.4BvSaT9Xuj@daneel.sf-tec.de>

Am Montag, 6. Februar 2017, 13:00:33 schrieb Brad King:
> On 02/05/2017 02:10 PM, Gregor Jasny via cmake-developers wrote:
> > I wonder if it would make sense to publish the CMake release tarballs
> > and binaries not only on cmake.org but also on github...
> > https://github.com/aktau/github-release
> 
> Thanks.  I'll take a look at that when I get a chance.

Now would be a good time ;)

Eike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170410/6882c73d/attachment.sig>

From mhanna21 at bloomberg.net  Tue Apr 11 09:34:54 2017
From: mhanna21 at bloomberg.net (Matthew Hanna (BLOOMBERG/ 731 LEX))
Date: Tue, 11 Apr 2017 13:34:54 -0000
Subject: [cmake-developers] =?utf-8?q?Proposal_to_disable_link_depends_inf?=
	=?utf-8?q?erence=2E?=
Message-ID: <58ECDB7E021E007201D80245_0_747265@n472>

Hi,

The inference logic in cmComputeLinkDepends.cxx is both inefficient and
superfluous for our specific use case.  I am proposing a global setting that
would disable the link computation entirely for those that wish to take full
responsibility of the ordering of dependencies.

We are currently using the FindPkgConfig module for generating link lines.
Following the pkg-config guidance, dependencies on system libraries are noted
in the "Libs" section of the pkg-config file as opposed to the "Requires"
section.  This means that common system libraries such as rt are repeated on
the link line.  Unfortunately, this appears to be causing the inference in
cmComputeLinkDepends.cxx to construct highly connected graphs resulting in
delays of several minutes.

For example, consider package X that depends on Y, where both depend on rt.
Since rt is a system library, pkg-config generates -lX -lrt -lY -lrt.  Now
there appears to be a cyclic dependency between rt and Y that the link logic
will attempt to grapple with.  The same problem can also occur even when
pkg-config files only contain a single unique library.  This is because the
output is not well ordered, so two targets might have the order of independent
libraries reversed, and I believe the inference is done globally, so a cycle
inference is possible.  As the number of dependent libraries increases, the
number of edges in the inferred graph explodes.

We have attempted to optimize the algorithm by removing redundant edges, but
this has only had marginal effects.  Assuming that we wish to take
responsibility for avoiding cycles, I would like a mechanism to disable the
inference logic.  One approach would be to extend the semantics of
LINK_INTERFACE_MULTIPLICITY such that setting it to 1 would disable inference
and leave link lines untouched.  However, since this is largely a property of
the library set as opposed to a single target, I would prefer a way to disable
inference at a global level, such as in a custom toolchain file.

Matthew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170411/5ad2cc6f/attachment-0001.html>

From brad.king at kitware.com  Tue Apr 11 11:16:19 2017
From: brad.king at kitware.com (Brad King)
Date: Tue, 11 Apr 2017 11:16:19 -0400
Subject: [cmake-developers] Proposal to disable link depends inference.
In-Reply-To: <58ECDB7E021E007201D80245_0_747265@n472>
References: <58ECDB7E021E007201D80245_0_747265@n472>
Message-ID: <03b1dafc-ec34-b6e2-a826-344144d85dc0@kitware.com>

On 04/11/2017 09:34 AM, Matthew Hanna (BLOOMBERG/ 731 LEX) wrote:
> The inference logic in cmComputeLinkDepends.cxx is both inefficient and
> superfluous for our specific use case. I am proposing a global setting that
> would disable the link computation entirely for those that wish to take full
> responsibility of the ordering of dependencies.

IIUC you're not talking about disabling the entire dependency analysis
but instead just turning off the magic guessing of implicit dependencies
based on observed order.  Correct?

Before we bikeshed the name and form of the setting, can you post a patch
that just removes the logic outright so we can see exactly what you mean?

Thanks,
-Brad


From petr.kmoch at gmail.com  Tue Apr 11 11:41:34 2017
From: petr.kmoch at gmail.com (Petr Kmoch)
Date: Tue, 11 Apr 2017 17:41:34 +0200
Subject: [cmake-developers] Feature suggestion: auto-create missing files
Message-ID: <CAKohaZfOkuOKqVvTm5THdcDVMZyppsfsFkc=4mQobCTcn8ZF8Q@mail.gmail.com>

Hi all,

I'd like to implement a feature for CMake which I miss there, and I'd like
to get approval for the idea & design before proceeding.

Currently, adding a new source file to a CMake-controlled project means
doing two things: creating the file on disk, and adding it to the relevant
CMakeList add_library() or add_executable() call. To me, this feels like
one operation too many. As a result, nearly all of my personal projects
using CMake end up with some sort of wrapper/pre-call which processes file
lists and creates any missing files before the list is passed to the
add_*() call.

I'd like this behaviour to become an option in CMake itself: allow the user
to switch from current behaviour of "error out if source file is not found"
to "create empty source file if it's not found." I've prototyped the
creation itself and it works, but I'd like to discuss the interface for
enabling this functionality. I was considering an inherited boolean
property on individual source file level, plus a variable which would
pre-initialise the property if set. This way, projects could control it on
the finest scope possible (or on broader scopes, since the prorepty would
recurse to directory & global level), while still providing a simple way to
set it centrally.

As far as naming is concerned, I was considering CREATE_SOURCES_IF_MISSING
for the property, and CMAKE_CREATE_SOURCES_IF_MISSING for the variable.

Is this something that would be acceptable into CMake? Any comments?

Thanks.

Petr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170411/a26696f9/attachment.html>

From brad.king at kitware.com  Tue Apr 11 11:52:52 2017
From: brad.king at kitware.com (Brad King)
Date: Tue, 11 Apr 2017 11:52:52 -0400
Subject: [cmake-developers] Feature suggestion: auto-create missing files
In-Reply-To: <CAKohaZfOkuOKqVvTm5THdcDVMZyppsfsFkc=4mQobCTcn8ZF8Q@mail.gmail.com>
References: <CAKohaZfOkuOKqVvTm5THdcDVMZyppsfsFkc=4mQobCTcn8ZF8Q@mail.gmail.com>
Message-ID: <706e667e-61f6-41c0-2d4b-ec84108b6255@kitware.com>

On 04/11/2017 11:41 AM, Petr Kmoch wrote:
> Currently, adding a new source file to a CMake-controlled project
> means doing two things: creating the file on disk, and adding it
> to the relevant CMakeList add_library() or add_executable() call.

I view this as a matching pair with an implicit sanity check.

> switch from current behaviour of "error out if source file is not found"
> to "create empty source file if it's not found."

So a typo in the `CMakeLists.txt` file leads to silent creation of a
source file instead of an error message?

That said, I can see how the proposed feature might be useful when
iteratively developing in an IDE.  Add the file to `CMakeLists.txt`,
reconfigure, and open the new (now existing) file to edit in the IDE.

> Is this something that would be acceptable into CMake? Any comments?

I'd like to hear more opinions from others before considering it
upstream.  It feels like a pretty personal workflow right now, and
can be implemented in CMake code already (perhaps with the `SOURCES`
target property to avoid separate lists).

If this were to be done I'd first like to see a policy introduced to
get rid of the magic extension guessing we do now.  Without knowing
the full file name with confidence we wouldn't be able to create it.

-Brad


From mhanna21 at bloomberg.net  Tue Apr 11 12:05:46 2017
From: mhanna21 at bloomberg.net (Matthew Hanna (BLOOMBERG/ 731 LEX))
Date: Tue, 11 Apr 2017 16:05:46 -0000
Subject: [cmake-developers]
	=?utf-8?q?Proposal_to_disable_link_depends_inf?=
	=?utf-8?q?erence=2E?=
Message-ID: <58ECFEDA026206B001D80389_0_1003215@n472>

Yes, disabling the 'magic guessing' is the primary goal.  I just wanted
to test the waters before embarking on a patch.  Will continue the
conversation once I have a patch ready that solves our problem.

Thanks,
Matthew
From: brad.king at kitware.com At: 04/11/17 11:16:27
To: cmake-developers at cmake.org
Subject: Re: [cmake-developers] Proposal to disable link depends inference.

On 04/11/2017 09:34 AM, Matthew Hanna (BLOOMBERG/ 731 LEX) wrote:
> The inference logic in cmComputeLinkDepends.cxx is both inefficient and
> superfluous for our specific use case. I am proposing a global setting that
> would disable the link computation entirely for those that wish to take full
> responsibility of the ordering of dependencies.

IIUC you're not talking about disabling the entire dependency analysis
but instead just turning off the magic guessing of implicit dependencies
based on observed order.  Correct?

Before we bikeshed the name and form of the setting, can you post a patch
that just removes the logic outright so we can see exactly what you mean?

Thanks,
-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170411/742aeefe/attachment.html>

From petr.kmoch at gmail.com  Tue Apr 11 12:16:16 2017
From: petr.kmoch at gmail.com (Petr Kmoch)
Date: Tue, 11 Apr 2017 18:16:16 +0200
Subject: [cmake-developers] Feature suggestion: auto-create missing files
In-Reply-To: <706e667e-61f6-41c0-2d4b-ec84108b6255@kitware.com>
References: <CAKohaZfOkuOKqVvTm5THdcDVMZyppsfsFkc=4mQobCTcn8ZF8Q@mail.gmail.com>
 <706e667e-61f6-41c0-2d4b-ec84108b6255@kitware.com>
Message-ID: <CAKohaZfOeKabOSoKkY+eivHhhh649-ROd+aa1kCZuqfeK4gB6Q@mail.gmail.com>

Thanks for the quick response, Brad.

On 11 April 2017 at 17:52, Brad King <brad.king at kitware.com> wrote:

> On 04/11/2017 11:41 AM, Petr Kmoch wrote:
> > Currently, adding a new source file to a CMake-controlled project
> > means doing two things: creating the file on disk, and adding it
> > to the relevant CMakeList add_library() or add_executable() call.
>
> I view this as a matching pair with an implicit sanity check.
>

I sometimes have very deep directory hierarchies (files are 3+ directory
levels below the CMakeLists.txt), with interface header, implementation
header, and implementation source in three different paths down that
hierarchy. Adding one class means adding three very similar lines of CMake
code, and then having to navigate three separate directory paths for adding
the files.


>
> > switch from current behaviour of "error out if source file is not found"
> > to "create empty source file if it's not found."
>
> So a typo in the `CMakeLists.txt` file leads to silent creation of a
> source file instead of an error message?
>

That's why I would make it strictly opt-in. We could even get rid of the
initialisation variable and keep it under full control of the project.


>
> That said, I can see how the proposed feature might be useful when
> iteratively developing in an IDE.  Add the file to `CMakeLists.txt`,
> reconfigure, and open the new (now existing) file to edit in the IDE.
>

Yes, I'm coming from an IDE background (VS, to be precise). It would be
quite helpful there. I've bounced the idea with other people in my team,
and they agreed it would be useful.


>
> > Is this something that would be acceptable into CMake? Any comments?
>
> I'd like to hear more opinions from others before considering it
> upstream.  It feels like a pretty personal workflow right now, and
> can be implemented in CMake code already (perhaps with the `SOURCES`
> target property to avoid separate lists).
>
> If this were to be done I'd first like to see a policy introduced to
> get rid of the magic extension guessing we do now.  Without knowing
> the full file name with confidence we wouldn't be able to create it.
>

I'm perfectly fine waiting for broader comments. As to extension guessing,
right now the creation happens after that step in my prototype code, and
simply uses the name verbatim as supplied. I'm perfectly willing to create
such a guess-disabling policy, though. I've never used the guessing
functionality anyway.

Petr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170411/b663fad5/attachment.html>

From wouter.klouwen at youview.com  Tue Apr 11 12:33:13 2017
From: wouter.klouwen at youview.com (Wouter Klouwen)
Date: Tue, 11 Apr 2017 17:33:13 +0100
Subject: [cmake-developers] External projects & library dependencies
Message-ID: <58ED0549.4000205@youview.com>

Hello all,

I've been converting a large build system to use CMake. At the moment it
consists of a custom build system that builds 250+ projects plus a
series of third party open source packages, that each have their own
build system. After some effort I've been able to convert all of our own
projects to use CMake.

This brings us to the next challenge as I'm now in the position where I
want to create one CMake, so that it can take over from our own build
system.
There's a major thing I can't find a good solution for yet. At the
moment each project is built individually and in order. As there's
multiple levels of build systems involved. So include and link flags
between these projects can be transferred through either CMake packages
or FindPkgConfig, for our own CMake projects and the third party
packages respectively. Both of these methods provide for interface
libraries that can be neatly depended on.

So in order to create a mega project I want to put all of the third
party packages into the build system using ExternalProject_Add.
This function does provide for targets in terms of build dependencies,
but this isn't quite enough. I need these packages to convey information
in the same way as was done through pkg-config files and provide
COMPILE_OPTIONS, INCLUDE_DIRECTORIES and LINK_LIBRARIES.

All of this information is present once the ExternalProject is built as
it would be possible to invoke pkg-config afterwards. This is of course
too late for CMake to resolve this information at configure/build rule
creation time.

Is there a better way of solving this other than effectively duplicating
the information in the pkg-config files so that CMake can read it at
generation time?

Thanks in advance,
      W
This transmission contains information that may be confidential and contain personal views which are not necessarily those of YouView TV Ltd. YouView TV Ltd (Co No:7308805) is a limited liability company registered in England and Wales with its registered address at YouView TV Ltd, 3rd Floor, 10 Lower Thames Street, London, EC3R 6YT. For details see our web site at http://www.youview.com

From ben.boeckel at kitware.com  Tue Apr 11 12:56:21 2017
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Tue, 11 Apr 2017 12:56:21 -0400
Subject: [cmake-developers] Feature suggestion: auto-create missing files
In-Reply-To: <706e667e-61f6-41c0-2d4b-ec84108b6255@kitware.com>
References: <CAKohaZfOkuOKqVvTm5THdcDVMZyppsfsFkc=4mQobCTcn8ZF8Q@mail.gmail.com>
 <706e667e-61f6-41c0-2d4b-ec84108b6255@kitware.com>
Message-ID: <20170411165621.GA31532@megas.kitware.com>

On Tue, Apr 11, 2017 at 11:52:52 -0400, Brad King wrote:
> If this were to be done I'd first like to see a policy introduced to
> get rid of the magic extension guessing we do now.  Without knowing
> the full file name with confidence we wouldn't be able to create it.

This is already an issue here:

    https://gitlab.kitware.com/cmake/cmake/issues/15208

I have a branch which needs lots of work to be rebased properly; I can
dig it up if anyone is interested in taking it over before I get to it.

--Ben

From brad.king at kitware.com  Tue Apr 11 13:00:07 2017
From: brad.king at kitware.com (Brad King)
Date: Tue, 11 Apr 2017 13:00:07 -0400
Subject: [cmake-developers] External projects & library dependencies
In-Reply-To: <58ED0549.4000205@youview.com>
References: <58ED0549.4000205@youview.com>
Message-ID: <806cae9d-161d-304f-db0a-8fea3470b068@kitware.com>

On 04/11/2017 12:33 PM, Wouter Klouwen wrote:
> So in order to create a mega project I want to put all of the third
> party packages into the build system using ExternalProject_Add.
> This function does provide for targets in terms of build dependencies,
> but this isn't quite enough. I need these packages to convey information
> in the same way as was done through pkg-config files and provide
> COMPILE_OPTIONS, INCLUDE_DIRECTORIES and LINK_LIBRARIES.
> 
> All of this information is present once the ExternalProject is built as
> it would be possible to invoke pkg-config afterwards. This is of course
> too late for CMake to resolve this information at configure/build rule
> creation time.
> 
> Is there a better way of solving this other than effectively duplicating
> the information in the pkg-config files so that CMake can read it at
> generation time?

Make your outer project a "superbuild" that does not compile anything
itself but instead just uses ExternalProject_Add to build everything
else in dependency order.  That way each project won't configure until
all its dependencies are built.

-Brad


From i.zaufi at gmail.com  Tue Apr 11 13:15:32 2017
From: i.zaufi at gmail.com (Alex Turbov)
Date: Wed, 12 Apr 2017 00:15:32 +0700
Subject: [cmake-developers] Fwd: Feature suggestion: auto-create missing
	files
In-Reply-To: <CANktQtswo9M-PVPEcGetKq6zax=itep9Ok15bwYHUkq22mrHBQ@mail.gmail.com>
References: <CAKohaZfOkuOKqVvTm5THdcDVMZyppsfsFkc=4mQobCTcn8ZF8Q@mail.gmail.com>
 <706e667e-61f6-41c0-2d4b-ec84108b6255@kitware.com>
 <CANktQtswo9M-PVPEcGetKq6zax=itep9Ok15bwYHUkq22mrHBQ@mail.gmail.com>
Message-ID: <CANktQtu2G_q4_PunB2mBW7edLZsPU8xBh0Zv7warBb+X3whOcQ@mail.gmail.com>

Hi,

here is my 5 cents...

On Tue, Apr 11, 2017 at 10:52 PM, Brad King <brad.king at kitware.com> wrote:

> On 04/11/2017 11:41 AM, Petr Kmoch wrote:
> > Currently, adding a new source file to a CMake-controlled project
> > means doing two things: creating the file on disk, and adding it
> > to the relevant CMakeList add_library() or add_executable() call.
>
> I view this as a matching pair with an implicit sanity check.
>
+1

>
> > switch from current behaviour of "error out if source file is not found"
> > to "create empty source file if it's not found."
>
> So a typo in the `CMakeLists.txt` file leads to silent creation of a
> source file instead of an error message?
>
+1

doesn't looks like a good idea... also if someone (re)moved/renamed a file
intentionally and forget to update CMakeLists.txt (or just rerun `make`
which executes `cmake`)


> That said, I can see how the proposed feature might be useful when
> iteratively developing in an IDE.  Add the file to `CMakeLists.txt`,
> reconfigure, and open the new (now existing) file to edit in the IDE.
>

my personal practice completely the opposite:
in my CMakeLists I have a custom target to generate a source file from the
project specific template, so I just use CLI to generate a new file like:

    $ make new-class name=BlahBlah ns=Vendor::Project subdir=some/dir

and then go to corresponding CMakeLists.txt and add the generated source(s)
to a target
and thanks to `cmake` missed files are reported at configuration time


> > Is this something that would be acceptable into CMake? Any comments?
>
> I'd like to hear more opinions from others before considering it
> upstream.  It feels like a pretty personal workflow right now, and
> can be implemented in CMake code already (perhaps with the `SOURCES`
> target property to avoid separate lists).
>
> If this were to be done I'd first like to see a policy introduced to
> get rid of the magic extension guessing we do now.  Without knowing
> the full file name with confidence we wouldn't be able to create it.
>
> -Brad
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensou
> rce/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170412/3d219bd8/attachment.html>

From wouter.klouwen at youview.com  Tue Apr 11 13:24:50 2017
From: wouter.klouwen at youview.com (Wouter Klouwen)
Date: Tue, 11 Apr 2017 18:24:50 +0100
Subject: [cmake-developers] External projects & library dependencies
In-Reply-To: <806cae9d-161d-304f-db0a-8fea3470b068@kitware.com>
References: <58ED0549.4000205@youview.com>
 <806cae9d-161d-304f-db0a-8fea3470b068@kitware.com>
Message-ID: <58ED1162.8090503@youview.com>

Hi Brad,

thanks for taking the time to reply.

On 11/04/17 18:00, Brad King wrote:
> On 04/11/2017 12:33 PM, Wouter Klouwen wrote:
>> So in order to create a mega project I want to put all of the third
>> party packages into the build system using ExternalProject_Add.
>> This function does provide for targets in terms of build dependencies,
>> but this isn't quite enough. I need these packages to convey information
>> in the same way as was done through pkg-config files and provide
>> COMPILE_OPTIONS, INCLUDE_DIRECTORIES and LINK_LIBRARIES.
>>
>> All of this information is present once the ExternalProject is built as
>> it would be possible to invoke pkg-config afterwards. This is of course
>> too late for CMake to resolve this information at configure/build rule
>> creation time.
>>
>> Is there a better way of solving this other than effectively duplicating
>> the information in the pkg-config files so that CMake can read it at
>> generation time?
>
> Make your outer project a "superbuild" that does not compile anything
> itself but instead just uses ExternalProject_Add to build everything
> else in dependency order.  That way each project won't configure until
> all its dependencies are built.

Unfortunately this isn't really an option for us. There's a non trivial
amount of third party packages that take a non trivial amount of time to
compile.
Waiting for all of these to compile while not yet starting on our own
projects would create a very long critical path before the build could
fan out for all targets. This would have a detrimental impact on our
build performance.

I appreciate it's not a usual problem as this is for an embedded
platform where we have to cross build everything from scratch.

Thanks,
     W


This transmission contains information that may be confidential and contain personal views which are not necessarily those of YouView TV Ltd. YouView TV Ltd (Co No:7308805) is a limited liability company registered in England and Wales with its registered address at YouView TV Ltd, 3rd Floor, 10 Lower Thames Street, London, EC3R 6YT. For details see our web site at http://www.youview.com

From brad.king at kitware.com  Tue Apr 11 13:26:22 2017
From: brad.king at kitware.com (Brad King)
Date: Tue, 11 Apr 2017 13:26:22 -0400
Subject: [cmake-developers] Mirror CMake release files on GitHub?
In-Reply-To: <1571569.4BvSaT9Xuj@daneel.sf-tec.de>
References: <994afa24-2904-186f-b8ee-309b6639e03d@googlemail.com>
 <ea2cb101-4fc5-7857-651e-62a6a8385805@kitware.com>
 <1571569.4BvSaT9Xuj@daneel.sf-tec.de>
Message-ID: <8ab23c18-f326-d7c4-6cc1-e5fc1d0a8f31@kitware.com>

On 04/10/2017 05:56 PM, Rolf Eike Beer wrote:
>> Thanks.  I'll take a look at that when I get a chance.
> 
> Now would be a good time ;)

I wish it were but I can't make this a priority now.

Our admins did fix a network performance problem that led
to the OP's reported trouble so the speed from cmake.org
should be much better than it was.

-Brad


From charles.huet at gmail.com  Tue Apr 11 14:09:11 2017
From: charles.huet at gmail.com (Charles Huet)
Date: Tue, 11 Apr 2017 18:09:11 +0000
Subject: [cmake-developers] Fwd: Feature suggestion: auto-create missing
	files
In-Reply-To: <CANktQtu2G_q4_PunB2mBW7edLZsPU8xBh0Zv7warBb+X3whOcQ@mail.gmail.com>
References: <CAKohaZfOkuOKqVvTm5THdcDVMZyppsfsFkc=4mQobCTcn8ZF8Q@mail.gmail.com>
 <706e667e-61f6-41c0-2d4b-ec84108b6255@kitware.com>
 <CANktQtswo9M-PVPEcGetKq6zax=itep9Ok15bwYHUkq22mrHBQ@mail.gmail.com>
 <CANktQtu2G_q4_PunB2mBW7edLZsPU8xBh0Zv7warBb+X3whOcQ@mail.gmail.com>
Message-ID: <CAGTK6ma8wn62xRLw7c8cYO8XsFvd9+ersx_h8hEDi1Zn8uLOxw@mail.gmail.com>

I personally really like the approach taken by FastBuild where you can
specify a folder in which the source resides, and it will take care of
compiling all the files within.

A checksum to verify if there are new files, and if not no need to
reconfigure.

This could pretty much be used with globing as well, making it a more
useful feature.

Also, I really appreciate the fact that you can't forget an old source file
by mistake (removed in the CMakeLists.txt but not on disk) this way.

Just my 2 cents.

On Tue, Apr 11, 2017, 19:15 Alex Turbov <i.zaufi at gmail.com> wrote:

>
>
> Hi,
>
> here is my 5 cents...
>
> On Tue, Apr 11, 2017 at 10:52 PM, Brad King <brad.king at kitware.com> wrote:
>
> On 04/11/2017 11:41 AM, Petr Kmoch wrote:
> > Currently, adding a new source file to a CMake-controlled project
> > means doing two things: creating the file on disk, and adding it
> > to the relevant CMakeList add_library() or add_executable() call.
>
> I view this as a matching pair with an implicit sanity check.
>
> +1
>
>
> > switch from current behaviour of "error out if source file is not found"
> > to "create empty source file if it's not found."
>
> So a typo in the `CMakeLists.txt` file leads to silent creation of a
> source file instead of an error message?
>
> +1
>
> doesn't looks like a good idea... also if someone (re)moved/renamed a file
> intentionally and forget to update CMakeLists.txt (or just rerun `make`
> which executes `cmake`)
>
>
> That said, I can see how the proposed feature might be useful when
> iteratively developing in an IDE.  Add the file to `CMakeLists.txt`,
> reconfigure, and open the new (now existing) file to edit in the IDE.
>
>
> my personal practice completely the opposite:
> in my CMakeLists I have a custom target to generate a source file from the
> project specific template, so I just use CLI to generate a new file like:
>
>     $ make new-class name=BlahBlah ns=Vendor::Project subdir=some/dir
>
> and then go to corresponding CMakeLists.txt and add the generated
> source(s) to a target
> and thanks to `cmake` missed files are reported at configuration time
>
>
> > Is this something that would be acceptable into CMake? Any comments?
>
> I'd like to hear more opinions from others before considering it
> upstream.  It feels like a pretty personal workflow right now, and
> can be implemented in CMake code already (perhaps with the `SOURCES`
> target property to avoid separate lists).
>
> If this were to be done I'd first like to see a policy introduced to
> get rid of the magic extension guessing we do now.  Without knowing
> the full file name with confidence we wouldn't be able to create it.
>
> -Brad
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170411/61d60a95/attachment.html>

From neundorf at kde.org  Tue Apr 11 15:28:40 2017
From: neundorf at kde.org (Alexander Neundorf)
Date: Tue, 11 Apr 2017 21:28:40 +0200
Subject: [cmake-developers] Feature suggestion: auto-create missing files
In-Reply-To: <706e667e-61f6-41c0-2d4b-ec84108b6255@kitware.com>
References: <CAKohaZfOkuOKqVvTm5THdcDVMZyppsfsFkc=4mQobCTcn8ZF8Q@mail.gmail.com>
 <706e667e-61f6-41c0-2d4b-ec84108b6255@kitware.com>
Message-ID: <4107681.FqV4aImEyG@linux-l7nd>

On 2017 M04 11, Tue 11:52:52 CEST Brad King wrote:
> On 04/11/2017 11:41 AM, Petr Kmoch wrote:
> > Currently, adding a new source file to a CMake-controlled project
> > means doing two things: creating the file on disk, and adding it
> > to the relevant CMakeList add_library() or add_executable() call.
> 
> I view this as a matching pair with an implicit sanity check.
> 
> > switch from current behaviour of "error out if source file is not found"
> > to "create empty source file if it's not found."
> 
> So a typo in the `CMakeLists.txt` file leads to silent creation of a
> source file instead of an error message?
> 
> That said, I can see how the proposed feature might be useful when
> iteratively developing in an IDE.  Add the file to `CMakeLists.txt`,
> reconfigure, and open the new (now existing) file to edit in the IDE.
> 
> > Is this something that would be acceptable into CMake? Any comments?
> 
> I'd like to hear more opinions from others before considering it
> upstream.  It feels like a pretty personal workflow right now, and
> can be implemented in CMake code already (perhaps with the `SOURCES`
> target property to avoid separate lists).

personally I'm not convinced.
Technically it would violate the "the source dir is read-only" rule.
A typo would generate files. With multiple build dirs the behaviour will be 
slightly different in the two dirs.
...not very strong arguments, but OTOH touching the file manually is also not 
too complicated.

Alex


From rleigh at codelibre.net  Tue Apr 11 17:27:56 2017
From: rleigh at codelibre.net (Roger Leigh)
Date: Tue, 11 Apr 2017 22:27:56 +0100
Subject: [cmake-developers] External projects & library dependencies
In-Reply-To: <58ED1162.8090503@youview.com>
References: <58ED0549.4000205@youview.com>
 <806cae9d-161d-304f-db0a-8fea3470b068@kitware.com>
 <58ED1162.8090503@youview.com>
Message-ID: <60dc812e-3667-351c-6f29-34bffbcea79f@codelibre.net>

On 11/04/2017 18:24, Wouter Klouwen wrote:
> On 11/04/17 18:00, Brad King wrote:
>> On 04/11/2017 12:33 PM, Wouter Klouwen wrote:
>>> So in order to create a mega project I want to put all of the third
>>> party packages into the build system using ExternalProject_Add.
>>> This function does provide for targets in terms of build dependencies,
>>> but this isn't quite enough. I need these packages to convey information
>>> in the same way as was done through pkg-config files and provide
>>> COMPILE_OPTIONS, INCLUDE_DIRECTORIES and LINK_LIBRARIES.
>>>
>>> All of this information is present once the ExternalProject is built as
>>> it would be possible to invoke pkg-config afterwards. This is of course
>>> too late for CMake to resolve this information at configure/build rule
>>> creation time.
>>>
>>> Is there a better way of solving this other than effectively duplicating
>>> the information in the pkg-config files so that CMake can read it at
>>> generation time?
>>
>> Make your outer project a "superbuild" that does not compile anything
>> itself but instead just uses ExternalProject_Add to build everything
>> else in dependency order.  That way each project won't configure until
>> all its dependencies are built.
>
> Unfortunately this isn't really an option for us. There's a non trivial
> amount of third party packages that take a non trivial amount of time to
> compile.
> Waiting for all of these to compile while not yet starting on our own
> projects would create a very long critical path before the build could
> fan out for all targets. This would have a detrimental impact on our
> build performance.

That's not an insurmountable problem.  If your projects are buildable in 
parallel with the third-party sources, you can add each third-party
source, plus each first-party project, as a separate external project
and then build the entire collection in parallel.

The only thing that's changed with the superbuild vs a completely 
self-contained project is the location of the higher-level organisation. 
  With the superbuild, that is moved out into a separate project which 
coordinates the building of everything with appropriate inter-project 
dependencies.


Regards,
Roger

From florent.castelli at gmail.com  Tue Apr 11 18:06:08 2017
From: florent.castelli at gmail.com (Florent Castelli)
Date: Wed, 12 Apr 2017 00:06:08 +0200
Subject: [cmake-developers] Feature suggestion: auto-create missing files
In-Reply-To: <4107681.FqV4aImEyG@linux-l7nd>
References: <CAKohaZfOkuOKqVvTm5THdcDVMZyppsfsFkc=4mQobCTcn8ZF8Q@mail.gmail.com>
 <706e667e-61f6-41c0-2d4b-ec84108b6255@kitware.com>
 <4107681.FqV4aImEyG@linux-l7nd>
Message-ID: <547BD2E4-D903-4D6D-A7CB-7A557A04EAA4@gmail.com>

It is easy enough in recent CMake versions to list all the subdirectories and their targets recursively.
Then you can list their files, check if they exist and create them if you want.
It can be done with a macro in your project and doesn?t need upstream support.

The next possible solution would be to create the file on disk and use a glob to list all the files.
You would need to rerun CMake manually whenever you add a file.

I would say that both solutions are not really good, even dangerous.
But if you really want them, you can pick your poison.

/Florent

> On 11 Apr 2017, at 21:28, Alexander Neundorf <neundorf at kde.org> wrote:
> 
> On 2017 M04 11, Tue 11:52:52 CEST Brad King wrote:
>> On 04/11/2017 11:41 AM, Petr Kmoch wrote:
>>> Currently, adding a new source file to a CMake-controlled project
>>> means doing two things: creating the file on disk, and adding it
>>> to the relevant CMakeList add_library() or add_executable() call.
>> 
>> I view this as a matching pair with an implicit sanity check.
>> 
>>> switch from current behaviour of "error out if source file is not found"
>>> to "create empty source file if it's not found."
>> 
>> So a typo in the `CMakeLists.txt` file leads to silent creation of a
>> source file instead of an error message?
>> 
>> That said, I can see how the proposed feature might be useful when
>> iteratively developing in an IDE.  Add the file to `CMakeLists.txt`,
>> reconfigure, and open the new (now existing) file to edit in the IDE.
>> 
>>> Is this something that would be acceptable into CMake? Any comments?
>> 
>> I'd like to hear more opinions from others before considering it
>> upstream.  It feels like a pretty personal workflow right now, and
>> can be implemented in CMake code already (perhaps with the `SOURCES`
>> target property to avoid separate lists).
> 
> personally I'm not convinced.
> Technically it would violate the "the source dir is read-only" rule.
> A typo would generate files. With multiple build dirs the behaviour will be 
> slightly different in the two dirs.
> ...not very strong arguments, but OTOH touching the file manually is also not 
> too complicated.
> 
> Alex
> 
> -- 
> 
> Powered by www.kitware.com
> 
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
> 
> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
> 
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
> 
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
> 
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170412/776cc95b/attachment-0001.html>

From wouter.klouwen at youview.com  Wed Apr 12 09:01:19 2017
From: wouter.klouwen at youview.com (Wouter Klouwen)
Date: Wed, 12 Apr 2017 14:01:19 +0100
Subject: [cmake-developers] External projects & library dependencies
In-Reply-To: <60dc812e-3667-351c-6f29-34bffbcea79f@codelibre.net>
References: <58ED0549.4000205@youview.com>
 <806cae9d-161d-304f-db0a-8fea3470b068@kitware.com>
 <58ED1162.8090503@youview.com>
 <60dc812e-3667-351c-6f29-34bffbcea79f@codelibre.net>
Message-ID: <58EE251F.1000106@youview.com>

On 11/04/17 22:27, Roger Leigh wrote:
> [..] If your projects are buildable in
> parallel with the third-party sources, you can add each third-party
> source, plus each first-party project, as a separate external project
> and then build the entire collection in parallel.

We effectively have this arrangement in place already, except it's of
our own creation instead of being CMake rules. So yes, this approach
works in principle.

> The only thing that's changed with the superbuild vs a completely
> self-contained project is the location of the higher-level organisation.
>   With the superbuild, that is moved out into a separate project which
> coordinates the building of everything with appropriate inter-project
> dependencies.

What's also different in the level to which the machine can be loaded.
If you were to look at our graph of dependencies, it's not a very nicely
balanced one and some of the third party packages don't compile reliably
in parallel.
So in order to get the best and most even load on our build servers, it
makes sense to have a self contained CMake so that we have target level
dependencies, as opposed to project level.

I suppose there's not many generic solutions to this as without having a
"super build" it's a bit of a chicken-egg problem.

Thanks,
     W
This transmission contains information that may be confidential and contain personal views which are not necessarily those of YouView TV Ltd. YouView TV Ltd (Co No:7308805) is a limited liability company registered in England and Wales with its registered address at YouView TV Ltd, 3rd Floor, 10 Lower Thames Street, London, EC3R 6YT. For details see our web site at http://www.youview.com

From ben.boeckel at kitware.com  Wed Apr 12 09:52:05 2017
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Wed, 12 Apr 2017 09:52:05 -0400
Subject: [cmake-developers] Feature suggestion: auto-create missing files
In-Reply-To: <4107681.FqV4aImEyG@linux-l7nd>
References: <CAKohaZfOkuOKqVvTm5THdcDVMZyppsfsFkc=4mQobCTcn8ZF8Q@mail.gmail.com>
 <706e667e-61f6-41c0-2d4b-ec84108b6255@kitware.com>
 <4107681.FqV4aImEyG@linux-l7nd>
Message-ID: <20170412135205.GB15102@megas.kitware.com>

On Tue, Apr 11, 2017 at 21:28:40 +0200, Alexander Neundorf wrote:
> personally I'm not convinced.
> Technically it would violate the "the source dir is read-only" rule.
> A typo would generate files. With multiple build dirs the behaviour will be 
> slightly different in the two dirs.
> ...not very strong arguments, but OTOH touching the file manually is also not 
> too complicated.

On case-insensitive file systems, there's also the "what if it exists,
but not with matching case?" problem. What was intended. Sure, CMake
will currently just leave it alone, but does the file exist? Is the file
on disk a typo? I don't think CMake can make that decision.

--Ben

From petr.kmoch at gmail.com  Thu Apr 13 02:39:36 2017
From: petr.kmoch at gmail.com (Petr Kmoch)
Date: Thu, 13 Apr 2017 08:39:36 +0200
Subject: [cmake-developers] Feature suggestion: auto-create missing files
In-Reply-To: <20170412135205.GB15102@megas.kitware.com>
References: <CAKohaZfOkuOKqVvTm5THdcDVMZyppsfsFkc=4mQobCTcn8ZF8Q@mail.gmail.com>
 <706e667e-61f6-41c0-2d4b-ec84108b6255@kitware.com>
 <4107681.FqV4aImEyG@linux-l7nd>
 <20170412135205.GB15102@megas.kitware.com>
Message-ID: <CAKohaZcvmbDwWFS1urqwQa5-D13wAOPWcYDOTpP_xRDnzRSMAw@mail.gmail.com>

OK, I can see there's quite a few voices against and none for. Idea
scratched.

Thanks everyone for input.

Petr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170413/862ef156/attachment.html>

From konstantin at podsvirov.pro  Tue Apr 18 13:16:25 2017
From: konstantin at podsvirov.pro (Konstantin Podsvirov)
Date: Tue, 18 Apr 2017 20:16:25 +0300
Subject: [cmake-developers] [DISCUSSION] CMake Localization (L10N)
Message-ID: <1427501492535785@web43j.yandex.ru>

Draft code:

> set(GREETING "greeting message" # Optional default value
>  en "Hello, world!"
>  ru "??????, ???!")
>
> set(CMAKE_OUTPUT_LOCALE "en") # Or CMAKE_L10N_LOCALE...
> 
> message("$L10N{GREETING}") # Hello, world!
> 
> set(CMAKE_OUTPUT_LOCALE "fr")
>
> message("$L10N{GREETING}") # greeting text
>
> message("$L10N:ru{GREETING}") # ??????, ???!

Any feedback?

--
Regards,
Konstantin Podsvirov

From irwin at beluga.phys.uvic.ca  Tue Apr 18 18:04:46 2017
From: irwin at beluga.phys.uvic.ca (Alan W. Irwin)
Date: Tue, 18 Apr 2017 15:04:46 -0700 (PDT)
Subject: [cmake-developers] Fortran standards compliance for various
	compilers
Message-ID: <alpine.DEB.2.11.1704181441360.23291@enira.zlyna.ubzr>

I have just noticed that the CMake Fortran language support sets the
undocumented variable CMAKE_Fortran_COMPILER_SUPPORTS_F90. I haven't
looked into what test is applied to determine that variable, but
Fortran 90 is really old which means that variable is likely not too
useful since presumably most Fortran compilers already support
Fortran 95.

<Feature Request> What would really be useful is a list containing
what Fortran features from the Fortran 2003 and 2008 standards that the
given Fortran compiler supports.  That information is already
published (for 11 different Fortran compilers at
<http://www.fortranplus.co.uk/app/download/23704631/fortran_2003_2008_compiler_support.pdf>)
so it should be straightforward to make that same information
available via a CMake list for the subset of those 11 compilers that
CMake supports. </Feature Request>

Is there any interest in implementing this feature request?

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

From eike at sf-mail.de  Wed Apr 19 01:27:20 2017
From: eike at sf-mail.de (Rolf Eike Beer)
Date: Wed, 19 Apr 2017 07:27:20 +0200
Subject: [cmake-developers] Fortran standards compliance for various
	compilers
In-Reply-To: <alpine.DEB.2.11.1704181441360.23291@enira.zlyna.ubzr>
References: <alpine.DEB.2.11.1704181441360.23291@enira.zlyna.ubzr>
Message-ID: <6849746.2ru3vbWqPR@daneel.sf-tec.de>

> <Feature Request> What would really be useful is a list containing
> what Fortran features from the Fortran 2003 and 2008 standards that the
> given Fortran compiler supports.  That information is already

To name the kid: this is about adding CMAKE_Fortran_KNOWN_FEATURES and 
friends, no? This exactly sounds like the whole compile_features things 
already done for C and C++, so yet another language shouldn't be too hard I 
guess.

Eike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170419/f13a2a71/attachment.sig>

From domen.vrankar at gmail.com  Wed Apr 19 02:52:23 2017
From: domen.vrankar at gmail.com (Domen Vrankar)
Date: Wed, 19 Apr 2017 08:52:23 +0200
Subject: [cmake-developers] [DISCUSSION] CMake Localization (L10N)
In-Reply-To: <1427501492535785@web43j.yandex.ru>
References: <1427501492535785@web43j.yandex.ru>
Message-ID: <CAKgx6BK71WRLFJTNWsUdxrOeNqDZJs6z9F+qVRHi6tBgwn8tFA@mail.gmail.com>

2017-04-18 19:16 GMT+02:00 Konstantin Podsvirov <konstantin at podsvirov.pro>:

> Draft code:
>
> > set(GREETING "greeting message" # Optional default value
> >  en "Hello, world!"
> >  ru "??????, ???!")
> >
> > set(CMAKE_OUTPUT_LOCALE "en") # Or CMAKE_L10N_LOCALE...
> >
> > message("$L10N{GREETING}") # Hello, world!
> >
> > set(CMAKE_OUTPUT_LOCALE "fr")
> >
> > message("$L10N{GREETING}") # greeting text
> >
> > message("$L10N:ru{GREETING}") # ??????, ???!
>
> Any feedback?


Coming from a small country I'm not too keen on localization as it makes my
life harder - in case of an error I have to guess what the english version
of the error message would look like just to get results on Google.

I somewhat understand the wish of non programmers to see text in their own
language but for developers english is de facto programming standard
language so I don't see a reason for such an addition.

That being said I'd suggest a more generic alternative that can be used for
things other than localization:

Access by array position:
> set(GREETING "greeting message" "Hello, world!" "??????, ???!")
> message(${GREETING}) # prints "greeting message"
> message(${GREETING:0}) # also prints "greeting message"
> message(${GREETING:1}) # prints "Hello, world!"
> message(${GREETING:2}) # prints "??????, ???!"
where the underlying structure of GREETING is "greeting message;Hello,
world!;??????, ???!"

Or taking that even further by defining maps:
> set(GREETING "greeting message" "en:Hello, world!" "ru:??????, ???!")
> message(${GREETING}) # prints "greeting message"
> message(${GREETING:}) # also prints "greeting message"
> message(${GREETING:en}) # prints "Hello, world!"
> message(${GREETING:ru}) # prints "??????, ???!"
where the underlying structure of GREETING is "greeting message;en:Hello,
world!;ru:??????, ???!"

This could then be used for e.g. for creating enums e.g.:
> set(BUILD_TYPE_OPTIONS "default_flags" "Debug:debug_flags"
"Release:release_flags" ...)
> message("using flags:  ${CMAKE_BUILD_TYPE_OPTIONS:${CMAKE_BUILD_TYPE}}")
# error if outside of range (e.g. OddRelease was specified for
CMAKE_BUILD_TYPE)

For this to really be useful support for if() command would also be
required.

Regards,
Domen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170419/50ec7dea/attachment.html>

From brad.king at kitware.com  Wed Apr 19 13:53:02 2017
From: brad.king at kitware.com (Brad King)
Date: Wed, 19 Apr 2017 13:53:02 -0400
Subject: [cmake-developers] [DISCUSSION] CMake Localization (L10N)
In-Reply-To: <CAKgx6BK71WRLFJTNWsUdxrOeNqDZJs6z9F+qVRHi6tBgwn8tFA@mail.gmail.com>
References: <1427501492535785@web43j.yandex.ru>
 <CAKgx6BK71WRLFJTNWsUdxrOeNqDZJs6z9F+qVRHi6tBgwn8tFA@mail.gmail.com>
Message-ID: <06cbb70d-dfc8-384c-d14e-25a4ab91173c@kitware.com>

On 04/19/2017 02:52 AM, Domen Vrankar wrote:
> I somewhat understand the wish of non programmers to see text in
> their own language but for developers english is de facto programming
> standard language so I don't see a reason for such an addition.

This is a good point.  I'd be hesitant to move forward with anything
in upstream CMake without broader interest.

> Or taking that even further by defining maps:
>> set(GREETING "greeting message" "en:Hello, world!" "ru:??????, ???!")
>> message(${GREETING}) # prints "greeting message"
>> message(${GREETING:}) # also prints "greeting message"
>> message(${GREETING:en}) # prints "Hello, world!"
>> message(${GREETING:ru}) # prints "??????, ???!"

This can be done already in the CMake language:

```
set("en.GREETING" "Hello world!")
set("ru.GREETING" "??????, ???!")
set(l10n ru)
message(STATUS "${${l10n}.GREETING}") # ??????, ???!
```

A macro or function could be used to improve the ergonomics of
defining the table.

-Brad


From i.zaufi at gmail.com  Wed Apr 19 14:44:34 2017
From: i.zaufi at gmail.com (Alex Turbov)
Date: Thu, 20 Apr 2017 01:44:34 +0700
Subject: [cmake-developers] [DISCUSSION] CMake Localization (L10N)
In-Reply-To: <CAKgx6BK71WRLFJTNWsUdxrOeNqDZJs6z9F+qVRHi6tBgwn8tFA@mail.gmail.com>
References: <1427501492535785@web43j.yandex.ru>
 <CAKgx6BK71WRLFJTNWsUdxrOeNqDZJs6z9F+qVRHi6tBgwn8tFA@mail.gmail.com>
Message-ID: <CANktQtvZRWckxWxQwhxbjNyW5BuAmB+acM93NzrDtgtNOj3vdQ@mail.gmail.com>

absolutely agreed.


On Wed, Apr 19, 2017 at 1:52 PM, Domen Vrankar <domen.vrankar at gmail.com>
wrote:

> 2017-04-18 19:16 GMT+02:00 Konstantin Podsvirov <konstantin at podsvirov.pro>
> :
>
>> Draft code:
>>
>> > set(GREETING "greeting message" # Optional default value
>> >  en "Hello, world!"
>> >  ru "??????, ???!")
>> >
>> > set(CMAKE_OUTPUT_LOCALE "en") # Or CMAKE_L10N_LOCALE...
>> >
>> > message("$L10N{GREETING}") # Hello, world!
>> >
>> > set(CMAKE_OUTPUT_LOCALE "fr")
>> >
>> > message("$L10N{GREETING}") # greeting text
>> >
>> > message("$L10N:ru{GREETING}") # ??????, ???!
>>
>> Any feedback?
>
>
> Coming from a small country I'm not too keen on localization as it makes
> my life harder - in case of an error I have to guess what the english
> version of the error message would look like just to get results on Google.
>
> I somewhat understand the wish of non programmers to see text in their own
> language but for developers english is de facto programming standard
> language so I don't see a reason for such an addition.
>
> That being said I'd suggest a more generic alternative that can be used
> for things other than localization:
>
> Access by array position:
> > set(GREETING "greeting message" "Hello, world!" "??????, ???!")
> > message(${GREETING}) # prints "greeting message"
> > message(${GREETING:0}) # also prints "greeting message"
> > message(${GREETING:1}) # prints "Hello, world!"
> > message(${GREETING:2}) # prints "??????, ???!"
> where the underlying structure of GREETING is "greeting message;Hello,
> world!;??????, ???!"
>
> Or taking that even further by defining maps:
> > set(GREETING "greeting message" "en:Hello, world!" "ru:??????, ???!")
> > message(${GREETING}) # prints "greeting message"
> > message(${GREETING:}) # also prints "greeting message"
> > message(${GREETING:en}) # prints "Hello, world!"
> > message(${GREETING:ru}) # prints "??????, ???!"
> where the underlying structure of GREETING is "greeting message;en:Hello,
> world!;ru:??????, ???!"
>
> This could then be used for e.g. for creating enums e.g.:
> > set(BUILD_TYPE_OPTIONS "default_flags" "Debug:debug_flags"
> "Release:release_flags" ...)
> > message("using flags:  ${CMAKE_BUILD_TYPE_OPTIONS:${CMAKE_BUILD_TYPE}}")
> # error if outside of range (e.g. OddRelease was specified for
> CMAKE_BUILD_TYPE)
>
> For this to really be useful support for if() command would also be
> required.
>
> Regards,
> Domen
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170420/d2853c24/attachment.html>

From irwin at beluga.phys.uvic.ca  Wed Apr 19 16:12:32 2017
From: irwin at beluga.phys.uvic.ca (Alan W. Irwin)
Date: Wed, 19 Apr 2017 13:12:32 -0700 (PDT)
Subject: [cmake-developers] [Feature Request] Fortran standards
 compliance for various compilers
In-Reply-To: <6849746.2ru3vbWqPR@daneel.sf-tec.de>
References: <alpine.DEB.2.11.1704181441360.23291@enira.zlyna.ubzr>
 <6849746.2ru3vbWqPR@daneel.sf-tec.de>
Message-ID: <alpine.DEB.2.11.1704191054320.23291@enira.zlyna.ubzr>

On 2017-04-19 07:27+0200 Rolf Eike Beer wrote:

>> <Feature Request> What would really be useful is a list containing
>> what Fortran features from the Fortran 2003 and 2008 standards that the
>> given Fortran compiler supports.  That information is already
>
> To name the kid: this is about adding CMAKE_Fortran_KNOWN_FEATURES and
> friends, no?

I wasn't aware of CMAKE_C_KNOWN_FEATURES and CMAKE_CXX_KNOWN_FEATURES,
but now that I have looked them up, I agree adding
CMAKE_Fortran_KNOWN_FEATURES is the right way to go rather than the
generic list I proposed above.

> This exactly sounds like the whole compile_features things
> already done for C and C++, so yet another language shouldn't be too hard I
> guess.

Especially since that Fortran information is already collected in
well-organized form in on one place, namely
<http://www.fortranplus.co.uk/app/download/23704631/fortran_2003_2008_compiler_support.pdf>.

It appears we are in consensus so it is time to put this idea into the
bug tracker as a feature request.  However, when I attempted to do
that following your FAQ, I could not get access to
<https://gitlab.kitware.com/users/sign_in> with the login identity
irwin at beluga.phys.uvic.ca.  I have never used that bug tracker before,
but I thought at least that login identity would have be copied from
the old Mantis bugtracker.  But using my old Mantis bugtracker
password failed and clicking on "forgot password" or "Request a new
one" (which presumably should work even if gitlab does not have
irwin at beluga.phys.uvic.ca registered as a login identity) did not send
any e-mail response at all to the above address.  And, yes, all mail
gets through to me except that spam_bayes sorts it into the INBOX,
sb_unsure, and sb_spam folders based solely on word counts, and mail
from your gitlab bug tracker showed up at none of those places after a
~half hour wait.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

From brad.king at kitware.com  Wed Apr 19 16:26:33 2017
From: brad.king at kitware.com (Brad King)
Date: Wed, 19 Apr 2017 16:26:33 -0400
Subject: [cmake-developers] gitlab.kitware.com sign in
In-Reply-To: <alpine.DEB.2.11.1704191054320.23291@enira.zlyna.ubzr>
References: <alpine.DEB.2.11.1704181441360.23291@enira.zlyna.ubzr>
 <6849746.2ru3vbWqPR@daneel.sf-tec.de>
 <alpine.DEB.2.11.1704191054320.23291@enira.zlyna.ubzr>
Message-ID: <b853ecda-a086-1e0f-0e64-032364068829@kitware.com>

On 04/19/2017 04:12 PM, Alan W. Irwin wrote:
> It appears we are in consensus so it is time to put this idea into the
> bug tracker as a feature request.  However, when I attempted to do
> that following your FAQ, I could not get access to
> <https://gitlab.kitware.com/users/sign_in> with the login identity
> irwin at beluga.phys.uvic.ca.  I have never used that bug tracker before,
> but I thought at least that login identity would have be copied from
> the old Mantis bugtracker.

No, GitLab is a whole new service.  It is far more than a bug tracker
and has no way to migrate users from Mantis.  Please sign up for a new
account.  If you already have a github.com account you can use that
to register and authenticate via GitHub OAuth.  Otherwise just doing
a normal username/password registration is fine.

-Brad


From irwin at beluga.phys.uvic.ca  Wed Apr 19 17:14:38 2017
From: irwin at beluga.phys.uvic.ca (Alan W. Irwin)
Date: Wed, 19 Apr 2017 14:14:38 -0700 (PDT)
Subject: [cmake-developers] [Feature Request] Fortran standards
 compliance for various compilers
In-Reply-To: <alpine.DEB.2.11.1704191054320.23291@enira.zlyna.ubzr>
References: <alpine.DEB.2.11.1704181441360.23291@enira.zlyna.ubzr>
 <6849746.2ru3vbWqPR@daneel.sf-tec.de>
 <alpine.DEB.2.11.1704191054320.23291@enira.zlyna.ubzr>
Message-ID: <alpine.DEB.2.11.1704191412230.23291@enira.zlyna.ubzr>

On 2017-04-19 13:12-0700 Alan W. Irwin wrote:

> It appears we are in consensus so it is time to put this idea into the
> bug tracker as a feature request.

OK. It was a bit of a struggle, but with list help from Brad with a
different subject line I finally got registered and generated the
desired feature request (CMake issue #16819).  Good luck to the CMake
developers in dealing with this issue.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

From rcdailey.lists at gmail.com  Thu Apr 20 15:31:58 2017
From: rcdailey.lists at gmail.com (Robert Dailey)
Date: Thu, 20 Apr 2017 14:31:58 -0500
Subject: [cmake-developers] Support for unified headers in Android NDK
Message-ID: <CAHd499CARgD=Aw1Hiwu5=qdQ-nVt0=G1vb=-n1-NGQmqL362TA@mail.gmail.com>

Google is supporting unified headers for sysroot as of NDK r14:

https://android.googlesource.com/platform/ndk/+/master/docs/UnifiedHeaders.md

Is there a plan to add support for this natively into CMake?

From brad.king at kitware.com  Thu Apr 20 15:35:54 2017
From: brad.king at kitware.com (Brad King)
Date: Thu, 20 Apr 2017 15:35:54 -0400
Subject: [cmake-developers] Support for unified headers in Android NDK
In-Reply-To: <CAHd499CARgD=Aw1Hiwu5=qdQ-nVt0=G1vb=-n1-NGQmqL362TA@mail.gmail.com>
References: <CAHd499CARgD=Aw1Hiwu5=qdQ-nVt0=G1vb=-n1-NGQmqL362TA@mail.gmail.com>
Message-ID: <0a0e4016-d6a2-0c45-ff09-e83a1ec40a39@kitware.com>

On 04/20/2017 03:31 PM, Robert Dailey wrote:
> Google is supporting unified headers for sysroot as of NDK r14:
> 
> https://android.googlesource.com/platform/ndk/+/master/docs/UnifiedHeaders.md
> 
> Is there a plan to add support for this natively into CMake?

See issue here:

 https://gitlab.kitware.com/cmake/cmake/issues/16584

Linked from the issue is a partially completed MR to fix it but
it was never finished to the point of being ready to merge.

-Brad


From ben.boeckel at kitware.com  Thu Apr 20 15:52:18 2017
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Thu, 20 Apr 2017 15:52:18 -0400
Subject: [cmake-developers] Support for unified headers in Android NDK
In-Reply-To: <CAHd499CARgD=Aw1Hiwu5=qdQ-nVt0=G1vb=-n1-NGQmqL362TA@mail.gmail.com>
References: <CAHd499CARgD=Aw1Hiwu5=qdQ-nVt0=G1vb=-n1-NGQmqL362TA@mail.gmail.com>
Message-ID: <20170420195218.GB24773@megas.kitware.com>

On Thu, Apr 20, 2017 at 14:31:58 -0500, Robert Dailey wrote:
> Google is supporting unified headers for sysroot as of NDK r14:
> 
> https://android.googlesource.com/platform/ndk/+/master/docs/UnifiedHeaders.md
> 
> Is there a plan to add support for this natively into CMake?

There is a merge request that is in-progress, but was closed due to
inactivity (lack of time on Florent's side it seems). I'd recommend
coordinating with Florent to resurrect the MR.

    https://gitlab.kitware.com/cmake/cmake/merge_requests/492

--Ben

From rcdailey.lists at gmail.com  Thu Apr 20 16:10:22 2017
From: rcdailey.lists at gmail.com (Robert Dailey)
Date: Thu, 20 Apr 2017 15:10:22 -0500
Subject: [cmake-developers] Support for unified headers in Android NDK
In-Reply-To: <20170420195218.GB24773@megas.kitware.com>
References: <CAHd499CARgD=Aw1Hiwu5=qdQ-nVt0=G1vb=-n1-NGQmqL362TA@mail.gmail.com>
 <20170420195218.GB24773@megas.kitware.com>
Message-ID: <CAHd499CxWbQ1N6QDL3zXoQMDPsayw6mo7a0u0Dv1vEjshOOOjQ@mail.gmail.com>

I may pick this up, because right now it's impossible to use libc++
(LLVM) with an API less than 21 since that's when clang was
introduced. libc is missing too many symbols that are required by
libc++ below API 21.

On Thu, Apr 20, 2017 at 2:52 PM, Ben Boeckel <ben.boeckel at kitware.com> wrote:
> On Thu, Apr 20, 2017 at 14:31:58 -0500, Robert Dailey wrote:
>> Google is supporting unified headers for sysroot as of NDK r14:
>>
>> https://android.googlesource.com/platform/ndk/+/master/docs/UnifiedHeaders.md
>>
>> Is there a plan to add support for this natively into CMake?
>
> There is a merge request that is in-progress, but was closed due to
> inactivity (lack of time on Florent's side it seems). I'd recommend
> coordinating with Florent to resurrect the MR.
>
>     https://gitlab.kitware.com/cmake/cmake/merge_requests/492
>
> --Ben

From florent.castelli at gmail.com  Thu Apr 20 17:14:50 2017
From: florent.castelli at gmail.com (Florent Castelli)
Date: Thu, 20 Apr 2017 23:14:50 +0200
Subject: [cmake-developers] Support for unified headers in Android NDK
In-Reply-To: <CAHd499CxWbQ1N6QDL3zXoQMDPsayw6mo7a0u0Dv1vEjshOOOjQ@mail.gmail.com>
References: <CAHd499CARgD=Aw1Hiwu5=qdQ-nVt0=G1vb=-n1-NGQmqL362TA@mail.gmail.com>
 <20170420195218.GB24773@megas.kitware.com>
 <CAHd499CxWbQ1N6QDL3zXoQMDPsayw6mo7a0u0Dv1vEjshOOOjQ@mail.gmail.com>
Message-ID: <CACTXgOYGw+kEzW2cTdHvyqA0ZG_tJc1B5QQV6g_BVR906gCqgA@mail.gmail.com>

I just came back from some holidays now, I'll try to update the MR with the
latest changes soon next week!

/Florent

On Apr 20, 2017 10:10 PM, "Robert Dailey" <rcdailey.lists at gmail.com> wrote:

> I may pick this up, because right now it's impossible to use libc++
> (LLVM) with an API less than 21 since that's when clang was
> introduced. libc is missing too many symbols that are required by
> libc++ below API 21.
>
> On Thu, Apr 20, 2017 at 2:52 PM, Ben Boeckel <ben.boeckel at kitware.com>
> wrote:
> > On Thu, Apr 20, 2017 at 14:31:58 -0500, Robert Dailey wrote:
> >> Google is supporting unified headers for sysroot as of NDK r14:
> >>
> >> https://android.googlesource.com/platform/ndk/+/master/
> docs/UnifiedHeaders.md
> >>
> >> Is there a plan to add support for this natively into CMake?
> >
> > There is a merge request that is in-progress, but was closed due to
> > inactivity (lack of time on Florent's side it seems). I'd recommend
> > coordinating with Florent to resurrect the MR.
> >
> >     https://gitlab.kitware.com/cmake/cmake/merge_requests/492
> >
> > --Ben
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170420/00a221bc/attachment.html>

From mhanna21 at bloomberg.net  Thu Apr 20 17:16:55 2017
From: mhanna21 at bloomberg.net (Matthew Hanna (BLOOMBERG/ 731 LEX))
Date: Thu, 20 Apr 2017 21:16:55 -0000
Subject: [cmake-developers]
	=?utf-8?q?Proposal_to_disable_link_depends_inf?=
	=?utf-8?q?erence=2E?=
Message-ID: <58F92547023E00CC00390A68_0_59215@msllnjpmsgsv06>

After checking several approaches, it looks as though the number of
edges in the inference algorithm is the bottleneck, regardless of the
number of cycles inferred.  In our particular case, the number of
external dependencies far outnumbers the known, internal libraries.
Also, since we are using pkg-config, the external dependencies are
not well ordered, so inferences involving two external deps are bound
to be misleading.  Given that, the approach we are considering is to
avoid adding the external to external edges, but still leave all edges
that contain at least one known library.  The desired effect is
sketched out in the following commit:

https://gitlab.kitware.com/mhanna21/cmake/commit/2c7d2e33b6218e58f88957fb793ce0a781ec76aa

Thanks,
Matthew

From: mhanna21 at bloomberg.net At: 04/11/17 12:05:50
To: cmake-developers at cmake.org
Subject: Re: [cmake-developers] Proposal to disable link depends inference.

Yes, disabling the 'magic guessing' is the primary goal.  I just wanted
to test the waters before embarking on a patch.  Will continue the
conversation once I have a patch ready that solves our problem.

Thanks,
Matthew
From: brad.king at kitware.com At: 04/11/17 11:16:27
To: cmake-developers at cmake.org
Subject: Re: [cmake-developers] Proposal to disable link depends inference.

On 04/11/2017 09:34 AM, Matthew Hanna (BLOOMBERG/ 731 LEX) wrote:
> The inference logic in cmComputeLinkDepends.cxx is both inefficient and
> superfluous for our specific use case. I am proposing a global setting that
> would disable the link computation entirely for those that wish to take full
> responsibility of the ordering of dependencies.

IIUC you're not talking about disabling the entire dependency analysis
but instead just turning off the magic guessing of implicit dependencies
based on observed order.  Correct?

Before we bikeshed the name and form of the setting, can you post a patch
that just removes the logic outright so we can see exactly what you mean?

Thanks,
-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers


         -- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170420/fb7c0f2c/attachment-0001.html>

From rcdailey.lists at gmail.com  Fri Apr 21 09:34:49 2017
From: rcdailey.lists at gmail.com (Robert Dailey)
Date: Fri, 21 Apr 2017 08:34:49 -0500
Subject: [cmake-developers] Support for unified headers in Android NDK
In-Reply-To: <CACTXgOYGw+kEzW2cTdHvyqA0ZG_tJc1B5QQV6g_BVR906gCqgA@mail.gmail.com>
References: <CAHd499CARgD=Aw1Hiwu5=qdQ-nVt0=G1vb=-n1-NGQmqL362TA@mail.gmail.com>
 <20170420195218.GB24773@megas.kitware.com>
 <CAHd499CxWbQ1N6QDL3zXoQMDPsayw6mo7a0u0Dv1vEjshOOOjQ@mail.gmail.com>
 <CACTXgOYGw+kEzW2cTdHvyqA0ZG_tJc1B5QQV6g_BVR906gCqgA@mail.gmail.com>
Message-ID: <CAHd499BBmrmgFuLi8cXx11U8zDJ_LCieTZabOq-sBzsdmnn7MQ@mail.gmail.com>

Thanks Florent!

Let me know if you need any help, especially testing. I have a real
world use case for this at $DAYJOB.

On Thu, Apr 20, 2017 at 4:14 PM, Florent Castelli
<florent.castelli at gmail.com> wrote:
> I just came back from some holidays now, I'll try to update the MR with the
> latest changes soon next week!
>
> /Florent
>
> On Apr 20, 2017 10:10 PM, "Robert Dailey" <rcdailey.lists at gmail.com> wrote:
>>
>> I may pick this up, because right now it's impossible to use libc++
>> (LLVM) with an API less than 21 since that's when clang was
>> introduced. libc is missing too many symbols that are required by
>> libc++ below API 21.
>>
>> On Thu, Apr 20, 2017 at 2:52 PM, Ben Boeckel <ben.boeckel at kitware.com>
>> wrote:
>> > On Thu, Apr 20, 2017 at 14:31:58 -0500, Robert Dailey wrote:
>> >> Google is supporting unified headers for sysroot as of NDK r14:
>> >>
>> >>
>> >> https://android.googlesource.com/platform/ndk/+/master/docs/UnifiedHeaders.md
>> >>
>> >> Is there a plan to add support for this natively into CMake?
>> >
>> > There is a merge request that is in-progress, but was closed due to
>> > inactivity (lack of time on Florent's side it seems). I'd recommend
>> > coordinating with Florent to resurrect the MR.
>> >
>> >     https://gitlab.kitware.com/cmake/cmake/merge_requests/492
>> >
>> > --Ben
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more
>> information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/cmake-developers

From brad.king at kitware.com  Fri Apr 21 10:08:59 2017
From: brad.king at kitware.com (Brad King)
Date: Fri, 21 Apr 2017 10:08:59 -0400
Subject: [cmake-developers] Proposal to disable link depends inference.
In-Reply-To: <58F92547023E00CC00390A68_0_59215@msllnjpmsgsv06>
References: <58F92547023E00CC00390A68_0_59215@msllnjpmsgsv06>
Message-ID: <86a00c6f-af58-ee4a-c58e-43487ea0b085@kitware.com>

On 04/20/2017 05:16 PM, Matthew Hanna (BLOOMBERG/ 731 LEX) wrote:
> avoid adding the external to external edges
> https://gitlab.kitware.com/mhanna21/cmake/commit/2c7d2e33b6218e58f88957fb793ce0a781ec76aa

That sounds good.  From the patch:

> +      if (this->EntryList[depender_index].Target ||
> +          this->EntryList[(int)*edge].Target) {
> +        edges.push_back(*edge);
> +      }

I think only the second condition is needed.  To check, try adding:

  assert(!this->EntryList[depender_index].Target);

there.  I don't think internal targets can get an InferredDependSets
entry, according to logic in `cmComputeLinkDepends::AddLinkEntry`.

-Brad


From cpfeiffer at live.de  Fri Apr 21 17:45:18 2017
From: cpfeiffer at live.de (Christian P.)
Date: Fri, 21 Apr 2017 21:45:18 +0000
Subject: [cmake-developers] Adding Microsoft MPI Fortran support in FindMPI
Message-ID: <AM5P194MB00346534AC9779901BA43256AD1A0@AM5P194MB0034.EURP194.PROD.OUTLOOK.COM>

Hi folks,

I?d like to implement support for MSMPI?s Fortran API in FindMPI so that it could be used to build ScaLAPACK and others. However, I?m looking for a bit of guidance on how to do this.

The Fortran 90 interfaces are contained in a file called mpi.f90 in the MSMPI include folder. This file has to be built with the Fortran compiler employed by the user and will generate the mpi module used by MPI code (there?s no mpi_f08 module provided). However, I don?t know how to handle this: If I add it to MPI::MPI_Fortran via INTERFACE_SOURCES, then it would break parallel builds as soon as two targets with the same module path were built, since the file could be overwritten at any time causing consuming build processes to read a partially written file.

In a way, FindMPI would need to compile the file itself as a static library and link the output and add the folder with the module to its includes. Yet, this can become a problem because of target visibility. My idea is therefore to add a static library in the FindMPI module containing just the mpi.f90 module and creating an imported target pointing to it in order to wrap up visibility.

Is this a good/bad idea or is there any way to do this in a proper fashion? The idea of adding an actual target to a Find module seems wrong to me, but I?m not seeing any way of doing it otherwise.


For reference, I?ve added the full list of steps that one needs to do for linking Fortran code with MSMPI below:

  1.  Add the x86/x64 include folder in the MSMPI folder containing mpifptr.h (not a problem at all)
  2.  Link one of msmpifec/es/mc/ms.lib ? The difference between these libraries is that the ?c?/?s? versions are for Fortran implementations using the ?cdecl? and ?stdcall? calling conventions, respectively. The ?m? versions are for Fortran implementations putting the size of a CHARACTER* argument immediately after the pointer in a call?s parameter list, and the ?e? ones for those that put them at the end of the parameter list.

For virtually all Fortran compilers (including PGI and Intel), the msmpifec is the right library and the msmpifms one is only needed for Compaq Visual Fortran (Intel Fortran predecessor) or when changing the default in ifort, see also https://software.intel.com/en-us/node/528352 for MKL?s handling of the matter.

I believe jus using the ?ec? version in all cases is therefore okay for CMake, and I wouldn?t know of a good way to otherwise detect a correct value.

  1.  (Only if the Fortran 90 mpi module is to be used. Not necessary for the F77 interfaces) Compile mpi.f90, link the output and include the folder containing the emitted Fortran module.

- Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170421/1f81cd85/attachment.html>

From cbergstrom at pathscale.com  Sat Apr 22 01:33:57 2017
From: cbergstrom at pathscale.com (=?UTF-8?B?QyBCZXJnc3Ryw7Zt?=)
Date: Sat, 22 Apr 2017 13:33:57 +0800
Subject: [cmake-developers] [Feature Request] Fortran standards
 compliance for various compilers
In-Reply-To: <alpine.DEB.2.11.1704191054320.23291@enira.zlyna.ubzr>
References: <alpine.DEB.2.11.1704181441360.23291@enira.zlyna.ubzr>
 <6849746.2ru3vbWqPR@daneel.sf-tec.de>
 <alpine.DEB.2.11.1704191054320.23291@enira.zlyna.ubzr>
Message-ID: <CAOnawYrf1Hzrds+ecUUJa6Ls6o7L65Ubbj7xHjPkWyb0Lhya7w@mail.gmail.com>

On Thu, Apr 20, 2017 at 4:12 AM, Alan W. Irwin
<irwin at beluga.phys.uvic.ca> wrote:
> On 2017-04-19 07:27+0200 Rolf Eike Beer wrote:
>
>>> <Feature Request> What would really be useful is a list containing
>>> what Fortran features from the Fortran 2003 and 2008 standards that the
>>> given Fortran compiler supports.  That information is already
>>
>>
>> To name the kid: this is about adding CMAKE_Fortran_KNOWN_FEATURES and
>> friends, no?
>
>
> I wasn't aware of CMAKE_C_KNOWN_FEATURES and CMAKE_CXX_KNOWN_FEATURES,
> but now that I have looked them up, I agree adding
> CMAKE_Fortran_KNOWN_FEATURES is the right way to go rather than the
> generic list I proposed above.
>
>> This exactly sounds like the whole compile_features things
>> already done for C and C++, so yet another language shouldn't be too hard
>> I
>> guess.
>
>
> Especially since that Fortran information is already collected in
> well-organized form in on one place, namely
> <http://www.fortranplus.co.uk/app/download/23704631/fortran_2003_2008_compiler_support.pdf>.

With my Fortran compiler vendor hat on - Please do be aware that this
list of supported features may not be 100% accurate.

#1 Vendors can add support that hasn't been reflected in that document

#2 Not all claimed support is created equal. There's quite a few F2K3
OO features that someone can claim to support, but when you start
digging into real code they just flat out fail. (maybe less of the
case now than it was before)

#3 F2K8 aka CAF features could be supported, but may require
additional runtime libraries or 3rd party software to actually work.
For example our implementation ties to specific hardware and may not
be 100% portable. Other implementations may depend on OpenMPI and not
work with MPICH.

I guess I'm saying that auto-detecting this stuff is cool, but do
ensure that someone can easily override it. If as a vendor I say we
support F2K8 and I'd like that enabled by default for supported
versions of the compiler I really don't want to fight against some
auto-test which might think otherwise.


Thanks

From cpfeiffer at live.de  Sat Apr 22 07:30:55 2017
From: cpfeiffer at live.de (Christian Pfeiffer)
Date: Sat, 22 Apr 2017 11:30:55 +0000
Subject: [cmake-developers] [Feature Request] Fortran standards
 compliance for various compilers
In-Reply-To: <CAOnawYrf1Hzrds+ecUUJa6Ls6o7L65Ubbj7xHjPkWyb0Lhya7w@mail.gmail.com>
References: <alpine.DEB.2.11.1704181441360.23291@enira.zlyna.ubzr>
 <6849746.2ru3vbWqPR@daneel.sf-tec.de>
 <alpine.DEB.2.11.1704191054320.23291@enira.zlyna.ubzr>
 <CAOnawYrf1Hzrds+ecUUJa6Ls6o7L65Ubbj7xHjPkWyb0Lhya7w@mail.gmail.com>
Message-ID: <AM5P194MB0034EC9289DBCC657945CD6CAD1D0@AM5P194MB0034.EURP194.PROD.OUTLOOK.COM>

On 4/22/2017 7:33 AM, C Bergstr?m wrote:

> On Thu, Apr 20, 2017 at 4:12 AM, Alan W. Irwin
> <irwin at beluga.phys.uvic.ca> wrote:
>> On 2017-04-19 07:27+0200 Rolf Eike Beer wrote:
>>
>>>> <Feature Request> What would really be useful is a list containing
>>>> what Fortran features from the Fortran 2003 and 2008 standards that the
>>>> given Fortran compiler supports.  That information is already
>>>
>>> To name the kid: this is about adding CMAKE_Fortran_KNOWN_FEATURES and
>>> friends, no?
>>
>> I wasn't aware of CMAKE_C_KNOWN_FEATURES and CMAKE_CXX_KNOWN_FEATURES,
>> but now that I have looked them up, I agree adding
>> CMAKE_Fortran_KNOWN_FEATURES is the right way to go rather than the
>> generic list I proposed above.
>>
>>> This exactly sounds like the whole compile_features things
>>> already done for C and C++, so yet another language shouldn't be too hard
>>> I
>>> guess.
>>
>> Especially since that Fortran information is already collected in
>> well-organized form in on one place, namely
>> <http://www.fortranplus.co.uk/app/download/23704631/fortran_2003_2008_compiler_support.pdf>.
> With my Fortran compiler vendor hat on - Please do be aware that this
> list of supported features may not be 100% accurate.
>
> #1 Vendors can add support that hasn't been reflected in that document
>
> #2 Not all claimed support is created equal. There's quite a few F2K3
> OO features that someone can claim to support, but when you start
> digging into real code they just flat out fail. (maybe less of the
> case now than it was before)
>
> #3 F2K8 aka CAF features could be supported, but may require
> additional runtime libraries or 3rd party software to actually work.
> For example our implementation ties to specific hardware and may not
> be 100% portable. Other implementations may depend on OpenMPI and not
> work with MPICH.
>
> I guess I'm saying that auto-detecting this stuff is cool, but do
> ensure that someone can easily override it. If as a vendor I say we
> support F2K8 and I'd like that enabled by default for supported
> versions of the compiler I really don't want to fight against some
> auto-test which might think otherwise.
>
>
> Thanks

I reckon working with the document is the most accurate option, though. 
It should be possible tooverride it somehow, since it can't be 
completely accurate nor updating outside of its 6-month cycle.
Coarrays need special treatment in CMake anyways. Right now, there's no 
way of determining which is the right way to enable Coarrays, if any.

Right now, in Intel Fortran, there's a number of related compiler 
switches, permitting anything from distributed to single image Coarrays, 
see https://software.intel.com/en-us/node/691534 .Each of these will 
also pull in different libraries that would need detection.

GFortran is even worse in this regard, since GCC 4.6, they've been able 
to support single images via -fcoarray=single, in GCC 4.7 they've got a 
barebones implementation using a communications library and since 5, 
that implementation is claimed to be "fully supported [...] except of 
bugs and incomplete support of special cases". Not to mention that GCC 
does not ship any useful communications library on their own, but rather 
relies on the external projects, see https://gcc.gnu.org/wiki/CoarrayLib 
, and can only support Coarrays in a useful fashion if an ABI compatible 
implementation like OpenCoarrays is installed on the system meaning 
feature completion also depends on some external library.

Either way, Coarrays should be the only feature in need of exceptional 
treatment, and for any other Fortran feature, it should be sufficient to 
work in a way comparable as to how C/C++ is being handled today.

- Chris

From irwin at beluga.phys.uvic.ca  Sat Apr 22 15:19:35 2017
From: irwin at beluga.phys.uvic.ca (Alan W. Irwin)
Date: Sat, 22 Apr 2017 12:19:35 -0700 (PDT)
Subject: [cmake-developers] [Feature Request] Fortran standards
 compliance for various compilers
In-Reply-To: <AM5P194MB0034EC9289DBCC657945CD6CAD1D0@AM5P194MB0034.EURP194.PROD.OUTLOOK.COM>
References: <alpine.DEB.2.11.1704181441360.23291@enira.zlyna.ubzr>
 <6849746.2ru3vbWqPR@daneel.sf-tec.de>
 <alpine.DEB.2.11.1704191054320.23291@enira.zlyna.ubzr>
 <CAOnawYrf1Hzrds+ecUUJa6Ls6o7L65Ubbj7xHjPkWyb0Lhya7w@mail.gmail.com>
 <AM5P194MB0034EC9289DBCC657945CD6CAD1D0@AM5P194MB0034.EURP194.PROD.OUTLOOK.COM>
Message-ID: <alpine.DEB.2.11.1704221145480.32335@enira.zlyna.ubzr>

On 2017-04-22 11:30-0000 Christian Pfeiffer wrote:

> On 4/22/2017 7:33 AM, C Bergstr?m wrote:
>
>> On Thu, Apr 20, 2017 at 4:12 AM, Alan W. Irwin
>> <irwin at beluga.phys.uvic.ca> wrote:
[...]
>>> Especially since that Fortran information is already collected in
>>> well-organized form in on one place, namely
>>> <http://www.fortranplus.co.uk/app/download/23704631/fortran_2003_2008_compiler_support.pdf>.
>> With my Fortran compiler vendor hat on - Please do be aware that this
>> list of supported features may not be 100% accurate.
>>
> On 4/22/2017 7:33 AM, C Bergstr?m wrote:
>> #1 Vendors can add support that hasn't been reflected in that document
>>
>> #2 Not all claimed support is created equal. There's quite a few F2K3
>> OO features that someone can claim to support, but when you start
>> digging into real code they just flat out fail. (maybe less of the
>> case now than it was before)
>>
>> #3 F2K8 aka CAF features could be supported, but may require
>> additional runtime libraries or 3rd party software to actually work.
>> For example our implementation ties to specific hardware and may not
>> be 100% portable. Other implementations may depend on OpenMPI and not
>> work with MPICH.
>>
>> I guess I'm saying that auto-detecting this stuff is cool, but do
>> ensure that someone can easily override it. If as a vendor I say we
>> support F2K8 and I'd like that enabled by default for supported
>> versions of the compiler I really don't want to fight against some
>> auto-test which might think otherwise.
>

Agreed.

> I reckon working with the document is the most accurate option, though.

Agreed! CMake is well ahead of the game here because of the existence
of this well-maintained document.  Furthmore, the document can be
parsed (see discussion of that at
<https://gitlab.kitware.com/cmake/cmake/issues/16819>) which is
another big advantage for the CMake developers.  My impression from
the forward of this document is this is a collection of information
that is supplied by the various vendors, but apparently they have been
reasonably honest about that assessment because there are lots of
non-"Y" results in the tables (for no claimed support for a given
sub-feature).  (See the overall totals for "Y" results that I
tabulated at <https://gitlab.kitware.com/cmake/cmake/issues/16819>
which for many vendors show far less than complete compliance with the
Fortran 2003 and Fortran 2008 standards.

So if a vendor does not claim support for a given sub-feature of the
Fortran 2003 and Fortran 2008 standards with a "Y", then I believe
them!  But as I think everyone will agree here, if they claim support
for a given sub-feature with a "Y", then that claim has to be taken
with a grain of salt by developers of CMake-based build systems for
Fortran projects and the users of such projects.

> It should be possible tooverride it somehow, since it can't be
> completely accurate nor updating outside of its 6-month cycle.

I assume this extremely useful Fortran information from CMake would
only be informational, and it would be up to developers of CMake-based
build-systems what they did with that useful (especially for the
non-"Y" case) information. And the documentation of the proposed
CMAKE_Fortran_KNOWN_FEATURES feature should make that useful
distinction between lack of claim for support (likely reliable), and
claim of support (substantially less reliable).

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

From irwin at beluga.phys.uvic.ca  Sun Apr 23 00:46:38 2017
From: irwin at beluga.phys.uvic.ca (Alan W. Irwin)
Date: Sat, 22 Apr 2017 21:46:38 -0700 (PDT)
Subject: [cmake-developers] [UseSWIG] regression in results from CMake-3.0.2
 to recent versions
Message-ID: <alpine.DEB.2.11.1704221944330.32335@enira.zlyna.ubzr>

This is just a preliminary statement of the problem in case someone
else has run into this, but obviously I have lots more work to do
(e.g., implement a grossly simplified test case to allow easy
verification of the problem both for me and others, and if I can
demonstrate the problem occurs for that simple test case, then use git
bisection to find when CMake introduced that regression).

To give some quick background for me (if some of you are not already aware),
I am an experienced CMake builder (with bootstrap method) on Debian
Jessie Gnu/Linux, and I use those resulting cmake executables to build a
number of different complex software projects including my primary
software interest, PLplot.

To give some background with regard to PLplot, that software project
has languages bindings for a number of different languages, and 4 of
those (Python, Java, Lua, and Octave) are generated by swig using the
facilities of CMake's UseSWIG module _without any CMake-related issues
whatsoever_. PLplot also has a really old hand-crafted binding called
plplot_widget that glues together our Python binding and our Tcl/Tk
binding.  This allows someone using the Python language to import
tkinter, plplot (a simple hand-crafted wrapper for plplotc which wraps
_plplotc.so where both the latter two are generated by swig), and the
plplot_widget extension module that glues everything together to
access our Tcl/Tk plot functionality directly from Python.
plplot_widget only works with Python2 and is essentially
unmaintainable (because it is someone else's work from a decade ago
who is no longer with the project).  So instead of getting into the
complications of porting that plplot_widget extension module to
Python3, I decided yesterday to let swig do that job (since
swig-generated bindings work in general both with Python2 and
Python3).  That implementation turned out to be trivial because the
effective C code that was being interfaced was a one-line routine with
a single long int argument. And the result (except for a set of build
warnings for both Python2 and Python3 for modern CMake) works fine for
both Python2 and Python3.

So with those preliminaries done, the issue I need to discuss is the
following build warnings (for the new swig-generated Python module
which consists of Pltk_init which wraps _Pltk_init) that I discovered
for CMake-3.8.0-rc4 (the latest version of that software I have
recently built) and also CMake-3.7.2:

bindings/python/CMakeFiles/_Pltk_init.dir/build.make:77: warning: overriding recipe for target 'bindings/python/plplotc.py'
bindings/python/CMakeFiles/_Pltk_init.dir/build.make:65: warning: ignoring old recipe for target 'bindings/python/plplotc.py'
bindings/python/CMakeFiles/_Pltk_init.dir/build.make:77: warning: overriding recipe for target 'bindings/python/plplotc.py'
bindings/python/CMakeFiles/_Pltk_init.dir/build.make:65: warning: ignoring old recipe for target 'bindings/python/plplotc.py'

These warnings occur when (successfully) building (or rebuilding)
_Pltk_init. A check of those files indicated they were caused by a
part (build rules for plplotc.py) of the _plplotc rules being copied
not once but twice (!) to the unrelated build rules for _Pltk_init.

This case of plplotc Makefile rules contaminating Pltk_init rules occurred for
the case where the Pltk_init CMake UseSWIG-related logic
(swig_add_module, swig_link_libraries, etc.) was placed after the
similar logic for the plplotc case in the relevant CMakeLists.txt
file.  If that order is reversed, the above warnings disappear, but
then you get similar warnings concerning Pltk_init rules contaminating
the plplotc rules!

No such warnings occur for the other (Java, Lua, Octave)
swig-generated bindings so it appears the problem is only triggered if
two library modules are generated with UseSWIG logic and swig in the
same directory.

These warnings completely disappear for CMake-3.0.2!  So there is a
good possibility this is due to an actual regression in CMake rather
than due to some bug in the PLplot build system that only manifests
for recent CMake versions.  In any case, the above
gross-simplification work should decide that issue.

So my next steps are gross simplification (to prove this
cross-contamination of build rules for UseSWIG-generated modules in
the same CMakeLists.txt file really is due to a regression in CMake
somewhere between CMake-3.0.2 and 3.7.2.  Note that both CMake-3.7.2
and CMake-3.8.0-rc4 show the warning problem.) And _if that is
proved_, then git bisect from CMake-3.0.2 to the latest git version to
make sure (a) the issue is not solved in the absolutely latest git
version of CMake and to (b) find exactly where the regression was
introduced.

Meanwhile, to help pin down the cause of the above warning messages
some more before I do the above work, has anybody else here had
trouble (or success) with use of the UseSWIG facilities in the same
directory for two different swig-generated Python modules? Same
question for two different swig-generated modules for the same
language?  Same question for two different swig-generated modules
for different languages?

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

From konstantin at podsvirov.pro  Sun Apr 23 01:30:44 2017
From: konstantin at podsvirov.pro (Konstantin Podsvirov)
Date: Sun, 23 Apr 2017 08:30:44 +0300
Subject: [cmake-developers] Where execute_process INPUT_CONTENT or
	INPUT_VARIABLE?
Message-ID: <6140521492925444@web25j.yandex.ru>

Where execute_process INPUT_CONTENT or INPUT_VARIABLE?

This would be very convenient for a small input.

Why should I always write a file for input?

--
Regards,
Konstantin Podsvirov

From irwin at beluga.phys.uvic.ca  Sun Apr 23 03:01:29 2017
From: irwin at beluga.phys.uvic.ca (Alan W. Irwin)
Date: Sun, 23 Apr 2017 00:01:29 -0700 (PDT)
Subject: [cmake-developers] Where execute_process INPUT_CONTENT or
 INPUT_VARIABLE?
In-Reply-To: <6140521492925444@web25j.yandex.ru>
References: <6140521492925444@web25j.yandex.ru>
Message-ID: <alpine.DEB.2.11.1704222333360.32335@enira.zlyna.ubzr>

On 2017-04-23 08:30+0300 Konstantin Podsvirov wrote:

> Where execute_process INPUT_CONTENT or INPUT_VARIABLE?
>
> This would be very convenient for a small input.
>
> Why should I always write a file for input?

Hi Konstantin:

I assume that last sentence refers to using the CMake FILE command
directly to write the required file at cmake time in the build tree
(as opposed to having to create an actual permanent file in the source
tree to be used directly or as a prototype for a configured file in
the build tree)?  If so, I use that approach quite a bit in various
build systems I have helped to develop to help drastically reduce the
number of small CMake-related files in the source tree.  And I far
prefer that approach to what you seem to be asking for above which is
some added syntax variation to EXECUTE_PROCESS to provide the same
ability that the FILE command currently has.

Note, I had to make some assumptions when answering you, and my
apologies in advance if I have misinterpreted anything you said
above.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

From konstantin at podsvirov.pro  Sun Apr 23 03:24:48 2017
From: konstantin at podsvirov.pro (Konstantin Podsvirov)
Date: Sun, 23 Apr 2017 10:24:48 +0300
Subject: [cmake-developers] Where execute_process INPUT_CONTENT or
	INPUT_VARIABLE?
In-Reply-To: <alpine.DEB.2.11.1704222333360.32335@enira.zlyna.ubzr>
References: <6140521492925444@web25j.yandex.ru>
 <alpine.DEB.2.11.1704222333360.32335@enira.zlyna.ubzr>
Message-ID: <6008521492932288@web34g.yandex.ru>

Hi Alan!

23.04.2017, 10:01, "Alan W. Irwin" <irwin at beluga.phys.uvic.ca>:
> On 2017-04-23 08:30+0300 Konstantin Podsvirov wrote:
>
>> ?Where execute_process INPUT_CONTENT or INPUT_VARIABLE?
>>
>> ?This would be very convenient for a small input.
>>
>> ?Why should I always write a file for input?
>
> Hi Konstantin:
>
> I assume that last sentence refers to using the CMake FILE command
> directly to write the required file at cmake time in the build tree
> (as opposed to having to create an actual permanent file in the source
> tree to be used directly or as a prototype for a configured file in
> the build tree)? If so, I use that approach quite a bit in various
> build systems I have helped to develop to help drastically reduce the
> number of small CMake-related files in the source tree. And I far
> prefer that approach to what you seem to be asking for above which is
> some added syntax variation to EXECUTE_PROCESS to provide the same
> ability that the FILE command currently has.
>
> Note, I had to make some assumptions when answering you, and my
> apologies in advance if I have misinterpreted anything you said
> above.

You have correctly understood and assumed. Thanks for your reply.

But imagine that we need to perform a simple process and process its standard output. But this process unfortunately awaits user input to complete.

>
> Alan
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________

My suggestion:

Add support for the INPUT_CONTENT or INPUT_VARIABLE arguments in execute_process command.

It seems to me that this will be a very useful improvement.

Will anyone take up the implementation of this improvement?

--
Regards,
Konstantin Podsvirov

From irwin at beluga.phys.uvic.ca  Sun Apr 23 05:25:58 2017
From: irwin at beluga.phys.uvic.ca (Alan W. Irwin)
Date: Sun, 23 Apr 2017 02:25:58 -0700 (PDT)
Subject: [cmake-developers] Where execute_process INPUT_CONTENT or
 INPUT_VARIABLE?
In-Reply-To: <6008521492932288@web34g.yandex.ru>
References: <6140521492925444@web25j.yandex.ru>
 <alpine.DEB.2.11.1704222333360.32335@enira.zlyna.ubzr>
 <6008521492932288@web34g.yandex.ru>
Message-ID: <alpine.DEB.2.11.1704230129230.32335@enira.zlyna.ubzr>

On 2017-04-23 10:24+0300 Konstantin Podsvirov wrote:

> Hi Alan!
>
> 23.04.2017, 10:01, "Alan W. Irwin" <irwin at beluga.phys.uvic.ca>:
>> On 2017-04-23 08:30+0300 Konstantin Podsvirov wrote:
>>
>>> ?Where execute_process INPUT_CONTENT or INPUT_VARIABLE?
>>>
>>> ?This would be very convenient for a small input.
>>>
>>> ?Why should I always write a file for input?
>>
>> Hi Konstantin:
>>
>> I assume that last sentence refers to using the CMake FILE command
>> directly to write the required file at cmake time in the build tree
>> (as opposed to having to create an actual permanent file in the source
>> tree to be used directly or as a prototype for a configured file in
>> the build tree)? If so, I use that approach quite a bit in various
>> build systems I have helped to develop to help drastically reduce the
>> number of small CMake-related files in the source tree. And I far
>> prefer that approach to what you seem to be asking for above which is
>> some added syntax variation to EXECUTE_PROCESS to provide the same
>> ability that the FILE command currently has.
>>
>> Note, I had to make some assumptions when answering you, and my
>> apologies in advance if I have misinterpreted anything you said
>> above.
>
> You have correctly understood and assumed. Thanks for your reply.
>

> But imagine that we need to perform a simple process and process its
standard output. But this process unfortunately awaits user input to
complete.

Interesting use case!

Of course, if it is really simple user input to the process involving
just a few values, then for that use case the user could enter those
values via environment variables or CMake variables while the designed
build system writes those via FILE to a temporary file in the right
order that is then read by the process that is being executed by
execute_process.  But that idea becomes clumsy as the number of values
increases. So I agree it would be useful to deal with the case where
user input of a substantial number of values via stdin (presumably
interactively prompted by the process to help guide that user input)
is the best and most flexible way to control the process.

One possibility to address that use case is whenever an appropriate
optional argument was specified to execute_process, i.e., that
execute_process command had the correct optional signature, then, for
example, you could connect cmake stdin with the stdin for the process
that is being executed by execute_process.

Of course, one concern with this solution for the use case might be
this makes the user build process difficult for a project's developers
to debug in case the whole thing is failing because the user typed in
the wrong stdin data for the process.  But I would argue against that
concern because this capability does give CMake-based build-system
designers more power and freedom which I fundamentally like as such a
build-system designer. And with each such additional increase in power
and freedom of CMake, build-system designers have a documentation
responsibility (i.e., in this case documenting exactly the stdin user
choices for the process they have forced users to run at cmake time
with execute_process), and the process design responsibility
(sanitizing user input, prompting user input, etc.).  Also
build-system users have the responsibility of reading that process
input documentation!  :-)

I must stop there because I have test project simplification and very
likely git bisect work to do on a completely different issue I have
raised here today.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

From konstantin at podsvirov.pro  Sun Apr 23 07:00:11 2017
From: konstantin at podsvirov.pro (Konstantin Podsvirov)
Date: Sun, 23 Apr 2017 14:00:11 +0300
Subject: [cmake-developers] Where execute_process INPUT_CONTENT or
	INPUT_VARIABLE?
In-Reply-To: <alpine.DEB.2.11.1704230129230.32335@enira.zlyna.ubzr>
References: <6140521492925444@web25j.yandex.ru>
 <alpine.DEB.2.11.1704222333360.32335@enira.zlyna.ubzr>
 <6008521492932288@web34g.yandex.ru>
 <alpine.DEB.2.11.1704230129230.32335@enira.zlyna.ubzr>
Message-ID: <6495651492945211@web19o.yandex.ru>



23.04.2017, 12:26, "Alan W. Irwin" <irwin at beluga.phys.uvic.ca>:
> On 2017-04-23 10:24+0300 Konstantin Podsvirov wrote:
>
>> ?Hi Alan!
>>
>> ?23.04.2017, 10:01, "Alan W. Irwin" <irwin at beluga.phys.uvic.ca>:
>>> ?On 2017-04-23 08:30+0300 Konstantin Podsvirov wrote:
>>>
>>>> ??Where execute_process INPUT_CONTENT or INPUT_VARIABLE?
>>>>
>>>> ??This would be very convenient for a small input.
>>>>
>>>> ??Why should I always write a file for input?
>>>
>>> ?Hi Konstantin:
>>>
>>> ?I assume that last sentence refers to using the CMake FILE command
>>> ?directly to write the required file at cmake time in the build tree
>>> ?(as opposed to having to create an actual permanent file in the source
>>> ?tree to be used directly or as a prototype for a configured file in
>>> ?the build tree)? If so, I use that approach quite a bit in various
>>> ?build systems I have helped to develop to help drastically reduce the
>>> ?number of small CMake-related files in the source tree. And I far
>>> ?prefer that approach to what you seem to be asking for above which is
>>> ?some added syntax variation to EXECUTE_PROCESS to provide the same
>>> ?ability that the FILE command currently has.
>>>
>>> ?Note, I had to make some assumptions when answering you, and my
>>> ?apologies in advance if I have misinterpreted anything you said
>>> ?above.
>>
>> ?You have correctly understood and assumed. Thanks for your reply.
>
>> ?But imagine that we need to perform a simple process and process its
>
> standard output. But this process unfortunately awaits user input to
> complete.
>
> Interesting use case!
>
> Of course, if it is really simple user input to the process involving
> just a few values, then for that use case the user could enter those
> values via environment variables or CMake variables while the designed
> build system writes those via FILE to a temporary file in the right
> order that is then read by the process that is being executed by
> execute_process. But that idea becomes clumsy as the number of values
> increases. So I agree it would be useful to deal with the case where
> user input of a substantial number of values via stdin (presumably
> interactively prompted by the process to help guide that user input)
> is the best and most flexible way to control the process.

No. Do not complicate things. You do not need to implement interactive communication with the user through CMake streams.
I just want to add the convenient INPUT_CONTENT and INPUT_VARIABLE options.
The input data is known in advance, even before the process is started.

> One possibility to address that use case is whenever an appropriate
> optional argument was specified to execute_process, i.e., that
> execute_process command had the correct optional signature, then, for
> example, you could connect cmake stdin with the stdin for the process
> that is being executed by execute_process.
>
> Of course, one concern with this solution for the use case might be
> this makes the user build process difficult for a project's developers
> to debug in case the whole thing is failing because the user typed in
> the wrong stdin data for the process. But I would argue against that
> concern because this capability does give CMake-based build-system
> designers more power and freedom which I fundamentally like as such a
> build-system designer. And with each such additional increase in power
> and freedom of CMake, build-system designers have a documentation
> responsibility (i.e., in this case documenting exactly the stdin user
> choices for the process they have forced users to run at cmake time
> with execute_process), and the process design responsibility
> (sanitizing user input, prompting user input, etc.). Also
> build-system users have the responsibility of reading that process
> input documentation! :-)
>
> I must stop there because I have test project simplification and very
> likely git bisect work to do on a completely different issue I have
> raised here today.
>
> Alan
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________

--
Regards,
Konstantin Podsvirov

From irwin at beluga.phys.uvic.ca  Sun Apr 23 07:09:54 2017
From: irwin at beluga.phys.uvic.ca (Alan W. Irwin)
Date: Sun, 23 Apr 2017 04:09:54 -0700 (PDT)
Subject: [cmake-developers] [UseSWIG] regression in results from
 CMake-3.0.2 to recent versions --SOLVED
In-Reply-To: <alpine.DEB.2.11.1704221944330.32335@enira.zlyna.ubzr>
References: <alpine.DEB.2.11.1704221944330.32335@enira.zlyna.ubzr>
Message-ID: <alpine.DEB.2.11.1704230327450.32335@enira.zlyna.ubzr>

On 2017-04-22 21:46-0700 Alan W. Irwin wrote:

> So my next steps are gross simplification (to prove this
> cross-contamination of build rules for UseSWIG-generated modules in
> the same CMakeLists.txt file really is due to a regression in CMake
> somewhere between CMake-3.0.2 and 3.7.2.  Note that both CMake-3.7.2
> and CMake-3.8.0-rc4 show the warning problem.)

Well, the short story is there was no such regression.  Note the
"--SOLVED" in the revised subject line.  Also, sorry for the noise!

The somewhat longer story is just at the start (fortunately for me) of
that simplification process, I double checked the source of both
FindSWIG.cmake and UseSWIG.cmake as used by PLplot, and those turned
out to be special cutting-edge versions recommended by one user of the
cmake bug tracking system from a decade (!) ago.  Oops!  Those
versions did continue to work for a very long time for our simple swig
needs, but those are obviously well past their "best buy" date, and
complete removal of those "special" versions from PLplot (so PLplot is
now using the official version of those modules that is distributed by
whatever CMake version a user chooses) works without the warning
messages for both CMake-3.0.2 AND CMake-3.8.0-rc4. In fact (as I
expected since I am an optimist) but unlike the extremely peculiar
result I had before, inspection of
bindings/python/CMakeFiles/_Pltk_init.dir/build.make showed no
contamination from plplotc rules at all.

So problem solved completely!  Thus, thanks to swig, and official
versions of FindSWIG.cmake and UseSWIG.cmake that vary with CMake
version but which are good enough for our needs despite that
variation, I now have my test of our Tcl/Tk "plframe" plotting GUI
working well for both Python 2 and Python 3 for a very large range of
CMake versions.

I hasten to add we will not support that large a range of CMake
versions too much longer although that supported range actually helped
to figure out the current problem. Indeed, I soon plan to bump our
minimum CMake version from 3.0.2 to 3.6.2 which will allow me to
greatly simplify our build system by stripping out a whole lot of
cruft that was necessary to work around issues that existed for quite
a few versions after CMake-3.0.2 was released.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

From eike at sf-mail.de  Sun Apr 23 11:10:22 2017
From: eike at sf-mail.de (Rolf Eike Beer)
Date: Sun, 23 Apr 2017 17:10:22 +0200
Subject: [cmake-developers] [UseSWIG] regression in results from
	CMake-3.0.2 to recent versions --SOLVED
In-Reply-To: <alpine.DEB.2.11.1704230327450.32335@enira.zlyna.ubzr>
References: <alpine.DEB.2.11.1704221944330.32335@enira.zlyna.ubzr>
 <alpine.DEB.2.11.1704230327450.32335@enira.zlyna.ubzr>
Message-ID: <1695718.iLsVrIcf0y@daneel.sf-tec.de>

> The somewhat longer story is just at the start (fortunately for me) of
> that simplification process, I double checked the source of both
> FindSWIG.cmake and UseSWIG.cmake as used by PLplot, and those turned
> out to be special cutting-edge versions recommended by one user of the
> cmake bug tracking system from a decade (!) ago.  Oops!  Those
> versions did continue to work for a very long time for our simple swig
> needs, but those are obviously well past their "best buy" date, and
> complete removal of those "special" versions from PLplot (so PLplot is
> now using the official version of those modules that is distributed by
> whatever CMake version a user chooses) works without the warning
> messages for both CMake-3.0.2 AND CMake-3.8.0-rc4.

So something in that range of versions has broken those old modules. It would 
be interesting to find out if that was breaking a never-really-supported case 
or something else.

Eike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170423/c1fc4b71/attachment.sig>

From irwin at beluga.phys.uvic.ca  Sun Apr 23 17:26:43 2017
From: irwin at beluga.phys.uvic.ca (Alan W. Irwin)
Date: Sun, 23 Apr 2017 14:26:43 -0700 (PDT)
Subject: [cmake-developers] On-going UseSWIG troubles with the official
	versions
Message-ID: <alpine.DEB.2.11.1704231309580.32335@enira.zlyna.ubzr>

On 2017-04-23 17:10+0200 Rolf Eike Beer wrote:

>> The somewhat longer story is just at the start (fortunately for me) of
>> that simplification process, I double checked the source of both
>> FindSWIG.cmake and UseSWIG.cmake as used by PLplot, and those turned
>> out to be special cutting-edge versions recommended by one user of the
>> cmake bug tracking system from a decade (!) ago.  Oops!  Those
>> versions did continue to work for a very long time for our simple swig
>> needs, but those are obviously well past their "best buy" date, and
>> complete removal of those "special" versions from PLplot (so PLplot is
>> now using the official version of those modules that is distributed by
>> whatever CMake version a user chooses) works without the warning
>> messages for both CMake-3.0.2 AND CMake-3.8.0-rc4.
>
> So something in that range of versions has broken those old modules. It would
> be interesting to find out if that was breaking a never-really-supported case
> or something else.

Hi Rolf:

It turns out I will be following up on that question because (sigh) my
further testing showed the versions of FindSWIG.cmake and
UseSWIG.cmake from CMake-3.0.2 has build failures for Java and Lua,
and the versions from CMake-3.6.2 and 3.8.0-rc4 have build failures
for Java even though none of these "official" versions exhibited the
rule contamination.  And, of course, our special versions of
FindSWIG.cmake and UseSWIG.cmake built our Python, Java, Lua, and
Octave bindings without any issues (except for the peculiar rule
contamination between Python and _Pltk_init).  So the current status
is the official versions partly fail, and the special versions partly
fail in a completely different way (ugh).

For the official versions, the consistently good results for Python
and Octave and the lack of rule contamination that is obtained argue
that my overall goal should be to figure out how to make PLplot use
the official versions without any errors for Lua and Java.  So more
later once I get this mess untangled using many different diff results
between the various versions of FindSWIG.cmake and UseSWIG.cmake and
comparing how our CMake code uses the UseSWIG facilities for Lua and
Java compared to the rest of our swig-generated bindings.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

From brad.king at kitware.com  Mon Apr 24 09:03:55 2017
From: brad.king at kitware.com (Brad King)
Date: Mon, 24 Apr 2017 09:03:55 -0400
Subject: [cmake-developers] Where execute_process INPUT_CONTENT or
 INPUT_VARIABLE?
In-Reply-To: <6140521492925444@web25j.yandex.ru>
References: <6140521492925444@web25j.yandex.ru>
Message-ID: <4390118f-62ed-e81b-2545-8662df165847@kitware.com>

On 04/23/2017 01:30 AM, Konstantin Podsvirov wrote:
> Where execute_process INPUT_CONTENT or INPUT_VARIABLE?
> 
> This would be very convenient for a small input.
> 
> Why should I always write a file for input?

I agree that the options should be there but they can't be easily
implemented without choosing our own temporary file which will have
its own problems.

The reason is that our internal process execution implementation
does not support communication from the parent on stdin.  Fixing
that is not something I'm prepared to do or even accept as a
contribution because I'd rather migrate to libuv than extend our
own process management implementation further.  That is a more
long-term process so in the meantime I think it is best to just
ask projects to use INPUT_FILE.

-Brad


From brad.king at kitware.com  Mon Apr 24 09:06:53 2017
From: brad.king at kitware.com (Brad King)
Date: Mon, 24 Apr 2017 09:06:53 -0400
Subject: [cmake-developers] Adding Microsoft MPI Fortran support in
 FindMPI
In-Reply-To: <AM5P194MB00346534AC9779901BA43256AD1A0@AM5P194MB0034.EURP194.PROD.OUTLOOK.COM>
References: <AM5P194MB00346534AC9779901BA43256AD1A0@AM5P194MB0034.EURP194.PROD.OUTLOOK.COM>
Message-ID: <a285b6aa-50b2-f34e-4670-7d5a28ea6fa9@kitware.com>

On 04/21/2017 05:45 PM, Christian P. wrote:
> Is this a good/bad idea or is there any way to do this in a proper fashion?
> The idea of adding an actual target to a Find module seems wrong to me,
> but I?m not seeing any way of doing it otherwise.

I think we'll have to expose this requirement to project code.  Provide
a function the project can call to make the needed target available.  That
way the project can control if/when it is done and what the target is
called.

-Brad


From konstantin at podsvirov.pro  Mon Apr 24 09:22:39 2017
From: konstantin at podsvirov.pro (Konstantin Podsvirov)
Date: Mon, 24 Apr 2017 16:22:39 +0300
Subject: [cmake-developers] Where execute_process INPUT_CONTENT or
	INPUT_VARIABLE?
In-Reply-To: <4390118f-62ed-e81b-2545-8662df165847@kitware.com>
References: <6140521492925444@web25j.yandex.ru>
 <4390118f-62ed-e81b-2545-8662df165847@kitware.com>
Message-ID: <2995251493040159@web13j.yandex.ru>

An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170424/3541512b/attachment.html>

From daniel at pfeifer-mail.de  Mon Apr 24 10:09:14 2017
From: daniel at pfeifer-mail.de (Daniel Pfeifer)
Date: Mon, 24 Apr 2017 16:09:14 +0200
Subject: [cmake-developers] Where execute_process INPUT_CONTENT or
	INPUT_VARIABLE?
In-Reply-To: <4390118f-62ed-e81b-2545-8662df165847@kitware.com>
References: <6140521492925444@web25j.yandex.ru>
 <4390118f-62ed-e81b-2545-8662df165847@kitware.com>
Message-ID: <CANZMcXofBL1GYEifu=3JdVcgrvPn-2TqTxY8D3Yfst0dsHRdgA@mail.gmail.com>

On Mon, Apr 24, 2017 at 3:03 PM, Brad King <brad.king at kitware.com> wrote:

> On 04/23/2017 01:30 AM, Konstantin Podsvirov wrote:
> > Where execute_process INPUT_CONTENT or INPUT_VARIABLE?
> >
> > This would be very convenient for a small input.
> >
> > Why should I always write a file for input?
>
> I agree that the options should be there but they can't be easily
> implemented without choosing our own temporary file which will have
> its own problems.
>
> The reason is that our internal process execution implementation
> does not support communication from the parent on stdin.  Fixing
> that is not something I'm prepared to do or even accept as a
> contribution because I'd rather migrate to libuv than extend our
> own process management implementation further.


Brad, can you share what the current status is on this? If I remember
correctly, then libuv cannot be built yet on all necessary compilers. Is
that still the case? This sounds like the biggest impediment. Once we can
rely on libuv, we can also use it for filesystem operations. This would
help solve issues like #13162.

Cheers, Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170424/eb776233/attachment.html>

From brad.king at kitware.com  Mon Apr 24 10:22:42 2017
From: brad.king at kitware.com (Brad King)
Date: Mon, 24 Apr 2017 10:22:42 -0400
Subject: [cmake-developers] status of libuv in CMake
In-Reply-To: <CANZMcXofBL1GYEifu=3JdVcgrvPn-2TqTxY8D3Yfst0dsHRdgA@mail.gmail.com>
References: <6140521492925444@web25j.yandex.ru>
 <4390118f-62ed-e81b-2545-8662df165847@kitware.com>
 <CANZMcXofBL1GYEifu=3JdVcgrvPn-2TqTxY8D3Yfst0dsHRdgA@mail.gmail.com>
Message-ID: <a666635c-ce66-f0ad-7197-c2964d47826b@kitware.com>

On 04/24/2017 10:09 AM, Daniel Pfeifer wrote:
> Brad, can you share what the current status is on this? If I
> remember correctly, then libuv cannot be built yet on all
> necessary compilers. Is that still the case? This sounds like
> the biggest impediment.

Yes, though I've been making some progress upstream [1] [2].
Once that is accepted then we'll have a portable pure-posix
poll abstraction in libuv that we can fall back on to make
the basic functionality work everywhere.

-Brad


[1] https://github.com/libuv/libuv/issues/1287
[2] https://github.com/libuv/libuv/pull/1312


From rcdailey.lists at gmail.com  Mon Apr 24 10:54:18 2017
From: rcdailey.lists at gmail.com (Robert Dailey)
Date: Mon, 24 Apr 2017 09:54:18 -0500
Subject: [cmake-developers] Trouble with FindPNG module
In-Reply-To: <CAHd499Ajdp-SN00UsnZ_dv4=9KEnzHXBfWHW=jK4O5P6oY7BsA@mail.gmail.com>
References: <CAHd499Ajdp-SN00UsnZ_dv4=9KEnzHXBfWHW=jK4O5P6oY7BsA@mail.gmail.com>
Message-ID: <CAHd499DgfkUEYGgfUdNSf5BrPGT5JAsjbhQ2-J+z_DzDukLLmQ@mail.gmail.com>

Sorry to bump; any info on this? I'm completely blocked :-(

On Fri, Apr 21, 2017 at 4:48 PM, Robert Dailey <rcdailey.lists at gmail.com> wrote:
> I'm running CMake 3.8.0 on Ubuntu 14. I invoke the following:
>
> find_package(PNG REQUIRED)
>
> Which gives me the output in CMake:
>
> Could NOT find PNG (missing: PNG_LIBRARY) (found version "1.2.50")
>
> The CMakeCache.txt file has these variables set:
>
> PNG_LIBRARY_DEBUG:FILEPATH=PNG_LIBRARY_DEBUG-NOTFOUND
> PNG_LIBRARY_RELEASE:FILEPATH=PNG_LIBRARY_RELEASE-NOTFOUND
> PNG_PNG_INCLUDE_DIR:PATH=/usr/include
>
> So it found the headers, but not the libs. Why did it not find the
> libs? Note that my version of Ubuntu is 64-bit, and I've installed the
> 32-bit libs like so:
>
> $ sudo apt-get install libpng12-dev:i386
>
> Would the find module be confused because it is trying to find the
> 64-bit library? What's the issue?

From ben.boeckel at kitware.com  Mon Apr 24 11:02:27 2017
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Mon, 24 Apr 2017 11:02:27 -0400
Subject: [cmake-developers] Trouble with FindPNG module
In-Reply-To: <CAHd499DgfkUEYGgfUdNSf5BrPGT5JAsjbhQ2-J+z_DzDukLLmQ@mail.gmail.com>
References: <CAHd499Ajdp-SN00UsnZ_dv4=9KEnzHXBfWHW=jK4O5P6oY7BsA@mail.gmail.com>
 <CAHd499DgfkUEYGgfUdNSf5BrPGT5JAsjbhQ2-J+z_DzDukLLmQ@mail.gmail.com>
Message-ID: <20170424150227.GA18124@megas.kitware.com>

On Mon, Apr 24, 2017 at 09:54:18 -0500, Robert Dailey wrote:
> On Fri, Apr 21, 2017 at 4:48 PM, Robert Dailey <rcdailey.lists at gmail.com> wrote:
> > I'm running CMake 3.8.0 on Ubuntu 14. I invoke the following:
> >
> > find_package(PNG REQUIRED)
> >
> > Which gives me the output in CMake:
> >
> > Could NOT find PNG (missing: PNG_LIBRARY) (found version "1.2.50")
> >
> > The CMakeCache.txt file has these variables set:
> >
> > PNG_LIBRARY_DEBUG:FILEPATH=PNG_LIBRARY_DEBUG-NOTFOUND
> > PNG_LIBRARY_RELEASE:FILEPATH=PNG_LIBRARY_RELEASE-NOTFOUND
> > PNG_PNG_INCLUDE_DIR:PATH=/usr/include
> >
> > So it found the headers, but not the libs. Why did it not find the
> > libs? Note that my version of Ubuntu is 64-bit, and I've installed the
> > 32-bit libs like so:
> >
> > $ sudo apt-get install libpng12-dev:i386

What compiler are you using (what does CMake say it is?)? Does an
`strace` of CMake configuring the project show anything interesting?
`cmake --trace-expand`?

--Ben

From rcdailey.lists at gmail.com  Mon Apr 24 13:20:27 2017
From: rcdailey.lists at gmail.com (Robert Dailey)
Date: Mon, 24 Apr 2017 12:20:27 -0500
Subject: [cmake-developers] Trouble with FindPNG module
In-Reply-To: <20170424150227.GA18124@megas.kitware.com>
References: <CAHd499Ajdp-SN00UsnZ_dv4=9KEnzHXBfWHW=jK4O5P6oY7BsA@mail.gmail.com>
 <CAHd499DgfkUEYGgfUdNSf5BrPGT5JAsjbhQ2-J+z_DzDukLLmQ@mail.gmail.com>
 <20170424150227.GA18124@megas.kitware.com>
Message-ID: <CAHd499C_JO+RpMYebvmrHmyDoJC2RZAgK-O0mJ51O5ds8StGKA@mail.gmail.com>

On Mon, Apr 24, 2017 at 10:02 AM, Ben Boeckel <ben.boeckel at kitware.com> wrote:
> On Mon, Apr 24, 2017 at 09:54:18 -0500, Robert Dailey wrote:
>> On Fri, Apr 21, 2017 at 4:48 PM, Robert Dailey <rcdailey.lists at gmail.com> wrote:
>> > I'm running CMake 3.8.0 on Ubuntu 14. I invoke the following:
>> >
>> > find_package(PNG REQUIRED)
>> >
>> > Which gives me the output in CMake:
>> >
>> > Could NOT find PNG (missing: PNG_LIBRARY) (found version "1.2.50")
>> >
>> > The CMakeCache.txt file has these variables set:
>> >
>> > PNG_LIBRARY_DEBUG:FILEPATH=PNG_LIBRARY_DEBUG-NOTFOUND
>> > PNG_LIBRARY_RELEASE:FILEPATH=PNG_LIBRARY_RELEASE-NOTFOUND
>> > PNG_PNG_INCLUDE_DIR:PATH=/usr/include
>> >
>> > So it found the headers, but not the libs. Why did it not find the
>> > libs? Note that my version of Ubuntu is 64-bit, and I've installed the
>> > 32-bit libs like so:
>> >
>> > $ sudo apt-get install libpng12-dev:i386
>
> What compiler are you using (what does CMake say it is?)? Does an
> `strace` of CMake configuring the project show anything interesting?
> `cmake --trace-expand`?

It's using Gcc 4.9 because I told it to via toolchain file:



-- The C compiler identification is GNU 4.9.4
-- The CXX compiler identification is GNU 4.9.4
-- Check for working C compiler: /usr/bin/gcc-4.9
-- Check for working C compiler: /usr/bin/gcc-4.9 -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/g++-4.9
-- Check for working CXX compiler: /usr/bin/g++-4.9 -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done



Via the following toolchain file contents:



set( CMAKE_SYSTEM_NAME Linux )
set( CMAKE_SYSTEM_VERSION 1 )
set( CMAKE_SYSTEM_PROCESSOR "i686" )
set( CMAKE_C_COMPILER gcc-4.9 )
set( CMAKE_CXX_COMPILER g++-4.9 )
set( CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -m32" )
set( CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -m32" )



I'm not sure how to use strace. I tried following instructions I found
on the [CMake Performance Tips][1] page, but this isn't working. My
generate command has a lot of options, so I use a helper shell script
to generate. strace seems to not work well when using a shell script.
Trace also doesn't show much useful. Could you give exact command line
I can run to get the info you need?

Where possible, I install everything via apt-get for the 4.9
toolchain. For libpng this was not an option as far as I could tell,
so I'm not sure what implications that has on find_package() behavior.

From ben.boeckel at kitware.com  Mon Apr 24 13:42:17 2017
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Mon, 24 Apr 2017 13:42:17 -0400
Subject: [cmake-developers] Trouble with FindPNG module
In-Reply-To: <CAHd499C_JO+RpMYebvmrHmyDoJC2RZAgK-O0mJ51O5ds8StGKA@mail.gmail.com>
References: <CAHd499Ajdp-SN00UsnZ_dv4=9KEnzHXBfWHW=jK4O5P6oY7BsA@mail.gmail.com>
 <CAHd499DgfkUEYGgfUdNSf5BrPGT5JAsjbhQ2-J+z_DzDukLLmQ@mail.gmail.com>
 <20170424150227.GA18124@megas.kitware.com>
 <CAHd499C_JO+RpMYebvmrHmyDoJC2RZAgK-O0mJ51O5ds8StGKA@mail.gmail.com>
Message-ID: <20170424174217.GA8585@megas.kitware.com>

On Mon, Apr 24, 2017 at 12:20:27 -0500, Robert Dailey wrote:
> -- The C compiler identification is GNU 4.9.4
> -- The CXX compiler identification is GNU 4.9.4
> -- Check for working C compiler: /usr/bin/gcc-4.9
> -- Check for working C compiler: /usr/bin/gcc-4.9 -- works
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Detecting C compile features
> -- Detecting C compile features - done
> -- Check for working CXX compiler: /usr/bin/g++-4.9
> -- Check for working CXX compiler: /usr/bin/g++-4.9 -- works
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- Detecting CXX compile features
> -- Detecting CXX compile features - done

Does the information in the CMakeFiles/$cmake_version directory contain
anything indicating that it's detecting the compiler as 64-bit?

> I'm not sure how to use strace. I tried following instructions I found
> on the [CMake Performance Tips][1] page, but this isn't working. My
> generate command has a lot of options, so I use a helper shell script
> to generate. strace seems to not work well when using a shell script.
> Trace also doesn't show much useful. Could you give exact command line
> I can run to get the info you need?

Sorry, it's such a common tool I use, I forget others are new to it :) .
Here's how I'd use it to debug this:

    strace -s 10000 -e file -o cmake.strace.log $cmake_command

If your cmake command is a script that later launches CMake, you can
give strace `-f` to have it also trace any child processes made by the
command. In the resulting log file, you'll see syscalls CMake is making.
searching for the png header/library searching area shouldn't be too
hard. Is it looking in anything resembling the right paths?

--Ben

From rleigh at codelibre.net  Mon Apr 24 14:17:39 2017
From: rleigh at codelibre.net (Roger Leigh)
Date: Mon, 24 Apr 2017 19:17:39 +0100
Subject: [cmake-developers] Trouble with FindPNG module
In-Reply-To: <CAHd499DgfkUEYGgfUdNSf5BrPGT5JAsjbhQ2-J+z_DzDukLLmQ@mail.gmail.com>
References: <CAHd499Ajdp-SN00UsnZ_dv4=9KEnzHXBfWHW=jK4O5P6oY7BsA@mail.gmail.com>
 <CAHd499DgfkUEYGgfUdNSf5BrPGT5JAsjbhQ2-J+z_DzDukLLmQ@mail.gmail.com>
Message-ID: <6972fa83-116c-a8e9-736d-24fa31e5f3da@codelibre.net>

On 24/04/2017 15:54, Robert Dailey wrote:
> Sorry to bump; any info on this? I'm completely blocked :-(
>
> On Fri, Apr 21, 2017 at 4:48 PM, Robert Dailey <rcdailey.lists at gmail.com> wrote:
>> I'm running CMake 3.8.0 on Ubuntu 14. I invoke the following:
>>
>> find_package(PNG REQUIRED)
>>
>> Which gives me the output in CMake:
>>
>> Could NOT find PNG (missing: PNG_LIBRARY) (found version "1.2.50")
>>
>> The CMakeCache.txt file has these variables set:
>>
>> PNG_LIBRARY_DEBUG:FILEPATH=PNG_LIBRARY_DEBUG-NOTFOUND
>> PNG_LIBRARY_RELEASE:FILEPATH=PNG_LIBRARY_RELEASE-NOTFOUND
>> PNG_PNG_INCLUDE_DIR:PATH=/usr/include
>>
>> So it found the headers, but not the libs. Why did it not find the
>> libs? Note that my version of Ubuntu is 64-bit, and I've installed the
>> 32-bit libs like so:
>>
>> $ sudo apt-get install libpng12-dev:i386
>>
>> Would the find module be confused because it is trying to find the
>> 64-bit library? What's the issue?

Sounds like that's exactly the problem.  You can only have one libpng 
*development* package installed at once.  You probably want the regular 
"libpng-dev" package installed if you want to build against the standard 
libpng.

What's your goal here?  Why did you install a single i386 development 
package?

If you want to build i386 binaries, it's usually simpler to build in a 
virtual machine, i.e. a chroot, container, full VM or whatever you like, 
where you have a fully 32-bit environment.  The multiarch library 
support is primarily intended for *deploying and running* 32-bit code 
rather than development.  While you can use it for development, it gets 
painful due to the conflicts with the headers and other bits in the 
native development packages.


Regards,
Roger


From ben.boeckel at kitware.com  Mon Apr 24 14:30:06 2017
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Mon, 24 Apr 2017 14:30:06 -0400
Subject: [cmake-developers] Trouble with FindPNG module
In-Reply-To: <6972fa83-116c-a8e9-736d-24fa31e5f3da@codelibre.net>
References: <CAHd499Ajdp-SN00UsnZ_dv4=9KEnzHXBfWHW=jK4O5P6oY7BsA@mail.gmail.com>
 <CAHd499DgfkUEYGgfUdNSf5BrPGT5JAsjbhQ2-J+z_DzDukLLmQ@mail.gmail.com>
 <6972fa83-116c-a8e9-736d-24fa31e5f3da@codelibre.net>
Message-ID: <20170424183006.GA12595@megas.kitware.com>

On Mon, Apr 24, 2017 at 19:17:39 +0100, Roger Leigh wrote:
> Sounds like that's exactly the problem.  You can only have one libpng 
> *development* package installed at once.  You probably want the regular 
> "libpng-dev" package installed if you want to build against the standard 
> libpng.

Ah, this is before the multiarch split from Debian came into Ubuntu? I'm
so used to Red Hat's lib64 split (multilib) (which, admittedly, has its
drawbacks in light of multiarch).

--Ben

From rleigh at codelibre.net  Mon Apr 24 14:58:52 2017
From: rleigh at codelibre.net (Roger Leigh)
Date: Mon, 24 Apr 2017 19:58:52 +0100
Subject: [cmake-developers] Trouble with FindPNG module
In-Reply-To: <20170424183006.GA12595@megas.kitware.com>
References: <CAHd499Ajdp-SN00UsnZ_dv4=9KEnzHXBfWHW=jK4O5P6oY7BsA@mail.gmail.com>
 <CAHd499DgfkUEYGgfUdNSf5BrPGT5JAsjbhQ2-J+z_DzDukLLmQ@mail.gmail.com>
 <6972fa83-116c-a8e9-736d-24fa31e5f3da@codelibre.net>
 <20170424183006.GA12595@megas.kitware.com>
Message-ID: <ae1b8c57-08bf-2a3b-5458-5cdb8d8f5b07@codelibre.net>

On 24/04/2017 19:30, Ben Boeckel wrote:
> On Mon, Apr 24, 2017 at 19:17:39 +0100, Roger Leigh wrote:
>> Sounds like that's exactly the problem.  You can only have one libpng
>> *development* package installed at once.  You probably want the regular
>> "libpng-dev" package installed if you want to build against the standard
>> libpng.
>
> Ah, this is before the multiarch split from Debian came into Ubuntu? I'm
> so used to Red Hat's lib64 split (multilib) (which, admittedly, has its
> drawbacks in light of multiarch).

Yes, this is exactly the case.  There are actually four development 
packages which could be installed:

libpng-dev:amd64
libpng-dev:i386
libpng12-dev:amd64
libpng12-dev:i386

And that's not counting the other architectures which could /also/ be 
installed as well, e.g. libpng-dev:powerpc, libpng12-dev:armel etc.

While you can install as many of the runtime packages as you like, the 
headers go into /usr/include and so they conflict with each other, 
limiting you to a single development package at one time (checked the 
behaviour to verify this, and installing one triggers removal of any 
existing variant).  Not itself a multiarch limitation--many packages now 
use /usr/include/<arch> for this reason--but certainly a limitation in 
the packaging of the current libpng, which for some reason hasn't yet 
started using arch-specific headers.

This is almost certainly why FindPNG fails.  The headers are found, but 
the library is missing since it's in the arch-specific lib path for the 
other architecture, and the compiler isn't using that path by default.


Regards,
Roger

From ben.boeckel at kitware.com  Mon Apr 24 15:29:19 2017
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Mon, 24 Apr 2017 15:29:19 -0400
Subject: [cmake-developers] Trouble with FindPNG module
In-Reply-To: <ae1b8c57-08bf-2a3b-5458-5cdb8d8f5b07@codelibre.net>
References: <CAHd499Ajdp-SN00UsnZ_dv4=9KEnzHXBfWHW=jK4O5P6oY7BsA@mail.gmail.com>
 <CAHd499DgfkUEYGgfUdNSf5BrPGT5JAsjbhQ2-J+z_DzDukLLmQ@mail.gmail.com>
 <6972fa83-116c-a8e9-736d-24fa31e5f3da@codelibre.net>
 <20170424183006.GA12595@megas.kitware.com>
 <ae1b8c57-08bf-2a3b-5458-5cdb8d8f5b07@codelibre.net>
Message-ID: <20170424192919.GA15274@megas.kitware.com>

On Mon, Apr 24, 2017 at 19:58:52 +0100, Roger Leigh wrote:
> While you can install as many of the runtime packages as you like, the 
> headers go into /usr/include and so they conflict with each other, 
> limiting you to a single development package at one time (checked the 
> behaviour to verify this, and installing one triggers removal of any 
> existing variant).  Not itself a multiarch limitation--many packages now 
> use /usr/include/<arch> for this reason--but certainly a limitation in 
> the packaging of the current libpng, which for some reason hasn't yet 
> started using arch-specific headers.

Hmm, odd. Coming from RPM, it copes with multiple -devel packages all
writing directly to `/usr/include` as long as the headers themselves are
the same on all architectures (and, IIRC, binaries are decided based on the
"preferred" architecture of the host in case of conflicts). Oddities in
packaging formats I suppose :) .

--Ben

From irwin at beluga.phys.uvic.ca  Tue Apr 25 04:08:16 2017
From: irwin at beluga.phys.uvic.ca (Alan W. Irwin)
Date: Tue, 25 Apr 2017 01:08:16 -0700 (PDT)
Subject: [cmake-developers] On-going UseSWIG troubles with the official
 versions --SOLVED
In-Reply-To: <alpine.DEB.2.11.1704231309580.32335@enira.zlyna.ubzr>
References: <alpine.DEB.2.11.1704231309580.32335@enira.zlyna.ubzr>
Message-ID: <alpine.DEB.2.11.1704241143590.32335@enira.zlyna.ubzr>

On 2017-04-23 14:26-0700 Alan W. Irwin wrote:

> [... My]
> further testing showed the versions of FindSWIG.cmake and
> UseSWIG.cmake from CMake-3.0.2 has build failures for Java and Lua,
> and the versions from CMake-3.6.2 and 3.8.0-rc4 have build failures
> for Java even though none of these "official" versions exhibited the
> rule contamination.

I have bumped the minimum CMake version from 3.0.2 to 3.6.2 for PLplot
so I am not going to worry about the Lua issue for 3.0.2.  And it
turned out the Java issue was simply a change in naming convention for
the resulting module between my special UseSWIG.cmake and the official
ones that I needed to adjust for.  So that concludes this topic from the
PLplot perspective.

However, while researching this, I did notice one issue with the CMake
git master version of Modules/UseSWIG.cmake that the CMake maintainers
of that file might want to address which is the if...elseif...elseif
clauses establishing the PREFIX and SUFFIX properties for each
specific language language covered currently has no else clause to
set PREFIX to "" for all languages not specifically covered by the if
and elseif blocks. I suggest you do implement such an else cause to be
consistent with older versions of UseSWIG.cmake (such as my special
version) which simply set PREFIX to "" for all languages, and also
consistent with the specificially covered languages where PREFIX is
set to "" as well (except for the Java case).

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

From brad.king at kitware.com  Tue Apr 25 08:54:34 2017
From: brad.king at kitware.com (Brad King)
Date: Tue, 25 Apr 2017 08:54:34 -0400
Subject: [cmake-developers] On-going UseSWIG troubles with the official
 versions --SOLVED
In-Reply-To: <alpine.DEB.2.11.1704241143590.32335@enira.zlyna.ubzr>
References: <alpine.DEB.2.11.1704231309580.32335@enira.zlyna.ubzr>
 <alpine.DEB.2.11.1704241143590.32335@enira.zlyna.ubzr>
Message-ID: <6c765a3c-be3d-cce4-2354-52b84bc48212@kitware.com>

On 04/25/2017 04:08 AM, Alan W. Irwin wrote:
> set PREFIX to "" for all languages not specifically covered by the if
> and elseif blocks.

Do you mean

```
diff --git a/Modules/UseSWIG.cmake b/Modules/UseSWIG.cmake
index 277f4ca28a..bfe1a6f754 100644
--- a/Modules/UseSWIG.cmake
+++ b/Modules/UseSWIG.cmake
@@ -326,6 +326,9 @@ macro(SWIG_ADD_LIBRARY name)
     if (APPLE)
       set_target_properties (${SWIG_MODULE_${name}_REAL_NAME} PROPERTIES SUFFIX ".bundle")
     endif ()
+  else()
+    # assume empty prefix because we expect the module to be dynamically loaded
+    set_target_properties (${SWIG_MODULE_${name}_REAL_NAME} PROPERTIES PREFIX "")
   endif ()
 endmacro()
```

?

-Brad


From rcdailey.lists at gmail.com  Tue Apr 25 10:25:34 2017
From: rcdailey.lists at gmail.com (Robert Dailey)
Date: Tue, 25 Apr 2017 09:25:34 -0500
Subject: [cmake-developers] Trouble with FindPNG module
In-Reply-To: <6972fa83-116c-a8e9-736d-24fa31e5f3da@codelibre.net>
References: <CAHd499Ajdp-SN00UsnZ_dv4=9KEnzHXBfWHW=jK4O5P6oY7BsA@mail.gmail.com>
 <CAHd499DgfkUEYGgfUdNSf5BrPGT5JAsjbhQ2-J+z_DzDukLLmQ@mail.gmail.com>
 <6972fa83-116c-a8e9-736d-24fa31e5f3da@codelibre.net>
Message-ID: <CAHd499Bt-URb0rRnKotdo0LJxqdukxnocW99K2qsR+C8dh7xsg@mail.gmail.com>

To give you some context, this is an Ubuntu 14 installation for
hosting our Atlassian Bamboo build server. We use it to build a 32-bit
application. The OS itself is 64-bit, but our app does not compile 64
bit (code is too crappy). So I had to make sure to be careful that I'm
using the correct toolchain (gcc 4.9) and 32-bit libs. CMake uses
find_package() for most libraries, and those libs must be the 32-bit
versions.

What instructions would you suggest for setting up the VM like you
mentioned? It needs to be something I can "initialize" from within
Bamboo. Basically as part of the build process, before doing anything,
I need to be able to tell bamboo to use a specific environment (in
this case specific VM). I'm not incredibly familiar with Linux, so
hopefully there is a recommended path here.

Thanks.

On Mon, Apr 24, 2017 at 1:17 PM, Roger Leigh <rleigh at codelibre.net> wrote:
> On 24/04/2017 15:54, Robert Dailey wrote:
>>
>> Sorry to bump; any info on this? I'm completely blocked :-(
>>
>> On Fri, Apr 21, 2017 at 4:48 PM, Robert Dailey <rcdailey.lists at gmail.com>
>> wrote:
>>>
>>> I'm running CMake 3.8.0 on Ubuntu 14. I invoke the following:
>>>
>>> find_package(PNG REQUIRED)
>>>
>>> Which gives me the output in CMake:
>>>
>>> Could NOT find PNG (missing: PNG_LIBRARY) (found version "1.2.50")
>>>
>>> The CMakeCache.txt file has these variables set:
>>>
>>> PNG_LIBRARY_DEBUG:FILEPATH=PNG_LIBRARY_DEBUG-NOTFOUND
>>> PNG_LIBRARY_RELEASE:FILEPATH=PNG_LIBRARY_RELEASE-NOTFOUND
>>> PNG_PNG_INCLUDE_DIR:PATH=/usr/include
>>>
>>> So it found the headers, but not the libs. Why did it not find the
>>> libs? Note that my version of Ubuntu is 64-bit, and I've installed the
>>> 32-bit libs like so:
>>>
>>> $ sudo apt-get install libpng12-dev:i386
>>>
>>> Would the find module be confused because it is trying to find the
>>> 64-bit library? What's the issue?
>
>
> Sounds like that's exactly the problem.  You can only have one libpng
> *development* package installed at once.  You probably want the regular
> "libpng-dev" package installed if you want to build against the standard
> libpng.
>
> What's your goal here?  Why did you install a single i386 development
> package?
>
> If you want to build i386 binaries, it's usually simpler to build in a
> virtual machine, i.e. a chroot, container, full VM or whatever you like,
> where you have a fully 32-bit environment.  The multiarch library support is
> primarily intended for *deploying and running* 32-bit code rather than
> development.  While you can use it for development, it gets painful due to
> the conflicts with the headers and other bits in the native development
> packages.
>
>
> Regards,
> Roger
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers

From gjasny at googlemail.com  Tue Apr 25 10:32:54 2017
From: gjasny at googlemail.com (Gregor Jasny)
Date: Tue, 25 Apr 2017 16:32:54 +0200
Subject: [cmake-developers] Nighly build of CMake release branch available?
Message-ID: <3389dc52-5ad6-b206-14b1-a0f3f61b9daa@googlemail.com>

Hello,

I wonder if a nightly (or on-demand) build of the CMake release branch 
is available somewhere as it is for the master branch. That would help 
me testing those snapshots within our companies projects.

Thanks,
Gregor

From brad.king at kitware.com  Tue Apr 25 10:39:08 2017
From: brad.king at kitware.com (Brad King)
Date: Tue, 25 Apr 2017 10:39:08 -0400
Subject: [cmake-developers] Nighly build of CMake release branch
 available?
In-Reply-To: <3389dc52-5ad6-b206-14b1-a0f3f61b9daa@googlemail.com>
References: <3389dc52-5ad6-b206-14b1-a0f3f61b9daa@googlemail.com>
Message-ID: <5714b64a-56a8-faa6-978b-35afd2855ab1@kitware.com>

On 04/25/2017 10:32 AM, Gregor Jasny via cmake-developers wrote:
> I wonder if a nightly (or on-demand) build of the CMake release branch 
> is available somewhere as it is for the master branch. That would help 
> me testing those snapshots within our companies projects.

No, we don't currently have one for `release`.  Unfortunately I don't
think the build machines have room for more than one binary each night
since they are also used for other things.  Also we'd have to be careful
providing such binaries because their version number would look like a
release even though they are not the actual tagged version.

Technically there is not one for `master` either.  They are built from
the MR topic staging branch, which consists of `master` plus all the
staged MRs.  This makes it easy for reporters to test fixes before
they are merged.  It also gives our MRs the same testing that is done
for release binary builds (except for manual steps).

-Brad


From foss at grueninger.de  Tue Apr 25 15:55:40 2017
From: foss at grueninger.de (=?UTF-8?Q?Christoph_Gr=c3=bcninger?=)
Date: Tue, 25 Apr 2017 21:55:40 +0200
Subject: [cmake-developers] Patch: Don't emit warning when config file
 not found
In-Reply-To: <79078cb6-8eb9-bf6b-f95a-012367fa0d40@kitware.com>
References: <5dfb692f-2d8b-fc2b-be9c-fddb09415857@grueninger.de>
 <25936235-f6e3-2b0a-5e42-2e0ea92413f3@kitware.com>
 <a7cb2c26-a4d3-f5cf-9edc-92463d89dae0@grueninger.de>
 <47824be5-e09a-760d-7481-e199759a5b80@kitware.com>
 <90690897-78ce-3ed5-730d-7fc2f891f33e@grueninger.de>
 <79078cb6-8eb9-bf6b-f95a-012367fa0d40@kitware.com>
Message-ID: <96757392-225e-8e6f-df66-d1ae4bd51835@grueninger.de>

Hi Brad,
please find attached a first attempt to implement OPTIONAL for
find_package. It is supposed to suppress all warnings and indicate the
negative result by a single line of output. Unfortunately, I still get a
warning and I could figure out how to simply print a message without the
warning. Could you give me some hints and comment on my patch?

Thanks
Christoph

-- 
[..] Mathematicians are like theologians: we regard
existence as the prime attribute of what we study.
But unlike theologians, we need not always rely upon
faith alone.                      [Lawrence Evans]

Am 10.10.2016 um 14:51 schrieb Brad King:
> On 10/09/2016 03:24 PM, Christoph Gr?ninger wrote:
>> * or loosing the output of tests and feature summary, as both tests are QUIET.
>>
>> I'd prefer to write the error message to the CMakeError.log and reduce
>> the output to one line. I think, the current behavior must be considered
>> a bug.
> 
> The default behavior evolved over many years to satisfy many use cases and
> give people the information they need to resolve real problems.  It is not
> going to change.  However, if you'd like to propose additional options to
> these interfaces to get the behavior you want then that would be fine.
> Perhaps find_package could gain an ``OPTIONAL`` switch.  I'm not very
> familiar with feature_summary so I'm not sure what that would need off the
> top of my head.
> 
> -Brad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-cmFindPackageCommand-Add-OPTIONAL.patch
Type: text/x-patch
Size: 6100 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170425/bfac156e/attachment.bin>

From daniel at pfeifer-mail.de  Tue Apr 25 16:33:30 2017
From: daniel at pfeifer-mail.de (Daniel Pfeifer)
Date: Tue, 25 Apr 2017 22:33:30 +0200
Subject: [cmake-developers] Can we please require TR1 to build CMake?
In-Reply-To: <31df61b3-3d59-8762-4167-f5b82c2b9282@kitware.com>
References: <CANZMcXorK5NqOO655w0pzwr=AZT+p=MdUj_MY4QSfuarpm-1Hw@mail.gmail.com>
 <31df61b3-3d59-8762-4167-f5b82c2b9282@kitware.com>
Message-ID: <CANZMcXq=jHm9uO7r+kxhQZgYkrme_y6xDVV9dvaKbbqnCZV_9A@mail.gmail.com>

On Mon, Jan 9, 2017 at 8:30 PM, Brad King <brad.king at kitware.com> wrote:

> On 01/09/2017 05:46 AM, Daniel Pfeifer wrote:
> > start using TR1/C++11 library features, namely std::function, std::bind,
> > std::placeholders, std::shared_ptr, std::make_shared.
>
> I'd love to be able to start using those too, but last time I checked
> they are not supported everywhere CMake builds, at least in the standard
> libraries (see below).
>
> > AIX-7.1_IBM-12.1 reports that __IBMCPP_TR1__ must be defined to use TR1.
>
> Hopefully, but that would take some investigation.
>
> > Xcode 2.1 and 3.2 fail. These builds are not marked as "expected".
>
> I'd be okay with dropping these.
>
> > This leaves HP-UX.11iv2.ia64-aCC and Solaris-10-8.11_Oracle-12.3.
>
> IIUC the Oracle compiler supports C++11 when told to use the proper
> stdlib.  However, I don't think there is a solution on HP-UX with its
> standard library.
>
> > * Explicitly require SP1 for Visual Studio 2008.
>
> Okay.  For hosting CMake's own build we could even consider requiring
> VS 2010.  One blocker for that on Kitware's side is updating our
> dashboard machines as needed to be able to host CMake builds even if
> testing generators for older versions.  I'm not sure when I'll have
> time to do that.
>
> > * Disallow compiling in C++98 mode if compiler is capable of C++11.
>
> Okay.
>
> > * Require TR1 by all means. This may require setting up Boost.TR1
> >   on a very small number of exotic platforms.
>
> IIRC there is a tool to extract a subset of boost.  Please see how
> small it can get.  We can even remove the config headers for the
> platforms we don't need to use it, perhaps manually.
>

I have pushed an updated branch to
https://gitlab.kitware.com/cmake/cmake/merge_requests/760/diffs

The necessary subset of boost can be generated with:

```
mkdir -p cm_boost
bcp --boost=</path/to/boost> \
  boost/bind.hpp \
  boost/function.hpp \
  boost/mem_fn.hpp \
  boost/ref.hpp \
  boost/unordered_map.hpp \
  boost/unordered_set.hpp \
  boost/shared_ptr.hpp \
  boost/weak_ptr.hpp \
  boost/enable_shared_from_this.hpp \
  cm_boost
```

The resulting directory is 6.5 MB, 2.6 MB of which are preprocessed headers
for Boost.MPL.
When we remove them, we get the size down to 3.9 MB.
Removing individual config headers is tedious and does not save much.

Cheers, Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170425/4f7080d3/attachment.html>

From irwin at beluga.phys.uvic.ca  Wed Apr 26 04:14:30 2017
From: irwin at beluga.phys.uvic.ca (Alan W. Irwin)
Date: Wed, 26 Apr 2017 01:14:30 -0700 (PDT)
Subject: [cmake-developers] On-going UseSWIG troubles with the official
 versions --SOLVED
In-Reply-To: <6c765a3c-be3d-cce4-2354-52b84bc48212@kitware.com>
References: <alpine.DEB.2.11.1704231309580.32335@enira.zlyna.ubzr>
 <alpine.DEB.2.11.1704241143590.32335@enira.zlyna.ubzr>
 <6c765a3c-be3d-cce4-2354-52b84bc48212@kitware.com>
Message-ID: <alpine.DEB.2.11.1704260112540.32335@enira.zlyna.ubzr>

On 2017-04-25 08:54-0400 Brad King wrote:

> On 04/25/2017 04:08 AM, Alan W. Irwin wrote:
>> set PREFIX to "" for all languages not specifically covered by the if
>> and elseif blocks.
>
> Do you mean
>
> ```
> diff --git a/Modules/UseSWIG.cmake b/Modules/UseSWIG.cmake
> index 277f4ca28a..bfe1a6f754 100644
> --- a/Modules/UseSWIG.cmake
> +++ b/Modules/UseSWIG.cmake
> @@ -326,6 +326,9 @@ macro(SWIG_ADD_LIBRARY name)
>     if (APPLE)
>       set_target_properties (${SWIG_MODULE_${name}_REAL_NAME} PROPERTIES SUFFIX ".bundle")
>     endif ()
> +  else()
> +    # assume empty prefix because we expect the module to be dynamically loaded
> +    set_target_properties (${SWIG_MODULE_${name}_REAL_NAME} PROPERTIES PREFIX "")
>   endif ()
> endmacro()
> ```
>
> ?

Yes, exactly.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

From brad.king at kitware.com  Wed Apr 26 10:27:41 2017
From: brad.king at kitware.com (Brad King)
Date: Wed, 26 Apr 2017 10:27:41 -0400
Subject: [cmake-developers] Patch: Don't emit warning when config file
 not found
In-Reply-To: <96757392-225e-8e6f-df66-d1ae4bd51835@grueninger.de>
References: <5dfb692f-2d8b-fc2b-be9c-fddb09415857@grueninger.de>
 <25936235-f6e3-2b0a-5e42-2e0ea92413f3@kitware.com>
 <a7cb2c26-a4d3-f5cf-9edc-92463d89dae0@grueninger.de>
 <47824be5-e09a-760d-7481-e199759a5b80@kitware.com>
 <90690897-78ce-3ed5-730d-7fc2f891f33e@grueninger.de>
 <79078cb6-8eb9-bf6b-f95a-012367fa0d40@kitware.com>
 <96757392-225e-8e6f-df66-d1ae4bd51835@grueninger.de>
Message-ID: <73b6da71-ef6d-4171-a09a-ec97b4fa8147@kitware.com>

On 04/25/2017 03:55 PM, Christoph Gr?ninger wrote:
> please find attached a first attempt to implement OPTIONAL for
> find_package. It is supposed to suppress all warnings and indicate the
> negative result by a single line of output. Unfortunately, I still get a
> warning and I could figure out how to simply print a message without the
> warning. Could you give me some hints and comment on my patch?

The IssueMessage API is for formatted diagnostics with backtraces.
Use DisplayStatus for a simple status line:

```
diff --git a/Source/cmFindPackageCommand.cxx b/Source/cmFindPackageCommand.cxx
index 2f899a38ff..af64884d2b 100644
--- a/Source/cmFindPackageCommand.cxx
+++ b/Source/cmFindPackageCommand.cxx
@@ -844,8 +844,8 @@ bool cmFindPackageCommand::HandlePackageMode()
       aw << "Could not find " << this->Name
          << ". (No " << this->Name
          << ".cmake or " << this->Name
-         << "-config.cmake)\n";
-      this->Makefile->IssueMessage(cmake::MESSAGE, aw.str());
+         << "-config.cmake)";
+      this->Makefile->DisplayStatus(aw.str().c_str(), -1);
   }

   // Set a variable marking whether the package was found.
```

One of the reasons the default message is so long is to help both
project authors when writing find_package calls (perhaps trying to
use a Find<pkg>.cmake file) and end-users trying to find a package.
Older forms of the message caused a lot of confusion about the role
of find modules (Find<pkg>.cmake) versus package configuration files
(<pkg>Config.cmake).  We need to make sure new messages don't cause
such confusion again, so we should never have wording that mentions
both files.

When a find module is in use then the Find<pkg>.cmake module is
responsible for result messages.  `find_package_handle_standard_args`
already constructs a nice single-line status message such as:

    -- Could NOT find ZLIB (missing: ZLIB_LIBRARY ZLIB_INCLUDE_DIR)

Therefore I think the proposed status message is only needed in
CONFIG mode when we can't find a <pkg>Config.cmake file.  IIUC you'd
like to replace the long-winded warning with something like:

    -- Could NOT find Foo (missing: Foo_DIR)

Correct?

Thanks,
-Brad


From brad.king at kitware.com  Wed Apr 26 10:54:18 2017
From: brad.king at kitware.com (Brad King)
Date: Wed, 26 Apr 2017 10:54:18 -0400
Subject: [cmake-developers] On-going UseSWIG troubles with the official
 versions --SOLVED
In-Reply-To: <alpine.DEB.2.11.1704260112540.32335@enira.zlyna.ubzr>
References: <alpine.DEB.2.11.1704231309580.32335@enira.zlyna.ubzr>
 <alpine.DEB.2.11.1704241143590.32335@enira.zlyna.ubzr>
 <6c765a3c-be3d-cce4-2354-52b84bc48212@kitware.com>
 <alpine.DEB.2.11.1704260112540.32335@enira.zlyna.ubzr>
Message-ID: <bcdd4103-6215-b07b-9a01-923af1e8f820@kitware.com>

On 04/26/2017 04:14 AM, Alan W. Irwin wrote:
> On 2017-04-25 08:54-0400 Brad King wrote:
>> +  else()
>> +    # assume empty prefix because we expect the module to be dynamically loaded
>> +    set_target_properties (${SWIG_MODULE_${name}_REAL_NAME} PROPERTIES PREFIX "")
> 
> Yes, exactly.

Thanks: https://gitlab.kitware.com/cmake/cmake/merge_requests/767

-Brad


From foss at grueninger.de  Wed Apr 26 16:11:19 2017
From: foss at grueninger.de (=?UTF-8?Q?Christoph_Gr=c3=bcninger?=)
Date: Wed, 26 Apr 2017 22:11:19 +0200
Subject: [cmake-developers] Patch: Don't emit warning when config file
 not found
In-Reply-To: <73b6da71-ef6d-4171-a09a-ec97b4fa8147@kitware.com>
References: <5dfb692f-2d8b-fc2b-be9c-fddb09415857@grueninger.de>
 <25936235-f6e3-2b0a-5e42-2e0ea92413f3@kitware.com>
 <a7cb2c26-a4d3-f5cf-9edc-92463d89dae0@grueninger.de>
 <47824be5-e09a-760d-7481-e199759a5b80@kitware.com>
 <90690897-78ce-3ed5-730d-7fc2f891f33e@grueninger.de>
 <79078cb6-8eb9-bf6b-f95a-012367fa0d40@kitware.com>
 <96757392-225e-8e6f-df66-d1ae4bd51835@grueninger.de>
 <73b6da71-ef6d-4171-a09a-ec97b4fa8147@kitware.com>
Message-ID: <328a487a-86d5-f9d4-87f1-1b88f3d89cc7@grueninger.de>

Hi Brad,
thanks for helping me out with the patch. Your wording of the message is
better than my proposal.
Please find attached an improved patch.

Bye
Christoph

-- 
[..] Mathematicians are like theologians: we regard
existence as the prime attribute of what we study.
But unlike theologians, we need not always rely upon
faith alone.                      [Lawrence Evans]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-cmFindPackageCommand-Add-OPTIONAL.patch
Type: text/x-patch
Size: 6071 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170426/a2f90d81/attachment.bin>

From brad.king at kitware.com  Wed Apr 26 16:31:34 2017
From: brad.king at kitware.com (Brad King)
Date: Wed, 26 Apr 2017 16:31:34 -0400
Subject: [cmake-developers] Requesting Advice: Installing object files
In-Reply-To: <e164eac0-217c-f9de-b6e6-3954d6cced78@kitware.com>
References: <2DD784D7-E950-43A7-BEC4-E69700D5536C@me.com>
 <bb95abc9-ee5c-805d-37de-78efde2b3985@gmail.com>
 <20170118135800.GA6386@megas.kitware.com>
 <C82B494F-3584-414E-BFDC-FC7CEA9D4E96@me.com>
 <20170118201407.GA21551@megas.kitware.com>
 <e164eac0-217c-f9de-b6e6-3954d6cced78@kitware.com>
Message-ID: <2ce02c7d-4a68-3bfb-b0f5-0aeea7be6598@kitware.com>

On 01/18/2017 03:14 PM, Ben Boeckel wrote:
> Installing the target can install the objects.
[snip]
On 01/18/2017 02:47 PM, Chris Bieneman wrote:
> If this allowed TARGET_OBJECTS to be used in the install(FILES ...)
> command, then we could create an object library and a custom install
> rule for the objects, which would be a lot cleaner.

In CMake `master` we now support `$<TARGET_OBJECTS:...>` in
`install(FILES)` and also support installing object libraries
directly via `install(TARGETS)` with an `OBJECTS DESTINATION`.

This will be in CMake 3.9.  Please try it out.

One problem for your use case is that the object file names
are still controlled by the generator.  You may need a custom
step with `install(SCRIPT)` or `install(CODE)` to fix the names
after installation.

-Brad

From brad.king at kitware.com  Wed Apr 26 16:38:31 2017
From: brad.king at kitware.com (Brad King)
Date: Wed, 26 Apr 2017 16:38:31 -0400
Subject: [cmake-developers] Patch: Don't emit warning when config file
 not found
In-Reply-To: <328a487a-86d5-f9d4-87f1-1b88f3d89cc7@grueninger.de>
References: <5dfb692f-2d8b-fc2b-be9c-fddb09415857@grueninger.de>
 <25936235-f6e3-2b0a-5e42-2e0ea92413f3@kitware.com>
 <a7cb2c26-a4d3-f5cf-9edc-92463d89dae0@grueninger.de>
 <47824be5-e09a-760d-7481-e199759a5b80@kitware.com>
 <90690897-78ce-3ed5-730d-7fc2f891f33e@grueninger.de>
 <79078cb6-8eb9-bf6b-f95a-012367fa0d40@kitware.com>
 <96757392-225e-8e6f-df66-d1ae4bd51835@grueninger.de>
 <73b6da71-ef6d-4171-a09a-ec97b4fa8147@kitware.com>
 <328a487a-86d5-f9d4-87f1-1b88f3d89cc7@grueninger.de>
Message-ID: <4f0157c4-e90f-045d-4ba7-1b68d7ef68ca@kitware.com>

On 04/26/2017 04:11 PM, Christoph Gr?ninger wrote:
> thanks for helping me out with the patch. Your wording of the message is
> better than my proposal.
> Please find attached an improved patch.

Thanks.  This is a good start.  Please see CONTRIBUTING.rst
and open a merge request on gitlab.kitware.com so we can perform
further review there.

The patch will need more work:

* Reject use of OPTIONAL and REQUIRED together.
* What about OPTIONAL and QUIET together?
* Document _FIND_OPTIONAL for find modules.
* Add tests.

Thanks,
-Brad


From cpfeiffer at live.de  Wed Apr 26 17:45:36 2017
From: cpfeiffer at live.de (Christian Pfeiffer)
Date: Wed, 26 Apr 2017 21:45:36 +0000
Subject: [cmake-developers] Adding Microsoft MPI Fortran support in
 FindMPI
In-Reply-To: <a285b6aa-50b2-f34e-4670-7d5a28ea6fa9@kitware.com>
References: <AM5P194MB00346534AC9779901BA43256AD1A0@AM5P194MB0034.EURP194.PROD.OUTLOOK.COM>
 <a285b6aa-50b2-f34e-4670-7d5a28ea6fa9@kitware.com>
Message-ID: <AM5P194MB0034B75502C3612476824683AD110@AM5P194MB0034.EURP194.PROD.OUTLOOK.COM>

I reckon it might be better to ignore the Fortran 90 module API for now.
Adding a function for that would mean that the linked target has to be 
visible everywhere where the MPI package is being used with Fortran. Not 
to mention that all projects using the F90 module API then would need to 
have extra code for supporting MSMPI, significantly limiting its usefulness.

Originally, I thought the mpi.f90 file just defined the MPI modules, but 
there's a few COMMON blocks that will end up as dllimport symbols and 
therefore need linking with the result, instead of it sufficing to just 
add some include directories after creating the .mod file.

Adding the Fortran 77 API isn't a problem at all on the other hand, so I 
would be leaving it at that for the time being. In case a user 
absolutely needs Fortran 90 support on MSMPI, they'd have to compile the 
file in advance, add it to the includes and the Fortran libraries. 
That's not too much trouble and imho a better way than adding a 
requirement for project code which then would need to be maintained in 
future versions, too.

- Chris

On 4/24/2017 3:06 PM, Brad King wrote:
> On 04/21/2017 05:45 PM, Christian P. wrote:
>> Is this a good/bad idea or is there any way to do this in a proper fashion?
>> The idea of adding an actual target to a Find module seems wrong to me,
>> but I?m not seeing any way of doing it otherwise.
> I think we'll have to expose this requirement to project code.  Provide
> a function the project can call to make the needed target available.  That
> way the project can control if/when it is done and what the target is
> called.
>
> -Brad
>


From brad.king at kitware.com  Thu Apr 27 08:11:23 2017
From: brad.king at kitware.com (Brad King)
Date: Thu, 27 Apr 2017 08:11:23 -0400
Subject: [cmake-developers] Patch: Don't emit warning when config file
 not found
In-Reply-To: <4f0157c4-e90f-045d-4ba7-1b68d7ef68ca@kitware.com>
References: <5dfb692f-2d8b-fc2b-be9c-fddb09415857@grueninger.de>
 <25936235-f6e3-2b0a-5e42-2e0ea92413f3@kitware.com>
 <a7cb2c26-a4d3-f5cf-9edc-92463d89dae0@grueninger.de>
 <47824be5-e09a-760d-7481-e199759a5b80@kitware.com>
 <90690897-78ce-3ed5-730d-7fc2f891f33e@grueninger.de>
 <79078cb6-8eb9-bf6b-f95a-012367fa0d40@kitware.com>
 <96757392-225e-8e6f-df66-d1ae4bd51835@grueninger.de>
 <73b6da71-ef6d-4171-a09a-ec97b4fa8147@kitware.com>
 <328a487a-86d5-f9d4-87f1-1b88f3d89cc7@grueninger.de>
 <4f0157c4-e90f-045d-4ba7-1b68d7ef68ca@kitware.com>
Message-ID: <ba0cf2d6-6bd4-8c65-9d3e-991f4d3be10f@kitware.com>

On 04/26/2017 04:38 PM, Brad King wrote:
> Thanks.  This is a good start
> 
> * Reject use of OPTIONAL and REQUIRED together.
> * What about OPTIONAL and QUIET together?
> * Document _FIND_OPTIONAL for find modules.

Having thought about these more, I think perhaps my suggestion to
add an `OPTIONAL` argument is too complex and not necessary:

* The lack of `REQUIRED` already indicates optional.
* The unclear argument combinations may cause more confusion.
* The find modules have no clear use for _FIND_OPTIONAL.
* The find modules already handle the not-found case as a
  one-line status message or with REQUIRED a full error.

As I posted previously one of the reasons the default message is
so long is because we don't know whether we are supposed to have
a find module or not.  If the call uses arguments exclusive to
Config mode then we don't necessarily need the full explanation.

Another reason for the long message is that when the package is not
found we try to give the user instructions on how to resolve the
problem.  The "missing: <var>..." part of the find module messages
serves that role nicely, but was introduced more recently than we
last visited the config-mode wording.  Based on our last few posts
in this thread I think that wording can work well for config-mode
too.

I propose that when the find_package call uses arguments exclusive
to the config-mode (e.g. CONFIG, NO_MODULE, or some of the others)
and the call does *not* specify REQUIRED, then we can use the
one-line wording if the package is not found:

    -- Could NOT find Foo (missing: Foo_DIR)

The "missing: Foo_DIR" provides a hint of a path forward for users.
The fact that a config-mode argument was given to the call indicates
that the project author is not expecting a find module to be used,
so we don't need the full explanation.

When REQUIRED is specified we should continue to produce the same
full error message we do now.  It provides more detail on how to
resolve the problem, which is important when the package is required.

The above approach should be a much simpler change.  It will allow
you to use the `find_package(Vc CONFIG)` form of the call I suggested
much earlier in the thread, but give a more concise message than it
does now (and with no warning or stack trace).

Thanks,
-Brad


From foss at grueninger.de  Fri Apr 28 17:43:10 2017
From: foss at grueninger.de (=?UTF-8?Q?Christoph_Gr=C3=BCninger?=)
Date: Fri, 28 Apr 2017 23:43:10 +0200 (CEST)
Subject: [cmake-developers] Patch: Don't emit warning when config file
 not found
In-Reply-To: <ba0cf2d6-6bd4-8c65-9d3e-991f4d3be10f@kitware.com>
References: <5dfb692f-2d8b-fc2b-be9c-fddb09415857@grueninger.de>
 <25936235-f6e3-2b0a-5e42-2e0ea92413f3@kitware.com>
 <a7cb2c26-a4d3-f5cf-9edc-92463d89dae0@grueninger.de>
 <47824be5-e09a-760d-7481-e199759a5b80@kitware.com>
 <90690897-78ce-3ed5-730d-7fc2f891f33e@grueninger.de>
 <79078cb6-8eb9-bf6b-f95a-012367fa0d40@kitware.com>
 <96757392-225e-8e6f-df66-d1ae4bd51835@grueninger.de>
 <73b6da71-ef6d-4171-a09a-ec97b4fa8147@kitware.com>
 <328a487a-86d5-f9d4-87f1-1b88f3d89cc7@grueninger.de>
 <4f0157c4-e90f-045d-4ba7-1b68d7ef68ca@kitware.com>
 <ba0cf2d6-6bd4-8c65-9d3e-991f4d3be10f@kitware.com>
Message-ID: <422791751.15778.1493415790761@com4.strato.de>

Hi Brad,
great idea! Your suggestion will make everybody happy.
I attached two patches implementing it.

Bye
Christoph
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-cmFindPackageCommand-shorten-output-for-missing-pack.patch
Type: text/x-patch
Size: 1576 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170428/ea56a785/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-cmFindPackageCommand-Split-condition-to-improve-read.patch
Type: text/x-patch
Size: 10390 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170428/ea56a785/attachment-0001.bin>

From irwin at beluga.phys.uvic.ca  Sat Apr 29 16:47:29 2017
From: irwin at beluga.phys.uvic.ca (Alan W. Irwin)
Date: Sat, 29 Apr 2017 13:47:29 -0700 (PDT)
Subject: [cmake-developers] Issues with overriding Python version,
	possible bug?
Message-ID: <alpine.DEB.2.11.1704291249261.32335@enira.zlyna.ubzr>

My use case (which I am pretty sure is a common one) is that for
PLplot I want the default behaviour of our build system to be that it
looks for Python 3, but if that does not exist it looks for Python 2.

It appears the following logic implements that desired default
behaviour.

find_package(PythonInterp 3)
find_package(PythonInterp 2)

So far so good, but I am sure there will be some of our users that
prefer Python 2 even when Python 3 is installed on their system.

I could implement that user choice with a special FORCE_PYTHON2 option
option to allow the user to skip the first find_package command above,
but if possible I would far prefer that our users used a more standard
way (e.g., by setting Python_ADDITIONAL_VERSIONS) to specify the
Python version they prefer. However, when I tried (for both CMake-3.6.2 and
CMake-3.8.0-rc4) -DPython_ADDITIONAL_VERSIONS:STRING=2, the result was
that setting was ignored, i.e., the result of the above two
find_package commands was

-- Found PythonInterp: /usr/bin/python3 (found suitable version "3.4.2", minimum required is "3") 
-- Found PythonInterp: /usr/bin/python3 (found suitable version "3.4.2", minimum required is "2")

Is this ignoring of Python_ADDITIONAL_VERSIONS for the above
find_package logic due to a bug in Modules/FindPythonInterp.cmake? Is
there some other standard way that the Python version can overridden
by the user for the above find_package logic?

(I am sorry I cannot answer either of these questions myself, but I am
having real trouble following the PythonInterp module logic for the
case when the default behaviour is specified via the above
find_package logic.)

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________