Re: [cmake-developers] kwsysProcess threadsafety

[clinton]

Cool.  I'd like to have parallel automoc and uic.

How about this 4th option?
Don't use threads.  A single thread is able to spawn multiple processes, and 
wait on multiple processes, and react when 1 or more processes change state.  
I'm probably not familiar enough with kwsysProcess to know if this approach 
will work, but it might be easier and simpler(?) than making it thread safe.

Clint

- On Jan 5, 2018, at 12:34 PM, Sebastian Holtermann sebl...@xwmw.org wrote:

> Hello!
> 
> As you might have noticed I tried to parallelize AUTOMOC/UIC.
> https://gitlab.kitware.com/cmake/cmake/merge_requests/1632
> The issue that's blocking it now is that the kwsysProcess framework
> isn't thread safe. As a consequence it is not possible for threads to
> start processes concurrently using the kwsysProcess framework.
> 
> There are three options I see
> 
> 1) Make kwsysProcess thread safe
> 
> I don't think it's impossible but it's not a small task.
> Looking through the code I found a few issues that
> would block the whole idea for me.
>  - OpenVMS: I have little to no knowledge about OpenVMS.
>Wikipedia says it is basically abandoned.
>Can the OpenVMS code be removed? I couldn't test it anyway.
> 
>  - C vs. C++
>There's a lot of C in processUNIX.c (list allocation etc.).
>I would prefer to use C++11 (or higher), especially
>std::array, std::vector, std::thread,  std::mutex, etc..
>Is C++11 acceptable in kwsysProcess?
>This would make processUNIX.c processUNIX.cpp?
> 
> 2) Use libuv instead
> 
> Using the libuv event loop is overkill and would probably imply that
> more threads are started than necessary
> (the libuv thread pool will be started anyway).
> But it would allow to start multiple concurrent  (moc/uic) processes.
> Is there a reason to not use libuv?
> 
> 3) Abandon the idea to parallelize AUTOMOC/UIC
> 
> Well, I liked the idea.
> 
> 
> Any thoughts?
> 
> -Sebastian
> 
> --
> 
> 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:
> https://cmake.org/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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMP0071

[clinton]

- On Sep 26, 2017, at 9:07 AM, Sebastian Holtermann sebl...@xwmw.org wrote:

>> I updated and I'm getting this:
>> 
>> CMake Warning (dev) in claro/navigation5/CMakeLists.txt:
>> Policy CMP0071 is not set: Let AUTOMOC and AUTOUIC process GENERATED files.
>> Run "cmake --help-policy CMP0071" for policy details. Use the cmake_policy
>> command to set the policy and suppress this warning.
>> 
>> AUTOMOC: Ignoring GENERATED header file(s):
>> 
>> "/path/to/ui_SomeFile.h"
>> "/path/to/qrc_AnotherFile.cpp"
>> 
>> 
>> Those ui_* and qrc_* files do not require processing by moc.
>> In this case, I was using qt5_wrap_ui() and qt5_add_resources().
>> 
>> I did an experiment and replaced qt5_wrap_ui() with autouic, and the warning
>> went away for those ui_* files.
>> 
>> Is there a way to not print out that policy warning on ui_* and qrc_* files
>> when using qt5_wrap_ui()/qt5_add_resources()? These are the only file types
>> for which I'm getting that warning.
> 
> You can set the source file property SKIP_AUTOMOC on the GENERATED files.
> See: https://cmake.org/cmake/help/v3.9/prop_sf/SKIP_AUTOMOC.html
> See: https://cmake.org/cmake/help/git-master/policy/CMP0071.html
> 
> For example like this
> ```
> set_property(SOURCE /path/to/ui_SomeFile.h PROPERTY SKIP_AUTOMOC ON)
> set_property(SOURCE /path/to/qrc_AnotherFile.cpp PROPERTY SKIP_AUTOMOC ON)
> ```
> 

I'm probably pushing things here, but why not.
I'm experimenting with setting AUTOMOC/AUTOUIC/AUTORCC on, and also using the 
qt5_* macros.

I see the rcc processing only looks at *.qrc files, but the uic processing 
looks at files with any extension.  Why not limit that to just *.ui files?  I 
find myself setting SKIP_AUTOUIC on *.h and *.cpp files to silence CMP0071 
warnings.  Its obvious to me that a .cpp or .h file is not an xml file as 
expected by uic.

I can understand having to set SKIP_AUTOMOC on files with various file 
extensions.

I bring this up here in case something needs to change on the CMake side.

Clint
-- 

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

Re: [cmake-developers] CMP0071

[clinton]

- On Sep 26, 2017, at 9:31 AM, Sebastian Holtermann sebl...@xwmw.org wrote:

> On Dienstag, 26. September 2017 09:25:36 CEST clin...@elemtech.com wrote:
>> - On Sep 26, 2017, at 9:07 AM, Sebastian Holtermann sebl...@xwmw.org
> wrote:
>> >> I updated and I'm getting this:
>> >> 
>> >> CMake Warning (dev) in claro/navigation5/CMakeLists.txt:
>> >> Policy CMP0071 is not set: Let AUTOMOC and AUTOUIC process GENERATED
>> >> files.
>> >> Run "cmake --help-policy CMP0071" for policy details. Use the
>> >> cmake_policy
>> >> command to set the policy and suppress this warning.
>> >> 
>> >> AUTOMOC: Ignoring GENERATED header file(s):
>> >> 
>> >> "/path/to/ui_SomeFile.h"
>> >> "/path/to/qrc_AnotherFile.cpp"
>> >> 
>> >> 
>> >> Those ui_* and qrc_* files do not require processing by moc.
>> >> In this case, I was using qt5_wrap_ui() and qt5_add_resources().
>> >> 
>> >> I did an experiment and replaced qt5_wrap_ui() with autouic, and the
>> >> warning went away for those ui_* files.
>> >> 
>> >> Is there a way to not print out that policy warning on ui_* and qrc_*
>> >> files
>> >> when using qt5_wrap_ui()/qt5_add_resources()? These are the only file
>> >> types
>> >> for which I'm getting that warning.
>> > 
>> > You can set the source file property SKIP_AUTOMOC on the GENERATED files.
>> > See: https://cmake.org/cmake/help/v3.9/prop_sf/SKIP_AUTOMOC.html
>> > See: https://cmake.org/cmake/help/git-master/policy/CMP0071.html
>> > 
>> > For example like this
>> > ```
>> > set_property(SOURCE /path/to/ui_SomeFile.h PROPERTY SKIP_AUTOMOC ON)
>> > set_property(SOURCE /path/to/qrc_AnotherFile.cpp PROPERTY SKIP_AUTOMOC ON)
>> > ```
>> 
>> Would it make sense for qt5_wrap_ui() and qt5_add_resources() to set
>> SKIP_AUTOMOC on the ui_* and qrc_* files?
> 
> That would be the best solution. The macros are provided by Qt though and not
> by CMake.

I agree.

I've reported it there
https://bugreports.qt.io/browse/QTBUG-63442

Thanks,
Clint
-- 

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

Re: [cmake-developers] CMP0071

[clinton]

- On Sep 26, 2017, at 9:07 AM, Sebastian Holtermann sebl...@xwmw.org wrote:

>> I updated and I'm getting this:
>> 
>> CMake Warning (dev) in claro/navigation5/CMakeLists.txt:
>> Policy CMP0071 is not set: Let AUTOMOC and AUTOUIC process GENERATED files.
>> Run "cmake --help-policy CMP0071" for policy details. Use the cmake_policy
>> command to set the policy and suppress this warning.
>> 
>> AUTOMOC: Ignoring GENERATED header file(s):
>> 
>> "/path/to/ui_SomeFile.h"
>> "/path/to/qrc_AnotherFile.cpp"
>> 
>> 
>> Those ui_* and qrc_* files do not require processing by moc.
>> In this case, I was using qt5_wrap_ui() and qt5_add_resources().
>> 
>> I did an experiment and replaced qt5_wrap_ui() with autouic, and the warning
>> went away for those ui_* files.
>> 
>> Is there a way to not print out that policy warning on ui_* and qrc_* files
>> when using qt5_wrap_ui()/qt5_add_resources()? These are the only file types
>> for which I'm getting that warning.
> 
> You can set the source file property SKIP_AUTOMOC on the GENERATED files.
> See: https://cmake.org/cmake/help/v3.9/prop_sf/SKIP_AUTOMOC.html
> See: https://cmake.org/cmake/help/git-master/policy/CMP0071.html
> 
> For example like this
> ```
> set_property(SOURCE /path/to/ui_SomeFile.h PROPERTY SKIP_AUTOMOC ON)
> set_property(SOURCE /path/to/qrc_AnotherFile.cpp PROPERTY SKIP_AUTOMOC ON)
> ```
> 

Would it make sense for qt5_wrap_ui() and qt5_add_resources() to set 
SKIP_AUTOMOC on the ui_* and qrc_* files?

Clint
-- 

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

[cmake-developers] CMP0071

[clinton]

I updated and I'm getting this: 

CMake Warning (dev) in claro/navigation5/CMakeLists.txt: 
Policy CMP0071 is not set: Let AUTOMOC and AUTOUIC process GENERATED files. 
Run "cmake --help-policy CMP0071" for policy details. Use the cmake_policy 
command to set the policy and suppress this warning. 

AUTOMOC: Ignoring GENERATED header file(s): 

"/path/to/ui_SomeFile.h" 
"/path/to/qrc_AnotherFile.cpp" 


Those ui_* and qrc_* files do not require processing by moc. 
In this case, I was using qt5_wrap_ui() and qt5_add_resources(). 

I did an experiment and replaced qt5_wrap_ui() with autouic, and the warning 
went away for those ui_* files. 

Is there a way to not print out that policy warning on ui_* and qrc_* files 
when using qt5_wrap_ui()/qt5_add_resources()? 
These are the only file types for which I'm getting that warning. 

I think the related issue is here: 
https://gitlab.kitware.com/cmake/cmake/issues/16186 

Thanks, 
Clint 
-- 

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

Re: [cmake-developers] CPackProductbuild Scripts

[clinton]

- On Dec 12, 2016, at 9:51 AM, Harry Mallon ha...@codexdigital.com wrote:

> Hello,
> 
> I am messing around with the CPackProductbuild stuff to try to port over what 
> we
> had before. Currently it support undocumented options
> "CPACK_PREFLIGHT_SCRIPT", "CPACK_POSTFLIGHT_SCRIPT",
> "CPACK_PREFLIGHT__SCRIPT" and 
> "CPACK_POSTFLIGHT__SCRIPT".
> It looks like these are also supported (also undocumented) in
> CPackPackageMaker. Are these options good names? Do they need to be these for
> ease of porting from Package Maker?

Productbuild inherited those variables by factoring out common pkg support 
between PackageMaker and ProductBuild.
I'm not aware of porting concerns, but I can imagine that being useful.
I think there *are* people using the undocumented variables with PackageMaker.

> Should they start with CPACK_PRODUCTBUILD_*
> as they are not generic?

The other CPack generators have their own variable names for this kind of thing.
And they also have separate code to handle it.  In this case, we have 2 pkg 
based generators with a potential of using the same named variables.

With PackageMaker being deprecated, CPACK_PRODUCTBUILD_* sounds good.

Clint

> 
> If the current names are fine I can prepare a pull req with documentation.
> 
> Yours,
> Harry
> 
> Harry Mallon
> CODEX | Software Engineer
> 60 Poland Street | London | England | W1F 7NT
> E ha...@codexdigital.com | T +44 203 7000 989
> --
> 
> 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

[cmake-developers] possible fix to include in release

[clinton]

Hi, 

If there is a CMake 3.6.3, I'd like to request the inclusion of 
https://cmake.org/gitweb?p=cmake.git;a=commit;h=48624b3c 

Some Linux distros are now shipping cmake-gui on top of Qt5, and the reported 
QFileDialog problem is present. 
See also http://public.kitware.com/pipermail/cmake/2016-September/064262.html 

Thanks, 
Clint 
-- 

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

Re: [cmake-developers] [PATCH v3 5/7] For consoles output on Windows use our own std::streambuf

[clinton]

From what I remember, WriteConsoleW doesn't support redirection to a file or pipe.  I don't see an alternative in the patch for the case where stdout is not attached to the console.
Clint

-- 

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

Re: [cmake-developers] [PATCH] Improve encoding handling on Windows

[clinton]

- On Jun 30, 2016, at 8:18 PM, Dāvis Mosāns davis...@gmail.com wrote:

> On Windows getenv uses ANSI codepage so it needs to be encoded to
> internally used encoding (eg. UTF-8). Here we use _wgetenv instead
> and encode that.
> 
> Also typically Windows applications (eg. MSVC compiler) use current
> console's codepage for output to pipes so we need to encode that
> to internally used encoding (KWSYS_ENCODING_DEFAULT_CODEPAGE).
> 
> Next, when we're outputing to console need to use wide functions.
> 
> This change allows that compilers such as MSVC on Windows can be
> installed in non-ASCII path and will work correctly for all
> console's codepages which supports that path's characters.

...

> +#if defined(_WIN32)
> +  // Kinda hack, with MSVC (and MinGW) for some reason std::wcout
> +  // (and all other std::w*) fails once it encounters non-ASCII
> +  // string unless locale is set.
> +  // Note that even with this, seems it can't output characters
> +  // which aren't present in ANSI codepage no matter what encoding
> +  // is used for console.
> +  // Also once any character outside of ANSI codepage is tried to
> +  // be outputed then after there anymore won't be output from
> +  // any of std::w* functions.
> +  _wsetlocale(LC_ALL, L"");
> +#endif

The _wsetlocale() may be a problem.

See:
https://gitlab.kitware.com/cmake/cmake/commit/87be2e142
https://cmake.org/Bug/view.php?id=16099


> @@ -30,8 +30,23 @@ namespace @KWSYS_NAMESPACE@
>   typedef std::basic_filebuf my_base_type;
>   basic_filebuf *open(char const *s,std::ios_base::openmode mode)
>   {
> +std::wstring wstr = Encoding::ToWide(s);
> +const wchar_t *ws = wstr.c_str();
> +#if defined(_MSC_VER) && _MSC_VER >= 1400
> +const wchar_t *ss = ws;
> +#else
> +const char *ss = 0;
> +size_t length = std::wcstombs(0, ws, 0);
> +if (length != size_t(-1)) {
> +  std::vector str(length + 1);
> +  ss = str.data();
> +  std::wcstombs((char *)ss, ws, str.size());
> +} else {
> +  ss = s;
> +}
> +#endif
> return static_cast(
> -  my_base_type::open(Encoding::ToWide(s).c_str(), mode)
> +  my_base_type::open(ss, mode)
>   );

Yes.  It makes sense to convert from utf-8 to code page when we are not using 
the wide apis.
This would at least give you support for the current code page, beyond ascii.   
Beyond that, the wide functions should be used.
Which compiler are you trying to support here, which doesn't give a wide open()?


>   }
>   };
> diff --git a/Source/kwsys/ProcessWin32.c b/Source/kwsys/ProcessWin32.c
> index 2b93e69..208e725 100644
> --- a/Source/kwsys/ProcessWin32.c
> +++ b/Source/kwsys/ProcessWin32.c
> @@ -181,7 +181,7 @@ struct kwsysProcessPipeData_s
>   /* - Data managed per call to Execute - */
> 
>   /* Buffer for data read in this pipe's thread.  */
> -  char DataBuffer[KWSYSPE_PIPE_BUFFER_SIZE];
> +  char DataBuffer[KWSYSPE_PIPE_BUFFER_SIZE*2];

This "*2" assumes all characters cmake sees will fit in the Basic Multilingual 
Plane.
Are we OK assuming that?
If the conversion from a code page to utf-16 results in surrogate pairs, there 
may not be enough space.


> 
>   /* The length of the data stored in the buffer.  */
>   DWORD DataLength;
> @@ -1626,6 +1626,25 @@ void kwsysProcessPipeThreadReadPipe(kwsysProcess* cp,
> kwsysProcessPipeData* td)
>   KWSYSPE_DEBUG((stderr, "read closed %d\n", td->Index));
>   }
> 
> +if (td->DataLength > 0) {
> +UINT codepage = GetConsoleCP();
> +if (!codepage) {
> +codepage = GetACP();


Can this be stored in kwsysProcessCreateInformation, and not computed ever time 
we read data?



> +}
> +if (codepage != KWSYS_ENCODING_DEFAULT_CODEPAGE) {
> +int wlength = MultiByteToWideChar(codepage, 0, td->DataBuffer,
> td->DataLength, NULL, 0);
> +wchar_t* wdata = malloc(wlength * sizeof(wchar_t));
> +int r = MultiByteToWideChar(codepage, 0, td->DataBuffer,
> td->DataLength, wdata, wlength);
> +if (r > 0) {
> +r = WideCharToMultiByte(KWSYS_ENCODING_DEFAULT_CODEPAGE, 0,
> wdata, wlength, td->DataBuffer, KWSYSPE_PIPE_BUFFER_SIZE * 2, NULL, NULL);
> +if (r > 0) {
> +td->DataLength = r;
> +}
> +}
> +free(wdata);
> +}
> +}

How about avoiding a malloc()/free() each time we read an array?

ProcessWin32.c already uses Encoding.h.  How about using the Encoding instead 
of 
WideCharToMultiByte(...)?  I'm fine either way.


Thanks for looking into this.
I had experimented with some of this as a next step, but didn't finish it.
Your general approach seems correct.

Clint
-- 

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 

Re: [cmake-developers] [PATCH] Improve encoding handling on Windows

[clinton]

- On Jul 1, 2016, at 8:41 AM, Mike Gelfand mike...@mikedld.com wrote:

> On 07/01/2016 05:12 PM, Ben Boeckel wrote:
>> On Fri, Jul 01, 2016 at 16:44:32 +0300, Dāvis Mosāns wrote:
>>> 2. change GetEnv to return std::unique_ptr which will be
>>>   automatically deleted once out of scope and we still can check if there
>>>   wasn't such env if it's empty.
>> Hrm. I'd rather use std::optional than relying on implicit nullptr
>> semantics.
> 
> Since you already have "bool SystemTools::GetEnv(const char* key,
> std::string& result)", another option would be to use it everywhere and
> maybe introduce something like "bool SystemTools::HasEnv(const char*
> key)" for those several cases where you only need to check the existence.
> 

+1

- Clint
-- 

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

Re: [cmake-developers] Questions about coding conventions

[clinton]

- On Jun 14, 2016, at 8:09 AM, Daniel Pfeifer dan...@pfeifer-mail.de wrote:

> On Tue, Jun 14, 2016 at 3:14 PM, Brad King  wrote:
>> On 06/13/2016 10:16 AM, Brad King wrote:
 Can't `std::ifstream` and `std::ofstream` be used directly? It seams
 that kwsys does some workarounds
>>>
>>> Yes, std::{o,f}stream can be used directly.
>>
>> On second thought, std::{i,o}fstream should not be used to open files.
>> The cmsys::{i,o}fstream interfaces are not about compatibility, they
>> are about opening files on Windows using the wide character APIs by
>> converting from UTF-8 to UCS-2.
> 
> I see.
> 
> There are a few uses of std::{i,o}fstream. I guess we should migrate
> them all to kwsys.

Yes.  Thanks.
cmsys::{i,o}fstream is to support additional filenames on Windows by not using 
obsolete ANSI apis.

Clint
-- 

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

Re: [cmake-developers] Productbuild CPack generator

[clinton]

On Jun 6, 2016 7:28 AM, Brad King <brad.k...@kitware.com> wrote:
>
> On 06/02/2016 12:03 PM, clin...@elemtech.com wrote: 
> > I have submitted a productbuild generator this morning. 
>
> Clinton, I see you followed up with some fixups to the topic and have 
> now squashed it down.  I've extended the revised topic with release notes: 
>
> Help: Add notes for 'productbuild' topic 
> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=63e5eb5f 
>
> Is the topic ready for 'master' now? 
Yes, I think it's ready.
Thanks,
Clint

-- 

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

Re: [cmake-developers] Productbuild CPack generator

[clinton]

Hi Harry, 

I have submitted a productbuild generator this morning. 
https://cmake.org/gitweb?p=cmake.git;a=commit;h=b746bd5c 

Its capabilities should be about equal to the PackageMaker generator. The code 
for distribution.xml is shared between PackageMaker and productbuild. 
The preflight/postflight script support should be better with this new 
generator than with PackageMaker. 

Please do help with testing and development. 

>From your other email with suggestions, I have implemented the --version 
>parameter for pkgbuild and product build, and fixed finding the pkgutil and 
>productbuild exectuables. 

I tried a user controlled setting for --install-location but ran into some 
difficulty getting cmCPackGenerator to cooperate. 
I decided to leave --install-location as '/' and do not see any negative 
effects of that. That can be revisited, of course. 

Does anyone here know if we have test coverage already for some cpack 
generators where we create a package, then unpack it to verify the results? 

Clint 

- On Jun 2, 2016, at 6:21 AM, Harry Mallon  wrote: 

> I found this on the other mailing list but it isn't getting much love. Is 
> anyone
> out there who can tell me how far from being merged in it is? It would really
> reduce the hackery in our cmake scripts here and I am happy to contribute to
> it's testing and development if I get some time.
> http://public.kitware.com/pipermail/cmake/2016-May/063493.html

> Harry

> Harry Mallon

> CODEX | Software Engineer

> 60 Poland Street | London | England | W1F 7NT

> E ha...@codexdigital.com | T +44 203 7000 989

> Website | Facebook | Twitter

> --

> 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

Re: [cmake-developers] CMake 3.5.2 conflates OSX SDK version with target deployment

[clinton]

- On May 25, 2016, at 12:38 PM, Brad King brad.k...@kitware.com wrote:

> On 05/25/2016 02:31 PM, Sean McBride wrote:
>> CMake should probably default to the newest SDK (which is what Xcode does).
>> I don't see a reason to default to an SDK "matching" the deployment target,
>> in fact it's problematic these days since they no longer provider older SDKs.
>> 
>> Of course, finding the "newest" SDK will be a bit fragile, since they get
>> moved/renamed all the time, but I guess that's something CMake always has to
>> deal with anyway.
> 
> This is all worked out in Modules/Platform/Darwin-Initialize.cmake:
> 
>  
> https://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/Platform/Darwin-Initialize.cmake;hb=v3.5.2#l38
> 
> The logic there has evolved over the years and is pretty solid now.
> It has good default behavior, and anyone that really needs a specific
> combination can specify it themselves explicitly.
> 
> The only question in this thread is whether the warning about the SDK
> and deployment target version not matching exactly is ever useful:
> 
> https://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/Platform/Darwin-Initialize.cmake;hb=v3.5.2#l97
> 
> Note that this is separate from the version compatibility check here:
> 
> https://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/Platform/Darwin.cmake;hb=v3.5.2#l67
> 
> which is an error.
> 
> -Brad

I don't think we need the warning.
A different version for deployment target and SDK is common.

Here
https://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/Platform/Darwin-Initialize.cmake;hb=v3.5.2#l81
the found SDK is equal or newer to the deployment target, which is good.

Clint
-- 

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

Re: [cmake-developers] fixup_bundle with @loader_path

[clinton]

- On Jan 14, 2016, at 6:48 AM, Brad King brad.k...@kitware.com wrote:

> On 01/13/2016 01:38 AM, Simon Wells wrote:
>> it kept saying that @loader_path/libboost_chrono-mt.dylib was not found
> 
> It looks like this was now reported here with a patch:
> 
> https://cmake.org/Bug/view.php?id=15918
> 
> We already handle @executable_path, so @loader_path should be handled in
> a similar way but we need to make sure enough information is passed to
> know the loader path.
> 

As far as I know, the information needed is already available, so my initial 
guess is that we don't need any significant re-engineering.

Simon,
Would you happen to have a simple example showing the problem without boost, 
that would be easy to replicate?  That could become the basis for a test.

Clint
-- 

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

Re: [cmake-developers] Create subdirectories in Resource directory for Frameworks and Application bundle.

[Clinton Stimpson]

On Friday, December 11, 2015 08:46:56 PM Bartosz Kosiorek wrote:
> Hi
> 
> To enable iOS build, I'm using following settings in CMakeLists.txt:
> 
> 
> set(APPLE_PLATFORM "iphonesimulator")
> set(CMAKE_OSX_SYSROOT
> "/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platf
> orm/Developer/SDKs/iPhoneSimulator.sdk")
 set(CMAKE_C_FLAGS "-isysroot
> ${CMAKE_OSX_SYSROOT} -mios-version-min=7.0") set(CMAKE_CXX_FLAGS "-isysroot
> ${CMAKE_OSX_SYSROOT} -mios-version-min=7.0") 
> Do you think it should be documented?
> 
> Where is the good place to do so?
> Maybe somewhere here:
> https://cmake.org/cmake/help/v3.4/variable/CMAKE_OSX_SYSROOT.html
> 
> 
> 
> What do you think?
> 

I'm thinking it'll be better to integrate that at the Modules/Platform/ level.
For example, there is code in Darwin-Clang.cmake for the -mmacosx-version-min 
flag.

Perhaps iOS can be toggled with CMAKE_GENERATOR_PLATFORM.
Brad, what do you think?

Or maybe toggled with CMAKE_OSX_SYSROOT, and if the SDK is pointing to another 
platform than OS X, we can switch between
-mios-version-min= and -mmacosx-version-min=

Clint


> ​
> 
> 
> 
> From: clin...@elemtech.com <clin...@elemtech.com>
> Sent: Friday, December 11, 2015 8:21 PM
> To: Bartosz Kosiorek
> Cc: Bartosz Kosiorek; cmake-developers; Gregor Jasny
> Subject: Re: [cmake-developers] Create subdirectories in Resource directory
> for Frameworks and Application bundle.
 
> 
> 
> - On Dec 11, 2015, at 11:44 AM, Bartosz Kosiorek <gan...@poczta.onet.pl>
> wrote:
 Hi
> 
> Because there is difference between OS X and iOS Bundles directory structure
> (see: Apple specification
> https://developer.apple.com/library/mac/documentation/CoreFoundation/Concep
> tual/CFBundles/BundleTypes/BundleTypes.html), in trunk (In CMake 3.5)
> RESOURCE property create corresponding directory structure. I have already
> fix that with:
> https://public.kitware.com/Bug/view.php?id=15848
> Ok.  I hadn't been following all your work.
> Also, I didn't see a toggle in the CMake code you sent to choose an iOS
> bundle instead of OS X bundles.  How is that toggled?
 
> So RESOURCE gives you a level of abstraction:
> For OSX:
> it will create "Resource" directory
> 
> For iOS it will create "flat" directory structure.
> 
> In your example "Resource" directory will be created in both cases (for OSX
> and iOS).
 Which is wrong:
> For OSX: it should  create "Resource" directory
> For iOS it will create "flat" directory structure.
> 
> I could provide patch to fix that issue, if you agree with that.
> What do you think about that?
> Do you think the same should be applied to "Headers"?
> 
> I think the abstraction seems reasonable, as well as what you are proposing.
>  However, I'm not an Apple guru.
 I wonder if there are other Apple experts
> that can weigh in this if better feedback is needed. 
> Clint
> 
> 
> Best Regards
> Bartosz
> 
> 
> 
> 2015-12-11 19:06 GMT+01:00 Clinton Stimpson
> <clin...@elemtech.com<mailto:clin...@elemtech.com>>:
 
> 
> On Friday, December 11, 2015 05:01:41 PM Bartosz Kosiorek wrote:
> 
> > Thanks Clint
> >
> >
> >
> > Unfortunately MACOSX_PACKAGE_LOCATION is not working correctly with
> > RESOURCE
 property. For every resource which is marked as RESOURCE, will
> > be placed in root "Resources" directory.
> >
> >
> >
> > The CMake code below create following directory structure for OS X:
> >
> >
> >
> > ── mul.framework
> > 
> > ├── Headers -> Versions/Current/Headers
> > ├── Resources -> Versions/Current/Resources
> > ├── Versions
> > │   ├── A
> > │   │   ├── Headers
> > │   │   │   └── mul.h
> > │   │   ├── Modules
> > │   │   │   └── module.modulemap
> > │   │   ├── Resources
> > │   │   │   ├── Info.plist
> > │   │   │   ├── mulres.txt
> > │   │   │   ├── pl.txt
> > │   │   │   └── resourcefile.txt
> > │   │   ├── lang
> > │   │   │   └── en.txt
> > │   │   └── mul
> > │   └── Current -> A
> > └── mul -> Versions/Current/mul
> >
> >
> >
> >
> > As you can see eveything which is marked as "RESOURCE" will be placed in
> > Versions/A/ directory My expectation will be that lang/pl.txt and
> > lang/en.txt should be in Resources/lang/ directory. Here is complete
> > directory structure:
> >
> >
> >
> > ── mul.framew

Re: [cmake-developers] Create subdirectories in Resource directory for Frameworks and Application bundle.

[Clinton Stimpson]

On Friday, December 11, 2015 05:01:41 PM Bartosz Kosiorek wrote:
> Thanks Clint
> 
> Unfortunately MACOSX_PACKAGE_LOCATION is not working correctly with RESOURCE
> property. For every resource which is marked as RESOURCE, will be placed in
> root "Resources" directory.
> 
> The CMake code below create following directory structure for OS X:
> 
> ── mul.framework
> ├── Headers -> Versions/Current/Headers
> ├── Resources -> Versions/Current/Resources
> ├── Versions
> │   ├── A
> │   │   ├── Headers
> │   │   │   └── mul.h
> │   │   ├── Modules
> │   │   │   └── module.modulemap
> │   │   ├── Resources
> │   │   │   ├── Info.plist
> │   │   │   ├── mulres.txt
> │   │   │   ├── pl.txt
> │   │   │   └── resourcefile.txt
> │   │   ├── lang
> │   │   │   └── en.txt
> │   │   └── mul
> │   └── Current -> A
> └── mul -> Versions/Current/mul
> 
> 
> As you can see eveything which is marked as "RESOURCE" will be placed in
> Versions/A/ directory My expectation will be that lang/pl.txt and
> lang/en.txt should be in Resources/lang/ directory. Here is complete
> directory structure:
> 
> ── mul.framework
> ├── Headers -> Versions/Current/Headers
> ├── Resources -> Versions/Current/Resources
> ├── Versions
> │   ├── A
> │   │   ├── Headers
> │   │   │   └── mul.h
> │   │   ├── Modules
> │   │   │   └── module.modulemap
> │   │   ├── Resources
> │   │   │   ├── Info.plist
> │   │   │   ├── mulres.txt
> │   │   │   ├── lang
> │   │   │   │   └── pl.txt
> │   │   │   │   └── en.txt
> │   │   │   └── resourcefile.txt
> │   │   ├── lang
> │   │   │   └── en.txt
> │   │   └── mul
> │   └── Current -> A
> └── mul -> Versions/Current/mul
> 
> 
> What do you think about that?
> 
> Here is the source code:
> 
> set_property(SOURCE module.modulemap
>   PROPERTY MACOSX_PACKAGE_LOCATION "Modules")
> 
> set_property(
>   SOURCE lang/en.txt lang/pl.txt
>   PROPERTY MACOSX_PACKAGE_LOCATION "lang")
> 
> set(RESLIST
> mulres.txt
> lang/pl.txt
> resourcefile.txt
> )
> 
> add_library(mul SHARED
> mul.c
> mul.h
> module.modulemap
> lang/pl.txt
> lang/en.txt
> resourcefile.txt
> mulres.txt)
> 
> # Create an iOS Framework bundle
> set_target_properties(mul PROPERTIES
>   FRAMEWORK TRUE
>   MACOSX_FRAMEWORK_IDENTIFIER org.cmake.mul
>   MACOSX_FRAMEWORK_SHORT_VERSION_STRING 42
>   MACOSX_FRAMEWORK_BUNDLE_VERSION 3.2.10
>   XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY "iPhone Developer"
>   PUBLIC_HEADER mul.h
>   RESOURCE "${RESLIST}"
> )


Here is a CMakeLists.txt that will give you the desired layout.
I also see that MACOSX_PACKAGE_LOCATION doesn't work with RESOURCE.


set_property(SOURCE module.modulemap
  PROPERTY MACOSX_PACKAGE_LOCATION "Modules")

set_property(
  SOURCE lang/pl.txt lang/en.txt
  PROPERTY MACOSX_PACKAGE_LOCATION "Resources/lang")

set(RESLIST 
mulres.txt
resourcefile.txt
)

add_library(mul SHARED 
mul.c
mul.h
module.modulemap
lang/pl.txt
lang/en.txt
resourcefile.txt
mulres.txt)

# Create an iOS Framework bundle 
set_target_properties(mul PROPERTIES
  FRAMEWORK TRUE
  MACOSX_FRAMEWORK_IDENTIFIER org.cmake.mul
  MACOSX_FRAMEWORK_SHORT_VERSION_STRING 42
  MACOSX_FRAMEWORK_BUNDLE_VERSION 3.2.10
  XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY "iPhone Developer"
  PUBLIC_HEADER mul.h
  RESOURCE "${RESLIST}"
)


Now I'm wondering what does the RESOURCE target property do that 
MACOSX_PACKAGE_LOCATION doesn't already support?

Clint
-- 

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

Re: [cmake-developers] Create subdirectories in Resource directory for Frameworks and Application bundle.

[clinton]

- On Dec 11, 2015, at 11:44 AM, Bartosz Kosiorek <gan...@poczta.onet.pl> 
wrote: 

> Hi

> Because there is difference between OS X and iOS Bundles directory structure
> (see: Apple specification
> https://developer.apple.com/library/mac/documentation/CoreFoundation/Conceptual/CFBundles/BundleTypes/BundleTypes.html
> ),
> in trunk (In CMake 3.5) RESOURCE property create corresponding directory
> structure.
> I have already fix that with:
> https://public.kitware.com/Bug/view.php?id=15848

Ok. I hadn't been following all your work. 
Also, I didn't see a toggle in the CMake code you sent to choose an iOS bundle 
instead of OS X bundles. How is that toggled? 

> So RESOURCE gives you a level of abstraction:
> For OSX:
> it will create "Resource" directory

> For iOS it will create "flat" directory structure.

> In your example "Resource" directory will be created in both cases (for OSX 
> and
> iOS).
> Which is wrong:
> For OSX: it should create "Resource" directory
> For iOS it will create "flat" directory structure.

> I could provide patch to fix that issue, if you agree with that.
> What do you think about that?
> Do you think the same should be applied to "Headers"?

I think the abstraction seems reasonable, as well as what you are proposing. 
However, I'm not an Apple guru. 
I wonder if there are other Apple experts that can weigh in this if better 
feedback is needed. 

Clint 

> Best Regards
> Bartosz

> 2015-12-11 19:06 GMT+01:00 Clinton Stimpson < clin...@elemtech.com > :

>> On Friday, December 11, 2015 05:01:41 PM Bartosz Kosiorek wrote:
>> > Thanks Clint

>> > Unfortunately MACOSX_PACKAGE_LOCATION is not working correctly with 
>> > RESOURCE
>> > property. For every resource which is marked as RESOURCE, will be placed in
>> > root "Resources" directory.

>> > The CMake code below create following directory structure for OS X:

>> > ── mul.framework
>> > ├── Headers -> Versions/Current/Headers
>> > ├── Resources -> Versions/Current/Resources
>> > ├── Versions
>> > │ ├── A
>> > │ │ ├── Headers
>> > │ │ │ └── mul.h
>> > │ │ ├── Modules
>> > │ │ │ └── module.modulemap
>> > │ │ ├── Resources
>> > │ │ │ ├── Info.plist
>> > │ │ │ ├── mulres.txt
>> > │ │ │ ├── pl.txt
>> > │ │ │ └── resourcefile.txt
>> > │ │ ├── lang
>> > │ │ │ └── en.txt
>> > │ │ └── mul
>> > │ └── Current -> A
>> > └── mul -> Versions/Current/mul


>> > As you can see eveything which is marked as "RESOURCE" will be placed in
>> > Versions/A/ directory My expectation will be that lang/pl.txt and
>> > lang/en.txt should be in Resources/lang/ directory. Here is complete
>> > directory structure:

>> > ── mul.framework
>> > ├── Headers -> Versions/Current/Headers
>> > ├── Resources -> Versions/Current/Resources
>> > ├── Versions
>> > │ ├── A
>> > │ │ ├── Headers
>> > │ │ │ └── mul.h
>> > │ │ ├── Modules
>> > │ │ │ └── module.modulemap
>> > │ │ ├── Resources
>> > │ │ │ ├── Info.plist
>> > │ │ │ ├── mulres.txt
>> > │ │ │ ├── lang
>> > │ │ │ │ └── pl.txt
>> > │ │ │ │ └── en.txt
>> > │ │ │ └── resourcefile.txt
>> > │ │ ├── lang
>> > │ │ │ └── en.txt
>> > │ │ └── mul
>> > │ └── Current -> A
>> > └── mul -> Versions/Current/mul


>> > What do you think about that?

>> > Here is the source code:

>> > set_property(SOURCE module.modulemap
>> > PROPERTY MACOSX_PACKAGE_LOCATION "Modules")

>> > set_property(
>> > SOURCE lang/en.txt lang/pl.txt
>> > PROPERTY MACOSX_PACKAGE_LOCATION "lang")

>> > set(RESLIST
>> > mulres.txt
>> > lang/pl.txt
>> > resourcefile.txt
>> > )

>> > add_library(mul SHARED
>> > mul.c
>> > mul.h
>> > module.modulemap
>> > lang/pl.txt
>> > lang/en.txt
>> > resourcefile.txt
>> > mulres.txt)

>> > # Create an iOS Framework bundle
>> > set_target_properties(mul PROPERTIES
>> > FRAMEWORK TRUE
>> > MACOSX_FRAMEWORK_IDENTIFIER org.cmake.mul
>> > MACOSX_FRAMEWORK_SHORT_VERSION_STRING 42
>> > MACOSX_FRAMEWORK_BUNDLE_VERSION 3.2.10
>> > XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY "iPhone Developer"
>> > PUBLIC_HEADER mul.h
>> > RESOURCE "${RESLIST}"
>> > )

>> Here is a CMakeLists.txt that will 

Re: [cmake-developers] [PATCH] Qt4Macros generate resources with same file name

[Clinton Stimpson]

On Tuesday, November 24, 2015 11:01:27 AM Joseph Shen wrote:
> Dear CMake developers:
> 
> Please view attached small patch that try to fix Qt4Macros generate
> resources with same file name error.
> 
> Right now, in the CMake main branch, using cmake with Qt4 library
> add resources project can be done like this:
> 
>  qt4_add_resources(app_source_res res_a.qrc)
>  qt4_add_resources(app_source_res res_b.qrc)
> 
> and above two line added two resource file, but if we try to add resource
> file with same name, a very subtle error will happen: only one file will
> be compile the as resources, and the other was totally ignored.
> 
> In some big projects, using the same file name as resource file name
> can be very common, especially when we using multi cmake files try
> to make the whole project into small ones, in each cmake files someone
> maybe just using the same resources file name like res.qrc which is
> located in the sub module resources folder.
> 
>qt4_add_resources(app_source_res res.qrc)
> 
> so, if they try to do this, and in the last add ${app_source_res} to the
> dependency list using:
> 
>   add_executable(project_name ${app_source_res} ...)
> 
> but in reality they just add one resources file, but CMake do not report
> any error or warning.
> 
> From the source of Qt4Macros we can see:
> 
> line 211:   get_filename_component(outfilename ${it} NAME_WE)
> line 244:   ARGS ${rcc_options} -name ${outfilename} -o ${outfile} ${infile}
> 
> 
> became we just using NAME_WE as the output file, if two files with same
> file name, one will overwrite the other, and this is the reason why the
> error
> will happen.
> 
> To fix this, I view the whole Qt4Macros source file, find a function
> QT4_MAKE_OUTPUT_FILE already exist to do something just what we
> need. so I work out a patch add two line code and remove two, and it works
> good to me, and I think this might fix the problem.
> 
> Please view this patch, thanks :)


Back on list with a more concrete example, and also to prevent others from 
merging this patch, because I don't think this patch should be accepted.  The 
random string breaks using the Q_INIT_RESOURCE() macro.


For example:
===
project(qrc)

find_package(Qt4)
include(${QT_USE_FILE})

qt4_add_resources(qrc_srcs ${CMAKE_CURRENT_SOURCE_DIR}/my.qrc)

add_library(qrc STATIC ${qrc_srcs})

add_executable(main main.cpp)
target_link_libraries(main qrc)


main.cpp has:
int main()
{
  Q_INIT_RESOURCE(my);
}

With the patch applied, I now get the link error:

main.cpp:(.text+0x5): undefined reference to `qInitResources_my()'

"my" comes from the basename of my.qrc, and is the name used for the resource.
With CMake generating a random name, there would be no way to reference that 
name when calling Q_INIT_RESOURCE.

I would prefer allowing the caller to pass in an alternate -name option for 
rcc, as I said in my first review.  With that, the caller would be able to pass 
a random string.

Clint

-- 

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

Re: [cmake-developers] CPack/NSIS is broken after extended length paths fix

[Clinton Stimpson]

On Monday, September 21, 2015 12:28:37 PM Dmitry Kochkin wrote:
>  Hi Clint,
> 
> >>Actually it's even worse because in current master HEAD I can see that
> >>INST_DIR is empty in generated project: !define INST_DIR ""
> >>(not sure if that's caused by your change)
> >
> >Interesting... Do you know why this happens?  How is this problem related
> >to extended paths (with the \\?\ prefix)?  Do you have an example to
> >demonstrate this problem? That was my mistake, please ignore.>
> >>I've figured out that NSIS was not going to fix this (see 
> >>http://sourceforge.net/p/nsis/feature-requests/241/ )>
> >Maybe they'll accept a patch to fix it there?  Was there any effort to fix
> >it there?
> In the URL I've put they claim you should just use "\\?\" in your NSIS
> project. I guess it's also possible to fix NSIS, but we cannot rely that
> user have latest NSIS.

Using "\\?\" in a NSIS project is a workaround, not a fix.
If a workaround is put into CMake, then you are relying on the latest CMake, 
right?


> >>I've made a small patch to NSIS generator and template to put infamous
> >>\\?\ there.
> >>
> >>I can send directly to you as I guess you know more about these parts of
> >>code.>
> >You can send your patch to this mailing list for review.
> 
> Patch attached. It's a bit hacky, more fixing symptoms I guess. The purpose
> is only to demonstrate the idea. Let me know if it can be done in better
> way.

Yes, it fixes symptoms.  The correct and robust way to fix this is to fix NSIS.

I have concerns with this patch:

1. Are the paths cleaned before placed into the NSIS template?  Only clean 
paths can be prepended with \\?\.  For example, these paths may not contain 
"." or "../" in them.

2. This patch can break UNC paths.  UNC paths must be prepended with a "\\?
\UNC\" prefix instead of "\\?\".  If CPACK_TEMPORARY_DIRECTORY is a UNC path, 
this patch breaks it.

3. For the uninstall code put into the NSIS template, how do you know whether 
INSTDIR is a UNC path or not?  INSTDIR is determined by the end-user when 
installing the software.  Blindly prepending "\\?\" may not work all the time.

Clint
-- 

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

Re: [cmake-developers] CPack/NSIS is broken after extended length paths fix

[clinton]

- On Sep 18, 2015, at 6:07 AM, Dmitry Kochkin <co...@mail.ru> wrote: 

> Hi Clinton,

> I was looking into an issue that we have in CMake on Windows with extended 
> paths
> and later on realized that you've fixed it.
> However I've realized that you fixed it only in cmSystemTools, which fixes 
> e.g.
> INSTALL, but does not fix cpack.
Yes, I was fixing the 'install' to work with paths > 260 characters, and was 
using the cpack archive generator at the time. 
With the path to the build tree, plus the "_CPackPackage/", some of these 
paths can become quite long. 

> Actually it's even worse because in current master HEAD I can see that 
> INST_DIR
> is empty in generated project:
> !define INST_DIR ""
> (not sure if that's caused by your change)
Interesting... Do you know why this happens? How is this problem related to 
extended paths (with the \\?\ prefix)? Do you have an example to demonstrate 
this problem? 

> I've figured out that NSIS was not going to fix this (see
> http://sourceforge.net/p/nsis/feature-requests/241/ )
Maybe they'll accept a patch to fix it there? Was there any effort to fix it 
there? 

> I've made a small patch to NSIS generator and template to put infamous \\?\
> there.

> I can send directly to you as I guess you know more about these parts of code.

You can send your patch to this mailing list for review. 

Clint 
-- 

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

Re: [cmake-developers] [PATCH] FindPythonLibs patches for version searching and frameworks

[Clinton Stimpson]

On Wednesday, September 16, 2015 11:04:23 PM David Gobbi wrote:
> On Wed, Sep 16, 2015 at 9:41 AM, Brad King  wrote:
> > On 09/16/2015 11:39 AM, Brad King wrote:
> > > On 09/16/2015 10:00 AM, David Gobbi wrote:
> > >> this new patch only changes the search for the include dirs.
> > > 
> > > Thanks.  Rather than calling find_path twice, the first call could
> > > just use HINTS instead of PATHS.  HINTS are meant for this use case:
> > > searching paths detected from the system in some manner.  They are
> > > searched before the generic system and environment paths.  Does that
> > > work for your use case?
> > > 
> > > Also, why does the second call not use the same list of suffixes?
> > 
> > Meanwhile I split out the OS X framework path fix:
> >  FindPythonLibs: Fix OS X framework include directory search path
> >  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ea2db3bb
> > 
> > Please check that it looks correct on its own.
> 
> Thanks, looks fine.  I've modified my patch so that it only calls find_path
> once.
> It uses HINTS to search for the includes in the same prefix as where the
> library
> was found, which is probably the best place to start.  I've left the
> framework dirs
> in PATHS because we don't necessarily want them to have priority, we just
> want to have them in the search path.
> 
>  - David


Hi,

I did a quick test to see if my issue has been resolved.

I have a CMakeLists.txt file with just:
FIND_PACKAGE(PythonInterp REQUIRED)
FIND_PACKAGE(PythonLibs ${PYTHON_VERSION_STRING} REQUIRED)


And I get this error:
  Could NOT find PythonLibs: Found unsuitable version "2.7.2", but required
  is at least "2.7.5" (found /usr/lib/libpython2.7.dylib)


The problem I have is that I get a python executable and python library from a 
system location, and headers from the SDK, which aren't the exact same 
version.

//Path to a program.
PYTHON_EXECUTABLE:FILEPATH=/usr/bin/python

//Path to a file.
PYTHON_INCLUDE_DIR:PATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/System/Library/Frameworks/Python.framework/Headers

//Path to a library.
PYTHON_LIBRARY:FILEPATH=/usr/lib/libpython2.7.dylib


Is that related to issues you are addressing here?

Thanks,
Clint

-- 

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

Re: [cmake-developers] [PATCH] FindPythonLibs patches for version searching and frameworks

[Clinton Stimpson]

On Thursday, September 17, 2015 12:54:26 PM Brad King wrote:
> On 09/17/2015 12:42 PM, David Gobbi wrote:
> > Okay, Clinton.  Now you've made me paranoid that I should be prepending
> > the value of CMAKE_OSX_SYSROOT before the prefix if it isn't already
> > part of the prefix.  I don't want to ignore CMAKE_OSX_SYSROOT if it has
> > been set, but unfortunately I don't know all the details of how
> > find_library uses CMAKE_OSX_SYSROOT internally.
> 
> Individual find modules and find_ calls should not have to worry
> about that.  See Modules/Platform/Darwin.cmake for use of the
> CMAKE_OSX_SYSROOT to set CMAKE_SYSTEM_PREFIX_PATH.

Yeah.

However, it does bother me that it found includes from the SDK and a library 
under /usr/lib.

For example, if I use the 10.6 SDK on OS X 10.7, it appears that it would find 
/usr/lib/libpython.2.7.dylib and headers for python 2.6 under the 10.6 SDK.

I guess I can put this in the bug tracker.

Clint
-- 

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

Re: [cmake-developers] "Inconsistent sizeofcmds" on Mac

[Clinton Stimpson]

On Thursday, September 17, 2015 11:18:06 PM Mike Gelfand wrote:
> Hello everyone,
> 
> I’m using cmake 3.3.1 on Mac 10.10.4. I’m building an executable target on
> Mac with the following settings:
> 
>   CMAKE_OSX_ARCHITECTURES = i386;x86_64
>   CMAKE_OSX_DEPLOYMENT_TARGET = 10.5
>   CMAKE_OSX_SYSROOT = .../MacOSX10.10.sdk
> 
> Right after build, executable is runnable (from inside the binary dir) and
> everything’s fine. But once I do `make install`, the executable in the
> install prefix starts giving out errors:
> 
>   % otool -L /install/prefix/myexecutable
>   ...
>   Inconsistent sizeofcmds
> 
> Adding INSTALL_RPATH target property (the executable depends on a number of
> shared libraries) results in another error during `make install`, although
> the command isn’t failing:
> 
>   % make install
>   ...
>   -- Installing: /tmp/prefix/usr/local/rmmagent/rmmagentd
>   .../install_name_tool: for architecture x86_64 object:
> /install/prefix/myexecutable malformed object (inconsistent sizeofcmds
> field in mach header) ...
> 
> What helps is either a) setting BUILD_WITH_INSTALL_RPATH target property to
> ON (with obvious inconvenience while debugging) or b) making the executable
> non-fat (i.e. setting architecture to either i386 or x86_64, but not both;
> which is not what I want in the end).
> 
> Is this a defect in cmake? Is there anything I can do to work this around?

I'm not sure where the defect is, or how to work around it, without getting 
more details.

I've seen problems similar to this, but not exactly the same as what you are 
seeing.  What I have seen before was discussed here:
http://public.kitware.com/pipermail/cmake/2014-October/058868.html

Perhaps you can go over that and see if it applies to you.
In that case, the bug was in install_name_tool, and there was a simple test 
case to demonstrate the bug.  Apple reported that it was fixed in Xcode 6.3.

Clint
-- 

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

Re: [cmake-developers] Modules/GetPrequisites.cmake issues

[Clinton Stimpson]

On Monday, August 03, 2015 10:22:18 AM Brad King wrote:
 On 07/30/2015 10:56 AM, Brad King wrote:
  Thanks!  Applied:
 Those patches exposed a bug in FindMPI, so I fixed that and
 rebased the other changes on it:
 
  FindMPI: Drop unnecessary and incorrect use of GetPrerequisites
  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1c46b6ae
 
  GetPrerequisites: Add error checks for execute_process() calls
  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=afb674ab
 
  GetPrerequisites: Optionally filter objdump output for speed
  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5d0a8b1a
 
 -Brad


Thanks.
I believe that also fixes

http://www.cmake.org/Bug/view.php?id=13351

Clint
-- 

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

Re: [cmake-developers] [PATCH 3/3] FindQt4: document cross compilation

[Clinton Stimpson]

On Thursday, July 30, 2015 10:56:02 AM Brad King wrote:
 On 07/30/2015 09:29 AM, Pascal Bach wrote:
  CMAKE_FIND_ROOT_PATH_MODE would then need to be extended to support
  something like NATIVE and TARGET that one could use to choose where
  to look for files.
  This way every find_* call could explicitly tell if it wants a host
  or a target version.
 
 Are you proposing new keyword arguments to find_* commands to specify
 this?  The problem is that find modules don't necessarily know which
 kind of binary the application wants.  That is why we have the
 CMAKE_FIND_ROOT_PATH_MODE_type variables.
 
 The existing CMAKE_FIND_ROOT_PATH* and CMAKE_SYSROOT options have been
 sufficient for most packages for a long time.  We regularly get
 complaints that FindPythonLibs does not ask the python executable
 where to get its libraries, and our answer every time is that it is
 wrong to do that for cross compiling.  FindQt4 is making that mistake,
 and that is the cause of these troubles.
 
 FindQt4 should be taught not to ask qmake for anything when cross
 compiling.

FindQt4 supports 2 use cases when cross compiling.

1. One Qt installation with a mix of native and non-native files.

2. Two Qt installations, one native and one non-native.  In this case, qmake 
may still be queried to find other tools, but CMAKE_FIND_ROOT_PATH is used to 
find the non-native includes and libraries.

The second case is what you are asking for, right?

This why I previously suggested changing 
from
SET(CMAKE_FIND_ROOT_PATH /sysroot/arm ...)
to 
SET(CMAKE_FIND_ROOT_PATH /sysroot/arm/usr ...)

Because its a find root, not a sysroot.

Clint

-- 

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

Re: [cmake-developers] [PATCH 3/3] FindQt4: document cross compilation

[Clinton Stimpson]

On Wednesday, July 29, 2015 04:59:57 PM Pascal Bach wrote:
 Hi Clint
 
 Am 29.07.2015 um 16:47 schrieb Clinton Stimpson:
  On Wednesday, July 29, 2015 04:05:41 PM Pascal Bach wrote:
  Hi Clint
  
  Am 29.07.2015 um 15:45 schrieb Clinton Stimpson:
  Hi Pascal,
  
  Thanks for the patches.
  
  Can you share with us why setting CMAKE_FIND_ROOT_PATH does not work, or
  how this new method compares?
  
  For example, in the toolchain file:
  SET(CMAKE_FIND_ROOT_PATH  /path/to/Qt ...)
  
  The problem is how FindQt4 does find the locations using qmake.
  
  let's assume there are two sysroots one is /sysroots/x86_64 which
  contains
  binaries usable on the host machine, and there is /sysroots/arm which
  contains libraries for the target system. this are both set via:
  set( CMAKE_FIND_ROOT_PATH /sysroots/arm /sysroots/x86_64)
  set( CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY )
  set( CMAKE_FIND_ROOT_PATH_MODE_PROGRAM ONLY )
  set( CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY )
  set( CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY )
  
  Yes, this concern of 2 sysroots has been brought up before.  Thanks for
  addressing this.
  
  Here is what happens when only setting CMAKE_FIND_ROOT_PATH:
  
  1. FindQt4 is trying to find the qmake executable. As there is no qmake
  in
  /sysroots/arm (it would not be runnable on the host) it will find qmake
  from the /sysroots/x86_64 directory. 2. FindQt4 is asking qmake for the
  path to the Qt installation. As the qmake found is the one from
  /sysroots/x86_64 it will point to the libraries from /sysroots/x86_64
  which
  will obviously not run on arm!
  
  Currently I didn't find a way to override this behaviour of FindQt4,
  except
  by setting all the variables usually set by FindQt4 manually. It is
  usually
  accepted to set some variables manually when doing cross compilation.
  With
  this patchset I tried to reduce this variable to a minumum and let
  FindQt4
  figure out the rest.
  
  The minimum variables required with the patch are:
  
  QT_BINARY_DIR is necessary to find the correct qmake
  QT_LIBRARY_DIR is necessary to find the library directory
  QT_INCLUDE_DIR is necessary to find the include directory (might be
  possible to figure this out from QT_INCLUDE_DIR if some assumptions are
  made) QT_MKSPECS_DIR necessary to have the correct prefixes (E in the
  case of qt4-embedded).
  
  
  I hope my explanation is clear. If there is a better way to achive this
  I'm
  all ears.
  
  I'm fine with this, and don't think it'll conflict with any other use
  cases.
 I don't see a conflict either.
 
  However, I do think we should first document setting CMAKE_FIND_ROOT_PATH,
  then afterwards document the other variables for those users which need
  more control.  Does that sound reasonable?
 
 I'm not sure I understand what you mean.
 I think how to set CMAKE_FIND_ROOT_PATH is already documented in cmake.
  Are you suggesting extending the docuemntation of FindQt4below with a
 paragraph documenting how to work with two sysroots? With an example like
 this?
 
 set( CMAKE_FIND_ROOT_PATH /sysroots/arm /sysroots/x86_64)
 set( CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY )
 set( CMAKE_FIND_ROOT_PATH_MODE_PROGRAM ONLY )
 set( CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY )
 set( CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY )

What I want to avoid is users thinking that what you are proposing overrides 
any other way of finding Qt when cross compiling.

The wording you propose is To find Qt in a cross compile environment set the 
following variables
However there are users for which setting only CMAKE_FIND_ROOT_PATH is enough.
Or setting CMAKE_FIND_ROOT_PATH plus QT_QMAKE_EXECUTABLE is enough.

Brad had a good question in another email.  Can't you set QT_QMAKE_EXECUTABLE?
My guess, is no, because that qmake returns paths under one sysroot.


I just realized something.  Your use case is similar or the same to one I had  
tested FindQt4 with.

Your Qt appears to be prefixed under /sysroot/arm/usr, not /sysroot/arm.

Can you include /sysroot/arm/usr in CMAKE_FIND_ROOT_PATH, then see if FindQt4 
can find your libraries under /sysroot/arm/usr.

Clint

-- 

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

Re: [cmake-developers] [PATCH 3/3] FindQt4: document cross compilation

[Clinton Stimpson]

Hi Pascal,

Thanks for the patches.

Can you share with us why setting CMAKE_FIND_ROOT_PATH does not work, or how 
this new method compares?

For example, in the toolchain file:
SET(CMAKE_FIND_ROOT_PATH  /path/to/Qt ...)

Clint

On Wednesday, July 29, 2015 02:32:48 PM Pascal Bach wrote:
 ---
  Modules/FindQt4.cmake | 20 
  1 file changed, 20 insertions(+)
 
 diff --git a/Modules/FindQt4.cmake b/Modules/FindQt4.cmake
 index 9d03378..64c06e1 100644
 --- a/Modules/FindQt4.cmake
 +++ b/Modules/FindQt4.cmake
 @@ -29,6 +29,26 @@
  #  for a particular executable, set the ``QT4_NO_LINK_QTMAIN`` target
  #  property to ``TRUE`` on the executable.
  #
 +# Cross Compile
 +# ^
 +#
 +# To find Qt in a cross compile environment set the following variables in
 your toolchain file: +#
 +#
 +# ``QT_BINARY_DIR``  = Path to native Qt binary directory
 +# ``QT_LIBRARY_DIR`` = Path to target Qt library directory
 +# ``QT_INCLUDE_DIR`` = Path to target Qt include directory
 +# ``QT_MKSPECS_DIR`` = Path to target Qt mkspecs directory
 +
 +# example
 +#
 +# ::
 +#   set( QT_BINARY_DIR   /sysroots/x86_64-linux/usr/bin )
 +#   set( QT_LIBRARY_DIR  /sysroots/arm/usr/lib )
 +#   set( QT_INCLUDE_DIR  /sysroots/arm/usr/include/qtopia )
 +#   set( QT_MKSPECS_DIR  /sysroots/arm/usr/share/qtopia/mkspecs )
 +#
 +#
  # Qt Build Tools
  # ^^
  #

-- 

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

Re: [cmake-developers] [PATCH 3/3] FindQt4: document cross compilation

[Clinton Stimpson]

On Wednesday, July 29, 2015 04:05:41 PM Pascal Bach wrote:
 Hi Clint
 
 Am 29.07.2015 um 15:45 schrieb Clinton Stimpson:
  Hi Pascal,
  
  Thanks for the patches.
  
  Can you share with us why setting CMAKE_FIND_ROOT_PATH does not work, or
  how this new method compares?
  
  For example, in the toolchain file:
  SET(CMAKE_FIND_ROOT_PATH  /path/to/Qt ...)
 
 The problem is how FindQt4 does find the locations using qmake.
 
 let's assume there are two sysroots one is /sysroots/x86_64 which contains
 binaries usable on the host machine, and there is /sysroots/arm which
 contains libraries for the target system. this are both set via:
 set( CMAKE_FIND_ROOT_PATH /sysroots/arm /sysroots/x86_64)
 set( CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY )
 set( CMAKE_FIND_ROOT_PATH_MODE_PROGRAM ONLY )
 set( CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY )
 set( CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY )

Yes, this concern of 2 sysroots has been brought up before.  Thanks for 
addressing this.

 
 Here is what happens when only setting CMAKE_FIND_ROOT_PATH:
 
 1. FindQt4 is trying to find the qmake executable. As there is no qmake in
 /sysroots/arm (it would not be runnable on the host) it will find qmake
 from the /sysroots/x86_64 directory. 2. FindQt4 is asking qmake for the
 path to the Qt installation. As the qmake found is the one from
 /sysroots/x86_64 it will point to the libraries from /sysroots/x86_64 which
 will obviously not run on arm!
 
 Currently I didn't find a way to override this behaviour of FindQt4, except
 by setting all the variables usually set by FindQt4 manually. It is usually
 accepted to set some variables manually when doing cross compilation. With
 this patchset I tried to reduce this variable to a minumum and let FindQt4
 figure out the rest.
 
 The minimum variables required with the patch are:
 
 QT_BINARY_DIR is necessary to find the correct qmake
 QT_LIBRARY_DIR is necessary to find the library directory
 QT_INCLUDE_DIR is necessary to find the include directory (might be possible
 to figure this out from QT_INCLUDE_DIR if some assumptions are made)
 QT_MKSPECS_DIR necessary to have the correct prefixes (E in the case of
 qt4-embedded).
 
 
 I hope my explanation is clear. If there is a better way to achive this I'm
 all ears.
 

I'm fine with this, and don't think it'll conflict with any other use cases.

However, I do think we should first document setting CMAKE_FIND_ROOT_PATH, then 
afterwards document the other variables for those users which need more 
control.  Does that sound reasonable?

Clint

 Pascal
 
  Clint
  
  On Wednesday, July 29, 2015 02:32:48 PM Pascal Bach wrote:
  ---
  
   Modules/FindQt4.cmake | 20 
   1 file changed, 20 insertions(+)
  
  diff --git a/Modules/FindQt4.cmake b/Modules/FindQt4.cmake
  index 9d03378..64c06e1 100644
  --- a/Modules/FindQt4.cmake
  +++ b/Modules/FindQt4.cmake
  @@ -29,6 +29,26 @@
  
   #  for a particular executable, set the ``QT4_NO_LINK_QTMAIN`` target
   #  property to ``TRUE`` on the executable.
   #
  
  +# Cross Compile
  +# ^
  +#
  +# To find Qt in a cross compile environment set the following variables
  in
  your toolchain file: +#
  +#
  +# ``QT_BINARY_DIR``  = Path to native Qt binary directory
  +# ``QT_LIBRARY_DIR`` = Path to target Qt library directory
  +# ``QT_INCLUDE_DIR`` = Path to target Qt include directory
  +# ``QT_MKSPECS_DIR`` = Path to target Qt mkspecs directory
  +
  +# example
  +#
  +# ::
  +#   set( QT_BINARY_DIR   /sysroots/x86_64-linux/usr/bin )
  +#   set( QT_LIBRARY_DIR  /sysroots/arm/usr/lib )
  +#   set( QT_INCLUDE_DIR  /sysroots/arm/usr/include/qtopia )
  +#   set( QT_MKSPECS_DIR  /sysroots/arm/usr/share/qtopia/mkspecs )
  +#
  +#
  
   # Qt Build Tools
   # ^^
   #

-- 

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

Re: [cmake-developers] Support of codesign

[Clinton Stimpson]

Thanks for providing the patch.
http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=2c50db26

Clint

On Wednesday, March 18, 2015 08:24:36 AM A. Klitzing wrote:
 Ping? :-)
 
  Am 11.03.2015 13:21 schrieb A. Klitzing aklitz...@gmail.com:
  Hi there!
  
  I added another improvement to the codesign feature. Sometimes it is
  helpful to overwrite or pass additional parameters like --timestamp=none
  to codesign.
  But this shouldn't be the default for everyone.
  
  So I added the variable CPACK_BUNDLE_APPLE_CODESIGN_PARAMETER.
  Hope you like it.
  
  Regards
  
André
  
  2015-02-20 16:20 GMT+01:00 Clinton Stimpson clin...@elemtech.com:
  On Friday, February 20, 2015 12:07:55 PM A. Klitzing wrote:
   Hi Clint,
   
   I have another patch to tweak the error output a little bit. If
   codesign
   fails it won't be possible to get the error message of codesign itself.
   That is a little bit confusing because it just fails without an
   understandable reason.
   
   This patch will print the output of codesign if it fails.
  
  Thanks.
  
  http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=7b582d1
  
  Clint

-- 

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

Re: [cmake-developers] Support of codesign

[Clinton Stimpson]

On Friday, February 20, 2015 12:07:55 PM A. Klitzing wrote:
 Hi Clint,
 
 I have another patch to tweak the error output a little bit. If codesign
 fails it won't be possible to get the error message of codesign itself.
 That is a little bit confusing because it just fails without an
 understandable reason.
 
 This patch will print the output of codesign if it fails.
 

Thanks.

http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=7b582d1

Clint
-- 

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

Re: [cmake-developers] [PATCH] User may now specify toolset through CMake GUI

[Clinton Stimpson]

On Monday, February 16, 2015 11:35:47 AM Brad King wrote:
 On 02/15/2015 03:27 PM, rcdailey.li...@gmail.com wrote:
  From: Robert Dailey rcdai...@gmail.com
  
  The -T parameter to CMake may now be specified through QtDialog
  (cmake-gui) via a new text field in the first-time configure
  wizard (below the generator chooser).
 
 Thanks for working on this.  I think QCMake::setBinaryDirectory
 also needs to check for CMAKE_GENERATOR_TOOLSET from an existing
 cache file much like it already does for CMAKE_GENERATOR.  One
 may currently use the Add Entry button to pre-define an entry
 for CMAKE_GENERATOR_TOOLSET to set this from the GUI indirectly.
 
 Since not all generators support this field, we should not present
 it when a non-supporting generator is selected.  This will need
 some type of query on the selected generator to be added.
 
 Thanks,
 -Brad

In addition to Brad's comments, QCMake::deleteCache() should reset the Toolset 
member.

Thanks,
Clint
-- 

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

Re: [cmake-developers] Patch for some GUI Mac fixes

[Clinton Stimpson]

On Monday, January 26, 2015 08:01:31 AM Kevin Wojniak wrote:
 These 3 patches fix the Install menu not showing for Qt5 builds, the Install
 buttons not behaving like the other (standard) buttons, and fixes the
 search field not being shown on OS X when the window is at minimum size.

Thanks for the patches!

They have been applied:

http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=8ced6375
http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=b46a1519
http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=c19539c5

Clint
-- 

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

Re: [cmake-developers] New RelWithDebInfo flags?

[clinton]

- Original Message -
 Hi,
 
 I just discovered today that it looks like GCC 4.8 shipped with a new
 optimization level:
 
-Og Optimize debugging experience.  -Og enables optimizations that do
not interfere with debugging. It should be the optimization level
of choice for the standard edit-compile-debug cycle, offering a
reasonable level of optimization while maintaining fast
compilation and a good debugging experience.
 
 Would using this (if available) rather than -O2 in RelWithDebInfo
 configurations be something developers would want?
 
 Mailing list thread about the patch:
 
 https://gcc.gnu.org/ml/gcc-patches/2012-09/msg00097.html


Perhaps not if people are using that configuration to build release binaries 
and stripping debug symbols from it.

In my opinion, it *does* interfere with debugging, because of optimization done 
on stack variables.
You may or may not be able to see their value at certain times.  Its annoying 
enough that I go back to not having -Og for development, and have a separate 
build directory if I want optimization.

The program flow while debugging is uninterrupted though, which is nice.

Clint
-- 

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

[cmake-developers] CMake 3.1 regression with incremental builds ?

[Clinton Stimpson]

Using the netcdf project
ftp://ftp.unidata.ucar.edu/pub/netcdf/netcdf-4.3.2.tar.gz

I see a problem with incremental builds doing a relink of libraries.  Within 
my project, this leads to unnecessarily relinking of many executables every 
time I run cmake.

For example:

tar zxf netcdf-4.3.2.tar.gz
cd netcdf-4.3.2
mkdir build
cd build
cmake ../
git init .
git add .
git commit -minit
cmake ../
git diff


These files have modifications in them which will lead to relinking.
liblib/CMakeFiles/netcdf.dir/build.make
liblib/CMakeFiles/netcdf.dir/link.txt

I see object files listed in a random order.  Perhaps there is a std::set used 
somewhere in CMake or something.

I do not see this behavior with CMake 3.0.2.

Clint
-- 

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

Re: [cmake-developers] CMake 3.1 regression with incremental builds ?

[clinton]

I've put in a fix for this.
580b668d genex: Preserve order while evaluating TARGET_OBJECTS

Can we put this in RC 2?

Clint

- Original Message -
 
 Using the netcdf project
 ftp://ftp.unidata.ucar.edu/pub/netcdf/netcdf-4.3.2.tar.gz
 
 I see a problem with incremental builds doing a relink of libraries.  Within
 my project, this leads to unnecessarily relinking of many executables every
 time I run cmake.
 
 For example:
 
 tar zxf netcdf-4.3.2.tar.gz
 cd netcdf-4.3.2
 mkdir build
 cd build
 cmake ../
 git init .
 git add .
 git commit -minit
 cmake ../
 git diff
 
 
 These files have modifications in them which will lead to relinking.
 liblib/CMakeFiles/netcdf.dir/build.make
 liblib/CMakeFiles/netcdf.dir/link.txt
 
 I see object files listed in a random order.  Perhaps there is a std::set
 used
 somewhere in CMake or something.
 
 I do not see this behavior with CMake 3.0.2.
 
 Clint
 --
 
 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

Re: [cmake-developers] Support of codesign

[Clinton Stimpson]

Thanks for the patch.
Its in the repository now.
http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=bd3fbf3

Clint

On Tuesday, October 28, 2014 06:18:34 PM A. Klitzing wrote:
 Hi there!
 
 As requested... I renamed the 3 APPLE variables to BUNDLE_APPLE in attached
 patch.
 
 Thanks
   André Klitzing
 
 
 Clinton Stimpson clin...@elemtech.com schrieb am Mon Oct 27 2014 at
 
 17:42:50:
  Hi André,
  
  I can help you get this patch into the git repo.  But before doing that,
  Brad
  requested one more change.
  
  Can you please rename 3 of the CMake variables to
  
   CPACK_BUNDLE_APPLE_CERT_APP
   CPACK_BUNDLE_APPLE_ENTITLEMENTS
   CPACK_BUNDLE_APPLE_CODESIGN_FILES
  
  Thanks,
  Clint

-- 

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

Re: [cmake-developers] Support of codesign

[Clinton Stimpson]

On Thursday, October 23, 2014 11:13:15 AM Brad King wrote:
 On 10/21/2014 11:44 AM, Clinton Stimpson wrote:
  Because the design of this Bundle generator is not consistent with the
  rest of the CPack generators, you don't have this same chance, and the
  only way to do customization is to keep adding patches like yours.
 
 Is this something that should be refactored in CPack to address
 independently of the codesign changes?

Actually, the design is intentional -- that is, it has the feature of creating 
the application bundle for you, which involves handling for icons, Info.plist, 
and now the proposed code signing.  Alternatively, we have handling for icons 
and Info.plist in add_executable(... MACOSX_BUNDLE ...).  So basically, its 
duplicated functionality.


There are 2 approaches:
1. 
set(INSTALL_LIB_DIR lib)
set(INSTALL_BIN_DIR bin)

add_library(foolib ...)
install(TARGETS foolib RUNTIME DESTINATION ${INSTALL_LIB_DIR})
add_executable(foo ...)
target_link_libraries(foo foolib)
add_executable(foo2 ...)
target_link_libraries(foo2 foolib)
install(TARGETS foo foo2 RUNTIME DESTINATION ${INSTALL_BIN_DIR})
set(CPACK_GENERATOR Bundle)
set(CPACK_BUNDLE_STARTUP_COMMAND StartScript)
include(CPack)

The end result is a 
foo.app/Contents/MacOS/foo (renamed from StartScript)
foo.app/Contents/MacOS/bin/foo
foo.app/Contents/MacOS/bin/foo2
foo.app/Contents/MacOS/lib/libfoo.dylib


If any other CPack generator is used (TGZ, DragNDrop, PackageMaker, etc...), 
the package layout will be
bin/foo
bin/foo2
lib/libfoo.dylib



2.
set(INSTALL_LIB_DIR foo.app/Contents/MacOS)
set(INSTALL_BIN_DIR foo.app/Contents/MacOS)

add_library(foolib ...)
install(TARGETS foolib RUNTIME DESTINATION ${INSTALL_LIB_DIR})
add_executable(foo MACOSX_BUNDLE ...)
target_link_libraries(foo foolib)
add_executable(foo2 MACOSX_BUNDLE ...)
target_link_libraries(foo2 foolib)
install(TARGETS foo foo2 BUNDLE DESTINATION .
  RUNTIME DESTINATION ${INSTALL_BIN_DIR})
include(CPack)


The end result is a 
foo.app/Contents/MacOS/foo
foo.app/Contents/MacOS/foo2
foo.app/Contents/MacOS/libfoo.dylib

This gives consistent results with all CPack generators (TGZ, DragNDrop, 
PackageMaker, etc..) except for the Bundle generator.


Similar to #2, CMake itself uses an interesting approach of modifying 
CMAKE_INSTALL_PREFIX to redirect the installation into the CMake.app bundle, 
without modifying the DESTINATION option to the install() commands.


If the Bundle generator is changed to be made consistent with other cpack 
generators (which implies you lose the bundle making feature), you end up with 
what the DragNDrop generator is.

And now there is code signing  There is a chance that code signing will be 
introduced into CMake using another mechanism that works across platforms and 
across cpack generators.  How that will interact with the propose patch, I do 
not know, so I do have some concern about adding this patch.

So Brad, does this give you some idea of the situation?  Do you have some 
thoughts on merging the patch?

Clint

-- 

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

Re: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic

[Clinton Stimpson]

On Tuesday, October 21, 2014 08:22:24 AM Clinton Stimpson wrote:
 On Tuesday, October 21, 2014 03:59:19 PM Adam Strzelecki wrote:
   Regardless of where the bug lies, your changes took a packaging
   case that worked and made it not work.  That is a regression.
  
  I am sorry, but 55707fd5 in fact does it CORRECT WAY as it is expressed
  in:
  
  https://developer.apple.com/library/mac/documentation/MacOSX/Conceptual/BP
  Fr ameworks/Concepts/FrameworkAnatomy.html
  
  and expected by code-sign.
  
  Resources/ folder needs to lie in VERSION folder, so in out case
  QtGui.framework/Versions/4/Resources/
  
  Previous CMake was checking and copying QtGui.framework/Resources/ which
  is
  WRONG as this is wrong place, and it may just be symlink to CORRECT place.
  But such symlink is not obligatory in final bundle.
  
  It WAS working because Qt was looking in WRONG place for .nib file that
  was
  copied. Also before 10.9.5 it was code signing well because Apple put some
  heuristics to allow lousy bundles. But these were removed in 10.9.5 for
  code signed bundles.
  
  But assuming we restore Resources/ optional symlink we can circumvent
  that.
  And I am working on the patch, just give me few minutes.
 
 +1 for a symlink.  Handling of framework resources in BundleUtilities.cmake
 was originally based on the buggy Qt behavior.  I think Adam's suggested fix
 here is good.
 
 

And for the Qt internal error:

 Qt internal error: qt_menu.nib could not be loaded. The .nib file should be 
placed in QtGui.framework/Versions/Current/Resources/  or in the resources 
directory of your application bundle.

The message is incorrect.  Qt is actually looking for the resource in 
QtGui.framework/Resources/

Clint
-- 

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

Re: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic

[Clinton Stimpson]

On Tuesday, October 21, 2014 03:59:19 PM Adam Strzelecki wrote:
  Regardless of where the bug lies, your changes took a packaging
  case that worked and made it not work.  That is a regression.
 
 I am sorry, but 55707fd5 in fact does it CORRECT WAY as it is expressed in:
 
 https://developer.apple.com/library/mac/documentation/MacOSX/Conceptual/BPFr
 ameworks/Concepts/FrameworkAnatomy.html
 
 and expected by code-sign.
 
 Resources/ folder needs to lie in VERSION folder, so in out case
 QtGui.framework/Versions/4/Resources/
 
 Previous CMake was checking and copying QtGui.framework/Resources/ which is
 WRONG as this is wrong place, and it may just be symlink to CORRECT place.
 But such symlink is not obligatory in final bundle.
 
 It WAS working because Qt was looking in WRONG place for .nib file that was
 copied. Also before 10.9.5 it was code signing well because Apple put some
 heuristics to allow lousy bundles. But these were removed in 10.9.5 for
 code signed bundles.
 
 But assuming we restore Resources/ optional symlink we can circumvent that.
 And I am working on the patch, just give me few minutes.

+1 for a symlink.  Handling of framework resources in BundleUtilities.cmake 
was originally based on the buggy Qt behavior.  I think Adam's suggested fix 
here is good.


Clint


  Working around it for the packaging machine of CMake itself is
  not a solution because it could happen to any project built this
  way.
 
 I used wrong word, this was not workaround, but introduction of correct
 behavior. But I will add extra change that will restore Resources/ symlinks
 as well.
  Please extend your changes to restore successful packaging with
  no special help by adding whatever workarounds are needed.
 
 If I remove all workarounds and do it ONLY correct way as Apple specified
 then apps using currently release Qt SDKs will not work :
 
 Please note this has been fixes in Qt 5.4 beta, so we could remove
 workarounds, but then only most recent Qt SDK would work fine.
 
 If you need more information ping me on IRC.
 
 --Adam


-- 

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

Re: [cmake-developers] Support of codesign

[Clinton Stimpson]

On Tuesday, October 21, 2014 04:37:56 PM A. Klitzing wrote:
 Hi,
 
 I attached another patch to address the given issues.
 
 On 09/26/2014 10:08 AM, clin...@elemtech.com wrote:
   I would suggest the SignPackage function be moved from
   cmCPackDragNDropGenerator to cmCPackBundleGenerator because
   its implementation is only usable by cmCPackBundleGenerator.
   It uses CPACK_BUNDLE_NAME which is only valid in the context
   of cmCPackBundleGenerator.
 
 Yes, I moved it and DragNDrop is untouched now. That was just a
 copy+paste+modify mistake.
 
  On 09/29/2014 09:55 AM, clin...@elemtech.com wrote:
   Because it appears to only work with the Bundle generator, can
   you please move the documentation from Modules/CPackDMG.cmake
   to Modules/CPackBundle.cmake?
   Or did you intend to make this feature work for both the
   DragNDrop and Bundle generator?
 
 Same here
 
  On 09/29/2014 02:00 PM, Clinton Stimpson wrote:
   I think application signing is generally not a CPack thing, but
   there probably isn't much of a choice if the Bundle generator
   is used.
 
 Well, it isn't possible to sign that bundle without it. There must be a
 step between bundle and dmg. Maybe cmake could support that, too. So custom
 processing could be more flexible.

It *is* possible by using the more customizable DragNDrop generator.  With the 
DragNDrop generator, you will have a chance to sign the bundle before its put 
into a dmg.  You also have that same chance with the PackageMaker generator.

Because the design of this Bundle generator is not consistent with the rest of 
the CPack generators, you don't have this same chance, and the only way to do 
customization is to keep adding patches like yours.


 But I think cmake should support more codesigning tools by itself to unify
 the handling. For example we sign our MSI for windows with a custom
 command. This could be integrated into a unifed CPACK variable.

A code signing solution in CMake would be an interesting proposition.

Clint
-- 

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

Re: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic

[clinton]

- Original Message -
 On 10/08/2014 11:05 AM, clin...@elemtech.com wrote:
  I pushed more fixes for this.  Instead of requiring 10.6,
  I took the other path of warning when rpaths need changed
  at install time and skip it.
  This should also fix the CMP0042 test which started failing.
 
 Thanks.  The message is currently:
 
  +  msg  WARNING: Target \  this-Target-GetName()
  + \ has runtime paths which cannot be changed during install.
  
  + To change runtime paths, OS X version 10.6 or newer is
  required.  
  + Therefore, runtime paths will not be changed when
  installing.;
  +  cmSystemTools::Message(msg.str().c_str(), Warning);
 
 Can that be changed to an IssueMessage, possibly on a cmMakefile
 for at least a little context?  Also it should suggest using
 CMAKE_BUILD_WITH_INSTALL_RPATH.
 
  By the way, Brad, your change to require 10.6 for the
  BundleUtilities test is no longer required on the rpath-osx-10_6 topic.
  
 
 I thought it was a missing piece of your original change.
 Since you've reverted that I've now reverted mine so we'll
 see how testing goes.
 
  However, it may still be required for the fix-OSX-bundle-rpaths-and-Qt5
  topic.
 
 I rebased rpath-osx-10_6 on fix-OSX-bundle-rpaths-and-Qt5 to
 make local testing of both together easier.  Please base the
 above-requested fixes on:
 
  OSX: Warn when attempting to change runtime paths on OS X 10.5
  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a6e58f55
 

Adam,

I was looking at the BundleUtilities failure after the above fixes, and I 
noticed it unconditionally removes rpaths.
Is there a reason for that?

If the user does 
set_target_properties(testbundleutils1 module1 PROPERTIES
  INSTALL_RPATH ${CMAKE_CURRENT_BINARY_DIR}/testdir1
  BUILD_WITH_INSTALL_RPATH 1)

The new BundleUtilities.cmake will strip that rpath.
The attempt to strip those rpaths fails on OS X 10.5, because install_name_tool 
does not recognize  the -delete_rpath.
The test fails because the -id and -change portion of the install_name_tool 
command is prevented by the error from the use of -delete_rpath.

Perhaps we can separate the -delete_rpath part into its own call to 
install_name_tool.  If it fails, the failure can be ignored (as it previously 
ignored install_name_tool failures).  Or maybe there is another idea.

Clint
-- 

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

Re: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic

[clinton]

- Original Message -
 Adam,
 
 On 10/08/2014 12:17 PM, Clinton Stimpson wrote:
  Yeah.  I'm curious if changes to BundleUtilities.cmake in fix-OSX-bundle-
  rpaths-and-Qt5 will gracefully handle the BundleUtilities test case with
  @rpath on OS X 10.5.  Perhaps it'll recognize there is no need to change
  rpaths.
 
 The BundleUtilities test still fails on OS X 10.5:
 
  http://open.cdash.org/testDetails.php?test=285651145build=3522021
  -- 6/10: fixing up
  
 '/.../Tests/BundleUtilities/testdir1/testbundleutils1.app/Contents/MacOS/testbundleutils1'
  install_name_tool: more than one input file specified
  (/.../Tests/BundleUtilities/testdir1 and -delete_rpath)
  Usage: install_name_tool [-change old new] ... [-id name] input
 
 Clinton's changes in his rpath-osx-10_6 extension topic to yours teach
 other uses of -delete_rpath to warn on OS X 10.5 and skip deletion.
 I think something similar will be needed here.  Please investigate.
 
 Meanwhile, on my local OS X 10.9 machine I added this patch:
 
 diff --git a/Modules/BundleUtilities.cmake b/Modules/BundleUtilities.cmake
 index eedab44..80e5d3b 100644
 --- a/Modules/BundleUtilities.cmake
 +++ b/Modules/BundleUtilities.cmake
 @@ -755,6 +755,7 @@ function(fixup_bundle_item resolved_embedded_item exepath
 dirs)
#
if(changes)
  execute_process(COMMAND install_name_tool ${changes}
  ${resolved_embedded_item})
 +message(STATUS CHANGE install_name_tool ${changes}
 \${resolved_embedded_item}\)
endif()
  endfunction()
 
 From the test output I can see that it is trying to delete several
 rpath entries that do not exist and therefore do not need deletion.
 How is the list chosen for each binary?
 

Brad,

When I do the same message(), I don't see deletion of rpaths which do not exist.
I see deletions of rpaths which do exist as defined in the CMakeLists.txt file:
set_target_properties(testbundleutils1 module1 PROPERTIES
  INSTALL_RPATH ${CMAKE_CURRENT_BINARY_DIR}/testdir1
  BUILD_WITH_INSTALL_RPATH 1)

But, I'm wondering if INSTALL_RPATH should only be effective on OS X if 
MACOSX_RPATH is set.
Currently MACOSX_RPATH determines whether a target uses @rpath for its id, 
which can result in rpaths for a consumer.
In other words, whether a target has rpaths is determined by the use of @rpath 
in its dependencies.
What do you think about the case of INSTALL_RPATH?

Clint
-- 

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

Re: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic

[Clinton Stimpson]

On Thursday, October 09, 2014 10:27:32 AM Brad King wrote:
 On 10/09/2014 10:16 AM, clin...@elemtech.com wrote:
  When I do the same message(), I don't see deletion of rpaths which do not
  exist.
 I see them for libshared and libshared2 which have SKIP_BUILD_RPATH.
 
  But, I'm wondering if INSTALL_RPATH should only be effective on OS X
  if MACOSX_RPATH is set.
  Currently MACOSX_RPATH determines whether a target uses @rpath for
  its id, which can result in rpaths for a consumer.
  In other words, whether a target has rpaths is determined by the
  use of @rpath in its dependencies.
  What do you think about the case of INSTALL_RPATH?
 
 If any dependencies have @rpath then the RPATH of a target is
 meaningful, and INSTALL_RPATH is how the actual search paths
 listed in the RPATH are to be set.  INSTALL_RPATH is orthogonal
 to MACOSX_RPATH.  The affect different fields of their target.
 

Another justification for that is if a target does not link to any libraries 
with an @rpath id, it is still useful to have an rpath to support 
dlopen(@rpath/somelib).

Thanks,
Clint
-- 

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

Re: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic

[clinton]

- Original Message -
 
 - Original Message -
  On 10/06/2014 10:36 AM, Adam Strzelecki wrote:
   Sure, I think it would be good to require 10.6.
   
   Moreover I believe nobody nowadays builds for 10.5 on 10.5.
  
  Perhaps no one has to build that way for deployment but there could
  still be people just building for their own host as the only computer
  they have.  The fact that our dashboard reported this problem means
  we are testing that case.
  
  Clinton, I don't have a 10.5 machine anymore and the test is failing
  on yours.  Please take whatever action you feel is appropriate to
  resolve the test failure on that machine.  This could mean either
  disabling rpath altogether on 10.5 or changing the new hunk:
  
   +  foreach(rpath ${${ikey}_RPATHS})
   +set(changes ${changes} -delete_rpath ${rpath})
   +  endforeach()
  
  to warn and skip removal when hosted on 10.5.  Or another option you
  find.
  
  This needs to be resolved in the next day or two or the topic won't
  be in CMake 3.1.
  
  Thanks,
  -Brad
  
  
 
 I don't have a 10.5 machine, but I've put in a commit which I hope solves the
 problem.
 36c509b9 OSX: Only enable @rpath support on OS X 10.6 or greater.
 

I pushed more fixes for this.  Instead of requiring 10.6, I took the other path 
of warning when rpaths need changed at install time and skip it.
This should also fix the CMP0042 test which started failing.

By the way, Brad, your change to require 10.6 for the BundleUtilities test is 
no longer required on the rpath-osx-10_6 topic.

However, it may still be required for the fix-OSX-bundle-rpaths-and-Qt5 topic.

Clint
-- 

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

Re: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic

[Clinton Stimpson]

On Wednesday, October 08, 2014 11:17:03 AM Brad King wrote:
 On 10/08/2014 11:05 AM, clin...@elemtech.com wrote:
  I pushed more fixes for this.  Instead of requiring 10.6,
  I took the other path of warning when rpaths need changed
  at install time and skip it.
  This should also fix the CMP0042 test which started failing.
 
 Thanks.  The message is currently:
  +  msg  WARNING: Target \  this-Target-GetName()
  + \ has runtime paths which cannot be changed during install. 
   + To change runtime paths, OS X version 10.6 or newer is
  required.   + Therefore, runtime paths will not be changed
  when installing.; +  cmSystemTools::Message(msg.str().c_str(),
  Warning);
 
 Can that be changed to an IssueMessage, possibly on a cmMakefile
 for at least a little context?  Also it should suggest using
 CMAKE_BUILD_WITH_INSTALL_RPATH.

Fixed.

 
  By the way, Brad, your change to require 10.6 for the
  BundleUtilities test is no longer required on the rpath-osx-10_6 topic.
 
 I thought it was a missing piece of your original change.
 Since you've reverted that I've now reverted mine so we'll
 see how testing goes.

Yeah.  I'm curious if changes to BundleUtilities.cmake in fix-OSX-bundle-
rpaths-and-Qt5 will gracefully handle the BundleUtilities test case with 
@rpath on OS X 10.5.  Perhaps it'll recognize there is no need to change 
rpaths.

Clint
-- 

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

Re: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic

[clinton]

- Original Message -
 On 10/04/2014 11:37 AM, Adam Strzelecki wrote:
  I've applied your suggestions about quoting and used portable
  (POSIX compliant) find call that should work now on any system.
 
 Thanks.
 
 On 10/05/2014 03:35 PM, Adam Strzelecki wrote:
  Correct me if I am wrong but it seems CDash reports no
  further problems with my changes.
 
 It's better, but the BundleUtilities test fails on OS X 10.5:
 
  http://open.cdash.org/testDetails.php?test=285651145build=3517533
 
  -- 6/10: fixing up
  
 '.../Tests/BundleUtilities/testdir1/testbundleutils1.app/Contents/MacOS/testbundleutils1'
  install_name_tool: more than one input file specified
  (.../Tests/BundleUtilities/testdir1 and -delete_rpath)
  Usage: install_name_tool [-change old new] ... [-id name] input
  -- 7/10: fixing up
  
 '.../Tests/BundleUtilities/testdir1/testbundleutils1.app/Contents/MacOS/module1.so'
  install_name_tool: more than one input file specified
  (.../Tests/BundleUtilities/testdir1 and -delete_rpath)
  Usage: install_name_tool [-change old new] ... [-id name] input
 
 From this message it looks like the install_name_tool does not
 support -delete_rpath.  IIRC @rpath was first added in OS X 10.5
 so it looks like that part had not yet matured.
 
 Use of -delete_rpath was previously added at install-time here:
 
  OS X: Add RPATH support for Mac.
  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=94e7fef2
 
 so I think this problem existed before but was not exposed by tests.
 
 Clinton, what do you think of changing the Darwin.cmake test for
 enabling @rpath support to require OS X 10.6 instead of 10.5?
 Otherwise we may be leaking build tree RPATH entries into installed
 files on 10.5.

Sure, I think it would be good to require 10.6.
We also have uses of the -delete_rpath/-add_rpath parameters in 
cmInstallTargetGenerator.cxx, and the test of that already requires 10.6 or 
greater.

Clint
-- 

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

Re: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic

[clinton]

- Original Message -
 On 10/06/2014 10:36 AM, Adam Strzelecki wrote:
  Sure, I think it would be good to require 10.6.
  
  Moreover I believe nobody nowadays builds for 10.5 on 10.5.
 
 Perhaps no one has to build that way for deployment but there could
 still be people just building for their own host as the only computer
 they have.  The fact that our dashboard reported this problem means
 we are testing that case.
 
 Clinton, I don't have a 10.5 machine anymore and the test is failing
 on yours.  Please take whatever action you feel is appropriate to
 resolve the test failure on that machine.  This could mean either
 disabling rpath altogether on 10.5 or changing the new hunk:
 
  +  foreach(rpath ${${ikey}_RPATHS})
  +set(changes ${changes} -delete_rpath ${rpath})
  +  endforeach()
 
 to warn and skip removal when hosted on 10.5.  Or another option you
 find.
 
 This needs to be resolved in the next day or two or the topic won't
 be in CMake 3.1.
 
 Thanks,
 -Brad
 
 

I don't have a 10.5 machine, but I've put in a commit which I hope solves the 
problem.
36c509b9 OSX: Only enable @rpath support on OS X 10.6 or greater.

Clint
-- 

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

Re: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic

[Clinton Stimpson]

On Tuesday, September 30, 2014 11:37:27 AM Brad King wrote:
 Hi Folks,
 
 Picking up from the end of an earlier thread:
 
  [PATCH] stage/fix-OSX-bundle-rpaths-and-Qt5
  http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10781/focu
 s=11016
 
 Is the fix-OSX-bundle-rpaths-and-Qt5 topic ready to be merged to
 'next' for testing?  Clinton, have your comments been addressed?
 
 Thanks,
 -Brad

My concerns of breaking backward compatibility were already addressed.

However, I do wish there is a test for this.  Although the commits target OS 
X, I would like to see some proof that the API changes in GetPrerequisites for 
supporting rpaths will work on other platforms such as Linux.

A test for both OS X and Linux will help justify the API changes.

Clint

-- 

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

Re: [cmake-developers] Support of codesign

[clinton]

- Original Message -

  It should not be an error for 'codesign' to not be available
 
  in the PATH. The user may have set CPACK_COMMAND_CODESIGN
 
  to some other location. The error should only occur if no
 
  value for CPACK_COMMAND_CODESIGN is available when the tool
 
  is actually needed for signing.
 

 I attached another patch that will fix the broken tests. It will check for
 defined CPACK_APPLE_CERT_APP before it will search for 'codesign'.

 Well, the FindProgram line for codesign looks like the line for Rez, hdiutil,
 SetFile and so on. I don't know cmake sources enough... but shouldn't it be
 the same here?

Because it appears to only work with the Bundle generator, can you please move 
the documentation from Modules/CPackDMG.cmake to Modules/CPackBundle.cmake? 
Or did you intend to make this feature work for both the DragNDrop and Bundle 
generator? 

Thanks, 
Clint 
-- 

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

Re: [cmake-developers] Support of codesign

[Clinton Stimpson]

On Monday, September 29, 2014 01:23:04 PM Chuck Atkins wrote:
  Maybe it shouldn't even be a CPack thing. Maybe it should be an
  install time step so that all CPack generators will contains signed
  binaries if codesign is used...
 
 I know this is a bit after the fact and I'm jumping in here pretty late,
 but...
 
 It would be nice to have package signing as a general top level CPack
 feature.  Most supported package formats support some form of signing, rpm
 and deb with gpg keys, apple bundles, dmgs, nsis installers, etc.  Could
 this be done as a generic CPack variable, CPACK_PACKAGE_SIGNING_KEY, for
 example, and then if set, then each CPack generator would use it
 accordingly?
 
 Just a thought, not to derail this current patch though.

The patch does introduce a SignPackage() function, but what its really doing 
is signing the application, not the package.  There is another suggestion for 
the patch -- rename the SignPackage() function to be clear that the 
application is being signed, not the package.  At least in the CPack context, 
the package is the .dmg file, not the .app bundle.

The Bundle generator creates an application bundle plus the package.  Because 
the Bundle generator makes the application, a user would want a way to sign 
it.  This is why its Bundle generator specific.  With any other generator, the 
application signing can be done with an install() command.

I think application signing is generally not a CPack thing, but there probably 
isn't much of a choice if the Bundle generator is used.

Clint

-- 

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

Re: [cmake-developers] Support of codesign

[clinton]

I would suggest the SignPackage function be moved from 
cmCPackDragNDropGenerator to cmCPackBundleGenerator because its implementation 
is only usable by cmCPackBundleGenerator.  It uses CPACK_BUNDLE_NAME which is 
only valid in the context of cmCPackBundleGenerator.

Clint 

- Original Message -
 On 09/25/2014 04:40 PM, A. Klitzing wrote:
  I refactored the patches of Brian Milco to support
  code signing of bundles in MacOS.
 [snip]
 On 09/26/2014 03:29 AM, A. Klitzing wrote:
  Well, first patch had a little mistake. I attached an update...
 
 Thanks!
 
 I've applied the patch and merged to our 'next' branch for
 testing:
 
  CPack: Add support for code signing of bundles on MacOS
  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1a9b0668
 
 I would appreciate any feedback from others too.
 
 -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

Re: [cmake-developers] [PATCH 3/6] Resolve replace @rpath placeholders

[Clinton Stimpson]

On Thursday, September 18, 2014 06:15:51 PM Adam Strzelecki wrote:
 FYI I pushed stage/fix-OSX-bundle-rpaths-and-Qt5 topic for final review.
 
 Regards,

Does the functionality you add allow us to modify 
CMake/Tests/BundleUtilities/CMakeLists.txt such that the last part in the 
tests where @rpath is used can be changed to separate the binaries into bin/ 
and lib/ directories instead of everything in one directory.  I assume so 
since you added the the ability to extract rpaths from a binary.

Then eventually, someone can add the same capability for Linux.  I'm hoping 
the parameter you added to functions in GetPrerequisite.cmake is not OS X 
specific (at the moment, it appears so).

Thanks,
- Clint

-- 

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

Re: [cmake-developers] [PATCH 3/6] Resolve replace @rpath placeholders

[Clinton Stimpson]

On Wednesday, September 17, 2014 01:13:45 AM Adam Strzelecki wrote:
  What is the new optional parameter to gp_file_type() used for?
 
 My intention was to pass exepath rather than take it from the path of
 original_file. But this is in fact not necessary.
  I don't see any code in your branch calling that function with the new
  parameter.
 
 You are right, I am not using that. So I can drop that change.
 
 --Adam

After that change is dropped, I give a +1 for the patch set.

Thanks,
Clint
-- 

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

Re: [cmake-developers] [PATCH 3/6] Resolve replace @rpath placeholders

[Clinton Stimpson]

)
 @@ -596,20 +600,20 @@ endfunction()
 
 
  function(gp_file_type original_file file type_var)
 +  set(executable ${ARGV0})
 +
if(NOT IS_ABSOLUTE ${original_file})
  message(STATUS warning: gp_file_type expects absolute full path for
 first arg original_file) endif()
 
 -  get_filename_component(exepath ${original_file} PATH)
 -
set(type )
 -  gp_resolved_file_type(${original_file} ${file} ${exepath}  type)
 +  gp_resolved_file_type(${original_file} ${file} ${executable} 
 type)
 
set(${type_var} ${type} PARENT_SCOPE)
  endfunction()
 
 
 -function(get_prerequisites target prerequisites_var exclude_system recurse
 exepath dirs) +function(get_prerequisites target prerequisites_var
 exclude_system recurse executable dirs) set(verbose 0)
set(eol_char E)
 
 @@ -738,6 +742,7 @@ function(get_prerequisites target prerequisites_var
 exclude_system recurse exepa
 
if(${gp_tool} STREQUAL ldd)
  set(old_ld_env $ENV{LD_LIBRARY_PATH})
 +get_filename_component(exepath ${executable} PATH)
  set(new_ld_env ${exepath})
  foreach(dir ${dirs})
set(new_ld_env ${new_ld_env}:${dir})
 @@ -834,7 +839,7 @@ function(get_prerequisites target prerequisites_var
 exclude_system recurse exepa
 
  if(add_item AND ${exclude_system})
set(type )
 -  gp_resolved_file_type(${target} ${item} ${exepath} ${dirs}
 type) +  gp_resolved_file_type(${target} ${item} ${executable}
 ${dirs} type)
 
if(${type} STREQUAL system)
  set(add_item 0)
 @@ -855,7 +860,7 @@ function(get_prerequisites target prerequisites_var
 exclude_system recurse exepa # that the analysis tools can simply accept it
 as input.
  #
  if(NOT list_length_before_append EQUAL list_length_after_append)
 -  gp_resolve_item(${target} ${item} ${exepath} ${dirs}
 resolved_item) +  gp_resolve_item(${target} ${item}
 ${executable} ${dirs} resolved_item) set(unseen_prereqs
 ${unseen_prereqs} ${resolved_item}) endif()
endif()
 @@ -874,7 +879,7 @@ function(get_prerequisites target prerequisites_var
 exclude_system recurse exepa if(${recurse})
  set(more_inputs ${unseen_prereqs})
  foreach(input ${more_inputs})
 -  get_prerequisites(${input} ${prerequisites_var} ${exclude_system}
 ${recurse} ${exepath} ${dirs}) +  get_prerequisites(${input}
 ${prerequisites_var} ${exclude_system} ${recurse} ${executable}
 ${dirs}) endforeach()
endif()
 
 @@ -911,7 +916,7 @@ function(list_prerequisites target)
get_filename_component(exepath ${target} PATH)
 
set(prereqs )
 -  get_prerequisites(${target} prereqs ${exclude_system} ${all}
 ${exepath} ) +  get_prerequisites(${target} prereqs ${exclude_system}
 ${all} ${target} )
 
if(print_target)
  message(STATUS File '${target}' depends on:)

-- 
Clinton Stimpson
Elemental Technologies, Inc
Computational Simulation Software, LLC
www.csimsoft.com
-- 

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

Re: [cmake-developers] [PATCH 3/6] Resolve replace @rpath placeholders

[Clinton Stimpson]

On Tuesday, September 16, 2014 08:48:31 PM Adam Strzelecki wrote:
  Instead, can you extract rpaths for a binary in BundleUtilities and pass
  that into gp_resolve_item via the existing dirs argument?
 
 Okay, fixed this in the new 3/6 + 4/6 patches, attached to previous patch
 post.
 
 FYI I cannot use existing dirs arguments because other replacements search
 paths shouldn't look into rpath, only @rpath replacements.

Sure, but the caller can also check for @rpath and in that case add the rpaths 
to the existing dirs argument.

Yes, there are other find_file() searches in there, that could potentially mess 
up if the actual filename had @rpath in it.

But I would also argue that the general fallback
find_file(ri ${item} ${exepath} ${dirs} /usr/lib)
can undesirably be affected by other variables such as CMAKE_INCLUDE_PATH.

 
 So instead I added extra optional rpaths argument to all GetPrerequisites
 functions that somewhere call gp_resolve_item so need to carry rpaths.
 
 WDYT?
 
 --Adam

Can you explain the exepath to executable change in the function 
signatures?  I have the impression you changed the signature of several 
functions to accept 
/path/to/executable
instead of 
/path/to/

No?  These functions are called by other codes and we can't just change the 
meaning of the arguments.

-- 
Clinton Stimpson
Elemental Technologies, Inc
Computational Simulation Software, LLC
www.csimsoft.com
-- 

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

Re: [cmake-developers] [PATCH 3/6] Resolve replace @rpath placeholders

[Clinton Stimpson]

On Tuesday, September 16, 2014 10:53:14 PM Adam Strzelecki wrote:
 I have sent [PATCH 3/5] Resolve  replace @rpath placeholders which replaces
 previous 3/6 and obsoletes 4/6.
 
 Since it is getting messy like checking  fixing maybe stage account and
 topic branch would be more accurate.
 
 --Adam

Yes, it would be easier to review on stage or on github.  Thanks.

-- 
Clinton Stimpson
Elemental Technologies, Inc
Computational Simulation Software, LLC
www.csimsoft.com
-- 

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

Re: [cmake-developers] [PATCH 3/6] Resolve replace @rpath placeholders

[Clinton Stimpson]

On Tuesday, September 16, 2014 11:01:33 PM Adam Strzelecki wrote:
  Yes, it would be easier to review on stage or on github.  Thanks.
 
 Here it is:
 https://github.com/nanoant/CMake/commits/fix-bundle-rpaths
 
 I would love to get stage access though ;)
 
 Cheers,

What is the new optional parameter to gp_file_type() used for?
I don't see any code in your branch calling that function with the new 
parameter.

-- 
Clinton Stimpson
Elemental Technologies, Inc
Computational Simulation Software, LLC
www.csimsoft.com
-- 

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

Re: [cmake-developers] [PATCH 3/6] Resolve replace @rpath placeholders

[clinton]

I think it would be nice to move
get_item_rpaths() from BundleUtilities.cmake to gp_item_get_rpaths() in 
GetPrerequisites.cmake.

And how does your patch or patch set handle @loader_path being used in the 
rpath?

Also, I think the function signature should include the rpath vs runpath 
distinction.  I realize OS X doesn't have the runpath concept, but if one were 
to add support for Linux, one may need that where the runpath affects only 
finding immediate dependencies.

Below is what I have for Linux and OS X.
It include rpath vs. runpath, and expands out the @loader_path variable.

Does it help, or did you have something else in mind?

# Get rpaths for a binary.
function(get_rpaths binary rpaths run_paths)
  get_filename_component(binary_dir ${binary} PATH)
  unset(myrpaths)
  unset(myrunpaths)
  if(APPLE)
execute_process(COMMAND otool -l ${binary}
COMMAND grep -A2 LC_RPATH
COMMAND grep path
OUTPUT_VARIABLE paths)
string(REPLACE \n ; paths ${paths})
foreach(str ${paths})
  string(REGEX REPLACE  path (.*) \\(offset.* \\1 rpath ${str})
  string(STRIP ${rpath} rpath)
  string(REPLACE @loader_path ${binary_dir} rpath ${rpath})
  list(APPEND myrpaths ${rpath})
endforeach()
  else()
execute_process(COMMAND objdump -p ${binary}
COMMAND grep RPATH
OUTPUT_VARIABLE paths)
execute_process(COMMAND objdump -p ${binary}
COMMAND grep RUNPATH
OUTPUT_VARIABLE paths2)
string(REPLACE \n ; paths ${paths})
string(REPLACE \n ; paths2 ${paths2})
foreach(str ${paths})
  string(REGEX REPLACE  RPATH[ ]*(.*) \\1 rpath ${str})
  string(STRIP ${rpath} rpath)
  string(REPLACE \$ORIGIN ${binary_dir} rpath ${rpath})
  list(APPEND myrpaths ${rpath})
endforeach()
foreach(str ${paths2})
  string(REGEX REPLACE  RUNPATH[ ]*(.*) \\1 rpath ${str})
  string(STRIP ${rpath} rpath)
  string(REPLACE \$ORIGIN ${binary_dir} rpath ${rpath})
  list(APPEND myrunpaths ${rpath})
endforeach()
  endif()

  string(REPLACE : ; myrpaths ${myrpaths})
  string(REPLACE : ; myrunpaths ${myrunpaths})
  set(${rpaths} ${myrpaths} PARENT_SCOPE)
  set(${run_paths} ${myrunpaths} PARENT_SCOPE)
endfunction()


Clint

- Original Message -
 This is done by gathering LC_RPATH commands for main bundle executable and
 using it for @rpath lookup in dependent frameworks.
 
 To achieve this all utility functions now take path to executable rather than
 path to its directory.
 
 This enabled apps using @rpath to be bundled correctly, which will be
 necessary
 for upcoming Qt 5.4 that will use @rpath for all frameworks.
 ---
  Modules/BundleUtilities.cmake  | 169
  -
  Modules/GetPrerequisites.cmake |  48 ++--
  2 files changed, 124 insertions(+), 93 deletions(-)
 
 diff --git a/Modules/BundleUtilities.cmake b/Modules/BundleUtilities.cmake
 index 7e2b173..9733bc9 100644
 --- a/Modules/BundleUtilities.cmake
 +++ b/Modules/BundleUtilities.cmake
 @@ -19,6 +19,7 @@
  #get_bundle_and_executable
  #get_bundle_all_executables
  #get_item_key
 +#get_item_rpaths
  #clear_bundle_keys
  #set_bundle_key_values
  #get_bundle_keys
 @@ -75,7 +76,7 @@
  #
  # ::
  #
 -#   GET_DOTAPP_DIR(exe dotapp_dir_var)
 +#   GET_DOTAPP_DIR(executable dotapp_dir_var)
  #
  # Returns the nearest parent dir whose name ends with .app given the
  # full path to an executable.  If there is no such parent dir, then
 @@ -123,7 +124,7 @@
  #
  # ::
  #
 -#   SET_BUNDLE_KEY_VALUES(keys_var context item exepath dirs
 +#   SET_BUNDLE_KEY_VALUES(keys_var context item executable dirs
  # copyflag)
  #
  # Add a key to the list (if necessary) for the given item.  If added,
 @@ -163,7 +164,7 @@
  #
  # ::
  #
 -#   FIXUP_BUNDLE_ITEM(resolved_embedded_item exepath dirs)
 +#   FIXUP_BUNDLE_ITEM(resolved_embedded_item executable dirs)
  #
  # Get the direct/non-system prerequisites of the resolved embedded item.
  # For each prerequisite, change the way it is referenced to the value of
 @@ -189,11 +190,11 @@
  #
  # ::
  #
 -#   VERIFY_BUNDLE_PREREQUISITES(bundle result_var info_var)
 +#   VERIFY_BUNDLE_PREREQUISITES(bundle executable result_var
 info_var)
  #
  # Verifies that the sum of all prerequisites of all files inside the
 -# bundle are contained within the bundle or are system libraries,
 -# presumed to exist everywhere.
 +# bundle with given main executable are contained within the bundle or are
 +# system libraries, presumed to exist everywhere.
  #
  # ::
  #
 @@ -285,8 +286,8 @@ function(get_bundle_main_executable bundle result_var)
  endfunction()
  
  
 -function(get_dotapp_dir exe dotapp_dir_var)
 -  set(s ${exe})
 +function(get_dotapp_dir executable dotapp_dir_var)
 +  set(s ${executable})
  
if(s MATCHES /.*\\.app/)
  # If there is a .app parent directory,
 @@ 

Re: [cmake-developers] [ANNOUNCE] CMake 3.0.0 Released.

[clinton]

- Original Message -
 On 11.06.2014 10:52, Kornel Benko wrote:
  Am Dienstag, 10. Juni 2014 um 17:14:31, schrieb Robert Maynard
  robert.mayn...@kitware.com
  On behalf of myself, Ken, Bill, Brad, David, Alex, Eike, Steve, Zach, Ben,
  Peter, Nils, and the rest of the CMake team from all around the world, we
  are
  pleased to announce that CMake 3.0.0 is now available for download at:
 http://www.cmake.org/files/v3.0/?C=M;O=D
  Running tests I got some errors:
 
  The following tests FAILED:
   344 - RunCMake.CommandLine (Failed)
   348 - CTestTestMemcheckDummyPurify (Failed)
   349 - CTestTestMemcheckDummyValgrind (Failed)
   354 - CTestTestMemcheckDummyValgrindPrePost (Failed)
   357 - CTestTestMemcheckDummyValgrindIgnoreMemcheck (Failed)
   395 - CMake.If (Failed)
  Errors while running CTest
 
 
 Were you testing git master rather than 3.0?
 
 The issues seem to have been introduced by
 5d360f23fa5616004ffa813914336e5810d1f42b.
 Which is not in 3.0.

Thanks for pointing that out.  I thought I ran tests before and after my 
changes under different locales, and didn't see any regressions.
Anyway, I do see it now and can look into this.

Clint
-- 

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/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Please review FindQt_versioned_tools

[Clinton Stimpson]

On Wednesday, May 21, 2014 10:50:42 AM Brad King wrote:
 On 05/21/2014 09:18 AM, Stephen Kelly wrote:
  I recall discussion about this kind of thing before, but I think
  relating to qmake-qt4 and other versioned names.
 
 Currently qmake is preferred over qmake-qt4, but I do not know
 why.  There is a check to avoid using qmake from Qt5 at least:
 
  FindQt4: Do not use qmake from Qt5, 2013-03-05
  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=21123416
 
 Originally qmake-qt4 was preferred over qmake:
 
  ENH: Add support for debian having both qt3 and qt4, 2006-02-28
  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2251970c
  (qmake-qt4 qmake)
 
 Then the order was reversed without much detail in the commit:
 
  ENH: -apply the patches by Clinton Stimpson, 2006-04-27
  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f59ad1aa
  (qmake qmake-qt4)
 
 The commit message mentions porting some changes from KDE's
 module, so perhaps history is there.
 
 Later they were flipped back and forth in one day:
 
  ENH:  Clarify a doc string.  Fixes #10358, 2010-03-17
  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bd0b37ea
  (qmake-qt4 qmake)
 
  Change to use FindX11.cmake.  Should fix #9929, 2010-03-17
  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=61ad5242
  (qmake qmake-qt4)
 
 so that was likely an accident followed by a correction.
 
 I think there was discussion too but I also do not remember when
 or where.
 

I vaguely remember a discussion as well.
I think it had something to do with find_program() looping over names then 
paths vs. paths then names.

Here's a test I just did on my machine:
I have qmake for Qt3 in a system location, qmake-qt4 for Qt4 in a system 
location, and qmake for my own Qt4 build under my home directory.
I then add my own Qt4 build in CMAKE_PREFIX_PATH.

With find_program( .. qmake qmake-qt4 ...),
I get my build of Qt4.

With  find_program( .. qmake-qt4 qmake ...),
I get the system Qt4.

Should we change FindQt4.cmake to loop over paths first, then it wouldn't 
matter as much what order the names are?  FindQt4 already handles the case 
where the qmake for Qt3 is found first and skip over it.

Clint

-- 

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/cgi-bin/mailman/listinfo/cmake-developers

[cmake-developers] sporadic build failures with ninja

[clinton]

I'm seeing some build problems show up on cdash from some of my builds that use 
ninja. 

The error that shows up on cdash is: 
ninja: error: GetFileAttributesEx(c:\Program Files (x86)\Mcl : Command line 
warning D9025 : overriding ): The filename, directory name, or volume label 
syntax is incorrect. 

When building a set of 3rd party libraries, I simply add /w to the compile 
flags to suppress any warnings from them. 
I could go back to that and modify how I'm suppressing them to take out the 
default /W3 to avoid this command line warning D9025 I'm getting. But, it 
doesn't show up on cdash anyway, and it uncovers another problem that should 
probably be fixed anyway. 

With some help from the ninja mailing list, they pointed me in the direction of 
cmcldeps included in CMake. 
I have now confirmed that a .d file generated by cmcldeps contains a line: 


hdf5-1.8.10/src/CMakeFiles/hdf5.dir/H5Pdcpl.c.obj.d:c:\\Program\ Files\ 
(x86)\\Mcl\ :\ Command\ line\ warning\ D9025\ :\ overriding\ '\\W3'\ with\ 
'\\W0' \ 




cmcldeps calls cl.exe with the additional argument of /showIncludes and it 
parses the output to make a list of includes. 

When I call cl.exe /nologo /showIncludes ... /W3 ... /w   manualy and 
redirect it, I noticed the D9025 warning is printed to stderr and everything 
else to stdout. And when printed to the console, or when both the stderr and 
stdout are redirected to the same file, I always get the D9025 warning on the 
first line. I also want to mention that compile errors go to stdout, not 
stderr. 




But, it seems that when cmcldeps calls cmSystemTools::RunSingleCommand(), the 
stderr and stdout are merged inconsistently. I'm guessing this inconsistency is 
why I get the D9025 warning on a line that starts with Note: including file: 
... 




I'm not sure if cmcldeps can be changed to ignore stderr, or if kwsysProcess 
needs fixed to alternately read stderr/stdout in the order the child process 
printed to them. I imagine the latter might be possible if the same HANDLE was 
given to the STARTUPINFO's hStdError and hStdOutput, if we aren't already doing 
that. I can't quickly tell what ProcessWin32.c is doing in that respect. 




Also, ninja appears to have some of its own dependency tracking capabilities. 
Is there any reason not to switch away from cmcldeps and use ninja's deps=msvc? 




So, does anyone have any tips on where to go next? 


Thanks, 

Clint 


-- 

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/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Please review FindQt_versioned_tools

[Clinton Stimpson]

On Tuesday, May 20, 2014 05:53:16 PM Rolf Eike Beer wrote:
 Clinton, Stephen,
 
 inspired by what OpenBSD currently does downstream I did a patch that always
 searches for the plain executable names (like moc) after all versioned
 executable names (e.g. moc4) have been tried. Since those tools are not
 checked for their versions one might otherwise end up e.g. picking up
 qmake3 and moc (version 4), which will of course cause some screwup. Using
 this patch it should be much more likely that the set of tools chosen by
 CMake for a given Qt major version is consistent.
 
 Opinions?
 
 Eike

The change makes sense to me.

Clint
-- 

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/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake identifies MacOSX10.7-Xcode43-ub as GNU, but it runs clang.

[Clinton Stimpson]

On Tuesday, April 29, 2014 11:01:06 AM Brad King wrote:
 On 04/28/2014 01:07 PM, Brad King wrote:
  It looks like in this case users will have to tell Xcode what tool
  to use up front using the CMake generator toolset feature (cmake -T).
  I think this is acceptable because it only affects old Xcode versions.
  Otherwise we will need a much more complicated compiler id bootstrap
  process
 
 Actually it is not so complicated because the determination of
 the sysroot and deployment target does not depend on the language.
 I just had to introduce a platform-specific initialization step
 after the system is determined but before the compilers are:
 
  Add platform-specific initialization step when enabling languages
  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=416761e3
 
  OS X: Factor a Darwin-Initialize module out of Platform/Darwin
  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0200d0a9
 
  Xcode: Use sysroot and deployment target to identify compiler
  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0cce556b
 
 Now the Xcode compiler identification finds the right one.
 I've reverted my change to the machine-specific dashboard
 script.
 
 -Brad

Thanks!  Those fixes were needed to fix this:
http://cmake.org/Bug/view.php?id=14572

- Clint
-- 

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/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Review request: fix-Qt5-windows-build

[Clinton Stimpson]

On Wednesday, March 12, 2014 05:21:30 PM Stephen Kelly wrote:
 Hi,
 
 I didn't follow the encoding work done by Clinton, and in my Qt 5 build with
 default settings, the new codepage related definition is not set. However,
 if it is set somehow, then the build would be calling methods which are not
 present in Qt 5.
 
 I've just pushed a topic fixing that, but would appreciate review from
 Clinton?
 
 Thanks,
 
 Steve.

I personally would prefer a Qt version check around the new QTextCodec code.
Perhaps something like this:

#if defined(KWSYS_CP_UTF8)
  QTextCodec* utf8_codec = QTextCodec::codecForName(UTF-8);
  QTextCodec::setCodecForLocale(utf8_codec);
#if QT_VERSION  0x05
  QTextCodec::setCodecForCStrings(utf8_codec);
  QTextCodec::setCodecForTr(utf8_codec);
#endif
#endif

Does that compile for you?

Clint
-- 

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/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Review request: fix-Qt5-windows-build

[Clinton Stimpson]

On Wednesday, March 12, 2014 05:50:09 PM Stephen Kelly wrote:
 Clinton Stimpson wrote:
  I personally would prefer a Qt version check
 
 This compiles:
 
  diff --git a/Source/QtDialog/CMakeSetup.cxx
 b/Source/QtDialog/CMakeSetup.cxx
  index 995929e..d1fbe9f 100644
  --- a/Source/QtDialog/CMakeSetup.cxx
  +++ b/Source/QtDialog/CMakeSetup.cxx
  @@ -79,12 +79,14 @@ int main(int argc, char** argv)
 
QApplication app(argc, argv);
 
  -#if defined(KWSYS_CP_UTF8)
  +// #if defined(KWSYS_CP_UTF8)
QTextCodec* utf8_codec = QTextCodec::codecForName(UTF-8);
  -  QTextCodec::setCodecForCStrings(utf8_codec);
QTextCodec::setCodecForLocale(utf8_codec);
  +#if QT_VERSION  QT_VERSION_CHECK(5, 0, 0)
  +  QTextCodec::setCodecForCStrings(utf8_codec);
QTextCodec::setCodecForTr(utf8_codec);
  #endif
  +// #endif
 
// clean out standard Qt paths for plugins, which we don't use anyway
// when creating Mac bundles, it potentially causes problems
 
 
 but I don't think it's better, I didn't runtime-test it, and I don't know
 what would trigger the KWSYS_CP_UTF8 to be defined anyway as it is not on my
 system. I just wanted to compile-out the new code.
 
 If you can runtime-test the behavior of the new lines with Qt 5, I'd say go
 ahead and commit that.
 

Thanks.  I can also do a runtime check on this code with Qt5.

By the way, can you confirm that you are not currently seeing compile errors?  
I don't think anyone would see these compile errors unless they manually add a 
cmake variable to the cache to enable the utf-8 encoding.

Are you concerned because you saw Qt4 apis by visual inspection?

Clint
-- 

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/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Question regarding [58e3d49] MSVC: Fix encoding of Visual Studio 10+ project files

[Clinton Stimpson]

On Thursday, March 06, 2014 11:09:24 AM Dominik Bernhardt wrote:
 Hi,
 
 I have a question regarding the change [58e3d49] that changed the
 encoding of generated visual studio project files from utf-8 to
 Windows-1252.
 Although the encoding header in the generated xml file was changed the
 files are still written as utf. Visual Studio does not complain about
 that fact. However If I try to parse the xml file with some other xml
 parsers they will complain about that encoding mismatch.
 What was the reason to change the encoding from utf-8 to Windows-1252?
 
 Dominik

Hi,

CMake's internal encoding on Windows is currently ANSI, not UTF-8.
So the generated xml file should actually be ANSI, even if the xml header used 
to say UTF-8.

I do realize that setting the encoding to Windows-1252 encoding is not 
entirely correct, even for ANSI, but it was an improvement.  Previously, only 
the 7-bit ASCII subset of strings were allowed to be written out by CMake to 
the xml file with a utf-8 header, and still have a valid xml file.

With that commit, a the larger 8-bit Latin-1 set of characters can be written 
out and still have a valid xml file, which helps the Western European 
languages, but still not other parts of the world.  The other parts of the 
world should still have the same limitation as before, when the header said it 
was a UTF-8 file.

There has been work going into CMake to support a UTF-8 encoding on Windows, 
but it is not complete.

- Clint
-- 

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] WG: [CMake] CMake 2.8.12.201401116 is much slower than 2.8.12.1

[Clinton Stimpson]

On Wednesday, January 29, 2014 02:35:53 PM Dominik Bernhardt wrote:
  -Urspruengliche Nachricht-
  Von: Clinton Stimpson [mailto:clin...@elemtech.com]
  Gesendet: Dienstag, 21. Januar 2014 16:10
  An: cmake-developers@cmake.org
  Cc: Bill Hoffman; Dominik Bernhardt
  Betreff: Re: [cmake-developers] [CMake] CMake 2.8.12.201401116 is
  much slower than 2.8.12.1
 
 [...]
 
  I'm surprised how this small change added a 20% slowdown.
  -set_property(DIRECTORY APPEND PROPERTY COMPILE_DEFINITIONS_DEBUG
  QT_DEBUG)
  +set_property(DIRECTORY APPEND PROPERTY COMPILE_DEFINITIONS $$NOT:
  $CONFIG:Debug:QT_NO_DEBUG)
  
  I tried this project on Windows with CMake master (my own build) and
  CMake (kitware build) and CMake master was slightly faster, then
  modifying UseQt.cmake made it slightly faster still.
  
  Dominik, if you are seeing a massive slowdown, can you narrow it down?
  It may not be generator expression related at all.
 
 I just tested it again with the latest master from today. For my
 particular project the configure step with the current master takes
 290s. If I only replace the UseQt4.cmake in the master with the
 version from 2.8.12.1 the configure time goes down to 23s!!
 I'm also surprised that such a tiny change results in a slowdown of
 more than 1000%. But at least in my setup this is the case.

Can you try the attached modifications to Qt4Macros.cmake to see if it helps 
you?  And make sure you try it with the restored UseQt4.cmake file.

Clint
diff --git a/Modules/Qt4Macros.cmake b/Modules/Qt4Macros.cmake
index fd9819f..d1aaed1 100644
--- a/Modules/Qt4Macros.cmake
+++ b/Modules/Qt4Macros.cmake
@@ -84,19 +84,19 @@ macro (QT4_GET_MOC_FLAGS _moc_flags)
   foreach(_current ${_inc_DIRS})
 if(${_current} MATCHES \\.framework/?$)
   string(REGEX REPLACE /[^/]+\\.framework  framework_path 
${_current})
-  set(${_moc_flags} ${${_moc_flags}} -F${framework_path})
+  list(APPEND ${_moc_flags} -F${framework_path})
 else()
-  set(${_moc_flags} ${${_moc_flags}} -I${_current})
+  list(APPEND ${_moc_flags} -I${_current})
 endif()
   endforeach()
 
   get_directory_property(_defines COMPILE_DEFINITIONS)
   foreach(_current ${_defines})
-set(${_moc_flags} ${${_moc_flags}} -D${_current})
+list(APPEND ${_moc_flags} -D${_current})
   endforeach()
 
   if(Q_WS_WIN)
-set(${_moc_flags} ${${_moc_flags}} -DWIN32)
+list(APPEND ${_moc_flags} -DWIN32)
   endif()
 
 endmacro()
-- 

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] [CMake] CMake 2.8.12.201401116 is much slower than 2.8.12.1

[Clinton Stimpson]

On Thursday, January 16, 2014 08:41:58 AM Clinton Stimpson wrote:
 On Thursday, January 16, 2014 10:14:32 AM Bill Hoffman wrote:
  Moving this to cmake-developers list:
  
  On 1/16/2014 9:55 AM, Clinton Stimpson wrote:
   On one of my projects, I see ~3.0 seconds for CMake 2.8.12 and ~3.8
   seconds
   for CMake master.  I don't have an idea why, but with my test, it
   doesn't
   see like much slower.
  
  3.8 from 3.0 is much slower in my book  :)
  
  change it to minutes... 3 minutes vs 3.8 minutes is a big jump...
  
  Looking at the test timing on the bootstrap test on a slow machine, this
  seems to be a point that got slower:
  
  http://open.cdash.org/testDetails.php?test=229000913build=3172685   885
  seconds
  http://open.cdash.org/testDetails.php?test=229192425build=3173776   902
  seconds
  
  -Bill
 
 For this one project I got 3.0 seconds - 3.8 seconds.
 I narrowed it down to this commit:
 
 commit 2509c7678feb2efab79a384fd0b0b35cee8d02b0
 Author: Stephen Kelly steve...@gmail.com
 Date:   Mon Jan 13 13:04:03 2014 +0100
 Qt4: Use generator expression in COMPILE_DEFINITIONS (#14692)
 
 
 
 
 I'm surprised how this small change added a 20% slowdown.
 -set_property(DIRECTORY APPEND PROPERTY COMPILE_DEFINITIONS_DEBUG QT_DEBUG)
 +set_property(DIRECTORY APPEND PROPERTY COMPILE_DEFINITIONS $$NOT:
 $CONFIG:Debug:QT_NO_DEBUG)

I tried this project on Windows with CMake master (my own build) and CMake 
(kitware build) and CMake master was slightly faster, then modifying 
UseQt.cmake made it slightly faster still.

Dominik, if you are seeing a massive slowdown, can you narrow it down?
It may not be generator expression related at all.

-Clint
-- 

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] [CMake] CMake 2.8.12.201401116 is much slower than 2.8.12.1

[Clinton Stimpson]

On Thursday, January 16, 2014 10:14:32 AM Bill Hoffman wrote:
 Moving this to cmake-developers list:
 
 On 1/16/2014 9:55 AM, Clinton Stimpson wrote:
  On one of my projects, I see ~3.0 seconds for CMake 2.8.12 and ~3.8
  seconds
  for CMake master.  I don't have an idea why, but with my test, it doesn't
  see like much slower.
 
 3.8 from 3.0 is much slower in my book  :)
 
 change it to minutes... 3 minutes vs 3.8 minutes is a big jump...
 
 Looking at the test timing on the bootstrap test on a slow machine, this
 seems to be a point that got slower:
 
 http://open.cdash.org/testDetails.php?test=229000913build=3172685   885
 seconds
 http://open.cdash.org/testDetails.php?test=229192425build=3173776   902
 seconds
 
 -Bill

For this one project I got 3.0 seconds - 3.8 seconds.
I narrowed it down to this commit:

commit 2509c7678feb2efab79a384fd0b0b35cee8d02b0
Author: Stephen Kelly steve...@gmail.com
Date:   Mon Jan 13 13:04:03 2014 +0100
Qt4: Use generator expression in COMPILE_DEFINITIONS (#14692)




I'm surprised how this small change added a 20% slowdown.
-set_property(DIRECTORY APPEND PROPERTY COMPILE_DEFINITIONS_DEBUG QT_DEBUG)
+set_property(DIRECTORY APPEND PROPERTY COMPILE_DEFINITIONS $$NOT:
$CONFIG:Debug:QT_NO_DEBUG)

-- 
Clinton Stimpson
Elemental Technologies, Inc
Computational Simulation Software, LLC
www.csimsoft.com
-- 

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] [CMake] CMake 2.8.12.201401116 is much slower than 2.8.12.1

[Clinton Stimpson]

On Thursday, January 16, 2014 11:49:58 AM Ben Boeckel wrote:
 On Thu, Jan 16, 2014 at 08:41:58 -0700, Clinton Stimpson wrote:
  I'm surprised how this small change added a 20% slowdown.
  -set_property(DIRECTORY APPEND PROPERTY COMPILE_DEFINITIONS_DEBUG
  QT_DEBUG)
  +set_property(DIRECTORY APPEND PROPERTY COMPILE_DEFINITIONS $$NOT:
  $CONFIG:Debug:QT_NO_DEBUG)
 
 There's a lot of places where std::string gets passed as a const char*
 only to be turned back into a std::string in the function. Would it be
 worth me trying to resurrect that branch again? It wasn't worth much
 last I tried, but that was before a lot of the generator expression
 stuff was added.
 
 I guess another question is whether the genex is evaluated once or
 per-target (I'd guess the latter which might be the reason especially if
 Qt4 is found at the top-level of a larger project).


From a bit of profiling, std::string construction did take a sizable amount of 
time, but its not clear how much of that was redundant.

However, the profile of my test case showed that the time increase is in the 
parser (yylex).  Perhaps someone else can look further into this.

Clint
-- 

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] [CMake 0014692]: UseQt4.cmake does not adhere to policy CMP0043

[Clinton Stimpson]

On Friday, January 10, 2014 11:14:11 AM Brad King wrote:
 On 01/10/2014 11:10 AM, Clinton Stimpson wrote:
  Well, I was getting those warnings because I was using UseQt4.cmake.
  I think I was getting it for every target that inherited settings from
  UseQt4.cmake.
  So in my case, it is directly related to the bug.
 
 Ahh, okay.  Once UseQt4 is fixed those should go away.
 
 However, did anything point at UseQt4 as the culprit? 

Nope.  Not at all.

The file is included like so
INCLUDE(${QT_USE_FILE})

and that inclusion could have been done in the current CMakeLists.txt file, or 
by any parent, grand-parent CMakeLists.txt file.

But the error message is emitted by targets that have the property inherited 
from the directory scope.

So, there is no indication in the error message what the culprit was.

 Could the
 messages have been collapsed somehow to be less overwhelming (though
 each needs its own stack trace)?  These kinds of things have a great
 impact on user perception.

Having it collapsed would help, but I think its a bigger issue that the 
culprit wasn't identified by the error message.

-- 
Clinton Stimpson
Elemental Technologies, Inc
Computational Simulation Software, LLC
www.csimsoft.com
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] Cmake configure unicode?

[clinton]

If you want cmake to support unicode with configure_file right now, use utf-8, 
not utf-16.
I just tried with a utf-8 file with various non-ascii characters on Windows and 
configure_file() works for me.

From your use of cmd /U, it appears you are attempting to do utf-16 (which 
is what Microsoft means when they say Unicode), which CMake doesn't support.

Support for looking for a BOM in a CMakeLists.txt file was added recently, and 
it throws an error for utf-16/utf-32 files.
Perhaps future versions of CMake will look at the BOM when using 
configure_file, and I assume it will throw an error on your utf-16 files as 
well instead of giving you garbage.

Clint

- Original Message -
 is there a wish list of features for 3.0?
 
  * unicode support
   * offer commands available with 'cmake -e ' as direct commands
 (I think that's the option... copy_if_different ?)  or did I just not
 find the alias?
 
 On Thu, Oct 10, 2013 at 5:36 AM, Brad King brad.k...@kitware.com wrote:
  On 10/10/2013 12:34 AM, J Decker wrote:
  Should cmake be able to configure unicode, if the unicode file has
  appropriate byte order indicators maybe?
 
  Not currently.  No effort has been made to support BOMs, encoding,
  etc. except that CTest expects UTF-8 output from tests and submits
  that to CDash in the xml files.
 
  -Brad
 --
 
 Powered by www.kitware.com
 
 Visit other Kitware open-source projects at
 http://www.kitware.com/opensource/opensource.html
 
 Please keep messages on-topic and check the CMake FAQ at:
 http://www.cmake.org/Wiki/CMake_FAQ
 
 Follow this link to subscribe/unsubscribe:
 http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
 
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] Possible issue with UseQt4.cmake

[clinton]

- Original Message -
 I noticed today that the UseQt4 module appends a lot of different data
 to the COMPILE_DEFINITIONS property via add_definitions but appends
 only one item to various COMPILE_DEFINITIONS_CONFIG properties.
 
 Is this a bug in the UseQt4 module?

I don't think that is a bug.

 
 The reason I ran across this possible issue is I am implementing a new
 version of the UseQt4 module that communicates its compile definition
 results and its include_directory results via variables rather than
 setting directory properties (which is way too blunt an instrument for
 PLplot needs since that method affects every compilation in PLplot,
 not just the minority of Qt-related ones).

These situations is why I like the target usage requirements, which could make 
UseQt4.cmake, or perhaps any Use*.cmake obsolete.
http://community.kde.org/Frameworks/Epics/CMake_target_usage_requirements

Clint
--

Powered by www.kitware.com

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

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

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

[cmake-developers] help with cdash failure

[Clinton Stimpson]

I assume these new failures are mine, but cannot reproduce it.
http://open.cdash.org/testDetails.php?test=222455969build=3128109
http://open.cdash.org/testDetails.php?test=222466359build=3128147

I've tried on Windows 7 with MSVC 2012 and 2005, debug and release.

Can someone check why the test timeouts with no output?

Clint
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] help with cdash failure

[Clinton Stimpson]

On Friday, December 06, 2013 03:17:44 PM Brad King wrote:
 On 12/06/2013 01:41 PM, Clinton Stimpson wrote:
  I assume these new failures are mine, but cannot reproduce it.
  http://open.cdash.org/testDetails.php?test=222455969build=3128109
  http://open.cdash.org/testDetails.php?test=222466359build=3128147
 
 The failure was dependent on registry content.  This fixes it:
 
  cmFindPackageCommand: Fix RegEnumValueW data size computation
  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=283c0a7e
 
 Unfortunately I had to kill the dash2win64 continuous for today so
 I could reproduce it in that tree.  It will resume again tomorrow.
 

Thanks for looking into that.

Clint
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] Cross compiling toolchain variables

[clinton]

- Original Message -
 On 10/30/2013 05:27 PM, Stephen Kelly wrote:
  Brad King wrote:
  I want to make sure that downstream uses the same GL headers and libraries
  as the ones used to build Qt itself. The PATHS is populated with
  information
  from qmake, and I wanted to prevent cmake finding different headers and
  libraries.
  
  I've just staged a patch to remove that behavior for mac though:
  
   https://codereview.qt-project.org/#change,69605
 
 Can you point me to the source of the qmake logic that uses -isysroot
 plus paths not inside the SDK?  I'd like to understand why qmake is
 generating paths that don't actually exist and depend on -isysroot
 to be found, or if I'm misunderstanding your explanation.

I don't think you'll find that in the source of qmake as Qt doesn't require 
anything outside the SDK.  Paths in the Qt build files (see 
qtbase/mkspects/common/mac.conf) such as 
/System/Library/Frameworks/OpenGL.framework/Headers are rerooted to the SDK by 
qmake for compiling.  That is, it becomes 
-I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/OpenGL.framework/Versions/A/Headers.

Also, any user of Qt also using something outside the SDK has to give the -F 
compile flag themselves.

 
  Ok. I thought a mac sdk was 'isolated' and self-contained as far as system
  APIs are concerned (which seems similar to CMAKE_SYSROOT). Where does the
  isolation break-down? Honestly I don't see much of a distinction.
 
 The main problem is that the two of us are not educated enough in the
 ways of Mac development to have this debate ;)
 
 I suppose with the default root path mode of searching re-rooted
 paths and then the original paths then treating the OSX SDK path as
 one of the rerooting prefixes makes sense.  That way any library
 provided by the system SDK will be found for the proper target
 version and otherwise the search will fall back to looking elsewhere.
 
 We'll have to resolve this while combining CMAKE_SYSROOT and
 CMAKE_OSX_SYSROOT.
 

With Mac OS X 10.9, frameworks under /System/Library/Frameworks no longer 
include header files (except for a few such as python).
That basically means the SDK needs to be used instead of things under 
/System/Library/Frameworks.
The same goes for the now empty /usr/include.

I can also reproduce the error here:
https://bugreports.qt-project.org/browse/QTBUG-32308
This is with qtbase at 569dec8e.

Clint
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] CMake 2.8.12 transitive link regression?

[Clinton Stimpson]

On Monday, November 04, 2013 09:48:57 AM Brad King wrote:
 On 11/02/2013 07:29 AM, Brad King wrote:
  Policy CMP0022's NEW behavior is supposed to be that the
  link interface is exactly specified by INTERFACE_LINK_LIBRARIES.
  Therefore in this case the plain tll signature should go
  ahead and populate *both* INTERFACE_LINK_LIBRARIES *and*
  LINK_LIBRARIES.
 
 After working through the details of this over the weekend
 the fix and a bunch of tests are now in master.  It ended
 up taking several commits.  The main one is:
 
  CMP0022: Plain target_link_libraries must populate link interface
  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ef10b87c
 
 Two other important changes are:
 
  Do not export INTERFACE_LINK_LIBRARIES from non-linkable targets
  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=23d21b78
 
  CMP0022: Warn about a given target at most once
  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0a561a03
 
 I plan to include all this in 2.8.12.1.  Please test ASAP.
 
 Thanks,
 -Brad

The problem I reported before indeed appears fixed.

But I see 2 others new problems.


1)
cmake_minimum_required(VERSION 2.8)
add_library(foo SHARED foo.cpp)
add_library(bar SHARED bar.cpp)
target_link_libraries(bar foo)
set_target_properties(bar PROPERTIES LINK_INTERFACE_LIBRARIES )
add_executable(exe exe.cpp)
target_link_libraries(exe bar)


With 2.8.12.1, I now get a new warning that I did not get with 2.8.12.  I'm 
not sure why I'm getting that warning because the linking of exe looks 
correct.

CMake Warning (dev) in CMakeLists.txt:
  Policy CMP0022 is not set: INTERFACE_LINK_LIBRARIES defines the link
  interface.  Run cmake --help-policy CMP0022 for policy details.  Use the
  cmake_policy command to set the policy and suppress this warning.

  Target bar has an INTERFACE_LINK_LIBRARIES property which differs from
  its LINK_INTERFACE_LIBRARIES properties.
  INTERFACE_LINK_LIBRARIES:
foo
  LINK_INTERFACE_LIBRARIES:



2)
cmake_minimum_required(VERSION 2.8.12)
add_library(foo SHARED foo.cpp)
add_library(bar SHARED bar.cpp)
target_link_libraries(bar foo)
set_target_properties(bar PROPERTIES LINK_INTERFACE_LIBRARIES )
add_executable(exe exe.cpp)
target_link_libraries(exe bar)

I get no warning or error, but my LINK_INTERFACE_LIBRARIES property was not 
respected and it linked both foo and bar into exe.  This appears to be a 
regression from 2.8.12 to 2.8.12.1.


-- 
Clinton Stimpson
Elemental Technologies, Inc
Computational Simulation Software, LLC
www.csimsoft.com
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] CMake 2.8.12 transitive link regression?

[Clinton Stimpson]

On Monday, November 04, 2013 10:40:15 AM Brad King wrote:
 On 11/04/2013 10:31 AM, Clinton Stimpson wrote:
  But I see 2 others new problems.
 
 Those are features and they work together as intended.
 
  1)
  cmake_minimum_required(VERSION 2.8)
  add_library(foo SHARED foo.cpp)
  add_library(bar SHARED bar.cpp)
  target_link_libraries(bar foo)
  set_target_properties(bar PROPERTIES LINK_INTERFACE_LIBRARIES )
  add_executable(exe exe.cpp)
  target_link_libraries(exe bar)
  
  With 2.8.12.1, I now get a new warning that I did not get with 2.8.12. 
  I'm
  not sure why I'm getting that warning because the linking of exe looks
  correct.
  
  CMake Warning (dev) in CMakeLists.txt:
Policy CMP0022 is not set: INTERFACE_LINK_LIBRARIES defines the link
interface.  Run cmake --help-policy CMP0022 for policy details.  Use
the
cmake_policy command to set the policy and suppress this warning.

Target bar has an INTERFACE_LINK_LIBRARIES property which differs from
its LINK_INTERFACE_LIBRARIES properties.

INTERFACE_LINK_LIBRARIES:
  foo

LINK_INTERFACE_LIBRARIES:
 This is a correct warning according to the definition of CMP0022.
 The bug you reported in 2.8.12.0 also caused it to not warn here.
 Prior to my fix CMake did not track the new INTERFACE_LINK_LIBRARIES
 value correctly for the plain tll signature so it didn't realize
 that things would change and therefore did not warn.
 
  2)
  cmake_minimum_required(VERSION 2.8.12)
  add_library(foo SHARED foo.cpp)
  add_library(bar SHARED bar.cpp)
  target_link_libraries(bar foo)
  set_target_properties(bar PROPERTIES LINK_INTERFACE_LIBRARIES )
  add_executable(exe exe.cpp)
  target_link_libraries(exe bar)
  
  I get no warning or error, but my LINK_INTERFACE_LIBRARIES property was
  not
  respected and it linked both foo and bar into exe.  This appears to be a
  regression from 2.8.12 to 2.8.12.1.
 
 This is also correct behavior.  The NEW behavior of CMP0022
 is to ignore LINK_INTERFACE_LIBRARIES and use the new
 INTERFACE_LINK_LIBRARIES which is now populated by the tll call.
 
 The warning you get when the policy is not set is telling
 you exactly what will change when the policy is set to NEW.
 Therefore it gives you a chance to fix your code before setting
 the policy (by bumping the min req version or explicitly).
 
 This is exactly how policies are intended to work.  It was
 very unfortunate that 2.8.12.0 was released without giving
 projects any release candidates with a correct CMP0022 impl.


Ok.  Yes, that threw me off when the cmp0022 behavior wasn't correct in 
2.8.12.0.  And I agree that it is fixed in 2.8.12.1.

Thanks,
Clint
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] CMake 2.8.12 transitive link regression?

[Clinton Stimpson]

On Monday, November 04, 2013 09:16:11 AM Clinton Stimpson wrote:
 On Monday, November 04, 2013 10:40:15 AM Brad King wrote:
  On 11/04/2013 10:31 AM, Clinton Stimpson wrote:
   But I see 2 others new problems.
  
  Those are features and they work together as intended.
  
   1)
   cmake_minimum_required(VERSION 2.8)
   add_library(foo SHARED foo.cpp)
   add_library(bar SHARED bar.cpp)
   target_link_libraries(bar foo)
   set_target_properties(bar PROPERTIES LINK_INTERFACE_LIBRARIES )
   add_executable(exe exe.cpp)
   target_link_libraries(exe bar)
   
   With 2.8.12.1, I now get a new warning that I did not get with 2.8.12.
   I'm
   not sure why I'm getting that warning because the linking of exe looks
   correct.
   
   CMake Warning (dev) in CMakeLists.txt:
 Policy CMP0022 is not set: INTERFACE_LINK_LIBRARIES defines the link
 interface.  Run cmake --help-policy CMP0022 for policy details.  Use
 the
 cmake_policy command to set the policy and suppress this warning.
 
 Target bar has an INTERFACE_LINK_LIBRARIES property which differs
 from
 its LINK_INTERFACE_LIBRARIES properties.
 
 INTERFACE_LINK_LIBRARIES:
   foo
 
 LINK_INTERFACE_LIBRARIES:
  This is a correct warning according to the definition of CMP0022.
  The bug you reported in 2.8.12.0 also caused it to not warn here.
  Prior to my fix CMake did not track the new INTERFACE_LINK_LIBRARIES
  value correctly for the plain tll signature so it didn't realize
  that things would change and therefore did not warn.
  

And I think that is part of why I submitted bug 
http://cmake.org/Bug/view.php?id=14512
where I was not getting a warning when I should have.  It was possible to go 
from CMake 2.8.10 to CMake 2.8.12 and not get any warning about behavior 
change.

Thanks for fixing this.

Clint


--

Powered by www.kitware.com

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

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

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

[cmake-developers] CMake unicode support

[clinton]

Hi All, 

I've started some work towards supporting Unicode in CMake so I could get 
better support for building/testing our internationalized applications. 
https://github.com/clintonstimpson/CMake/commit/f08ca2ff65f434b2bc404000765a836880f78f0e
 

It keeps char* / std::string throughout the code where utf-8 is assumed on 
Windows and the current encoding on other platforms (usually utf-8). 
Conversions to wchar_t are done on demand when calling Windows apis. In other 
words, its mainly just a change to move towards unicode aware apis on Windows. 
It calls the wide version of Windows apis explicitly, so it does not matter 
whether one is compiling with -DUNICODE/-D_UNICODE or not. I assumed Win9x 
support is no longer needed, so there was no attempt to enable calling the old 
ANSI version of the apis. 

I haven't gotten as far as I hoped because of unicode limitations in Visual 
Studio. For example, custom commands in visual studio executed with cmd.exe has 
problems with encoding. When I reported this to Microsoft, they said it works 
better on Windows 8, but I don't have that right now. I was able to make my own 
utf-8 .bat files and call cmd.exe (with appropriate settings) myself and it 
worked just fine. Somehow, its different when Visual Studio does the same for 
custom commands. 

Any feedback or patches would be appreciated. For instance, std::ifstream/std:: 
ofstream/fopen need to be done special, and maybe some of you would prefer to 
have a wrapper for that. 

There are plenty of changes in KWSys so the patch probably needs to be split 
up. 

Although probably not an entire solution, it gets us part of the way there. I 
think this scope of changes can be merged in and further work done later which 
can include others. Overall, these changes don't really change the programs 
behavior except that some things which have already been working on other 
platforms start to work on Windows. 

Clint 
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] [CMake] CMake 2.8.12-rc2 FindHDF5 issues

[Clinton Stimpson]

On Thursday, September 19, 2013 01:47:23 PM Brad King wrote:
 On 09/17/2013 06:16 PM, Clinton Stimpson wrote:
  I've narrowed it down to a regression caused by 04d4dc33.
 
 The following should fix this:
 
  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0f05961f
 
 See the commit message for an explanation.
 
 Please test and let me know.
 
 Thanks,
 -Brad

It fixed my simple test case.

-- 
Clinton Stimpson
Elemental Technologies, Inc
Computational Simulation Software, LLC
www.csimsoft.com
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] [CMake] CMake 2.8.12-rc2 Released

[clinton]

Same here... and this looks like a regression:

A simple CMakeLists.txt like this can reproduce it.

set(CMAKE_BUILD_TYPE Debug)
find_package(HDF5 COMPONENTS C HL REQUIRED)
add_executable(foo foo.cpp)
target_link_libraries(foo ${HDF5_LIBRARIES})

FindHDF5.cmake misuses CMAKE_BUILD_TYPE and CMAKE_CONFIGURATION_TYPES when 
assembling the HDF5_LIBRARIES variable.  If I clear out the CMAKE_BUILD_TYPE 
variable, then the problem goes away.

Clint


- Original Message -
 On 08/30/2013 02:49 PM, Robert Maynard wrote:
  The CMake 2.8.12 release candidate stream continues!
  You can find the source and binaries here:
  http://www.cmake.org/files/v2.8/?C=M;O=D
 
 Is it expected that this is now an error?
 
 CMake Error: The following variables are used in this project, but they are
 set to NOTFOUND.
 Please set them or make sure they are set and tested correctly in the CMake
 files:
 HDF5_dl_LIBRARY_DEBUG (ADVANCED)
  linked by target netcdf in directory
 /builddir/build/BUILD/netcdf-c-4.3.1-rc2/liblib
  linked by target ncgen in directory
 /builddir/build/BUILD/netcdf-c-4.3.1-rc2/ncgen
  linked by target nccopy in directory
 /builddir/build/BUILD/netcdf-c-4.3.1-rc2/ncdump
  linked by target ncdump in directory
 /builddir/build/BUILD/netcdf-c-4.3.1-rc2/ncdump
  linked by target nctestserver in directory
 /builddir/build/BUILD/netcdf-c-4.3.1-rc2/ncdap_test
 
 Something has definitely changed with handling debug CMAKE_BUILD_TYPEs
 between
 2.8.11.2 and 2.8.12-rc2.  I'm building netcdf 4.8.1-rc2 and it works fine
 with
 2.8.11.2 but I get errors like the above with 2.8.12-rc2.  We build Fedora
 packages with either the Debug or RelWithDebugInfo build types so debug info
 is generated - though it is later stripped and put into a separate -debuginfo
 sub-package.  So the debug versions of libraries are generally not available
 at build time.
 
 Could someone describe to me more of what is going on here?  There seems to
 be
 a new debug link mode or some such? I'm afraid this will be a real show
 stopper for Linux distributions.
 
 --
 Orion Poplawski
 Technical Manager 303-415-9701 x222
 NWRA, Boulder/CoRA Office FAX: 303-415-9702
 3380 Mitchell Lane   or...@nwra.com
 Boulder, CO 80301   http://www.nwra.com
 --
 
 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://www.cmake.org/mailman/listinfo/cmake
 
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] [CMake] CMake 2.8.12-rc2 FindHDF5 issues

[Clinton Stimpson]

On Tuesday, September 17, 2013 04:01:30 PM Orion Poplawski wrote:
 On 09/16/2013 09:58 PM, clin...@elemtech.com wrote:
  Same here... and this looks like a regression:
  
  A simple CMakeLists.txt like this can reproduce it.
  
  set(CMAKE_BUILD_TYPE Debug)
  find_package(HDF5 COMPONENTS C HL REQUIRED)
  add_executable(foo foo.cpp)
  target_link_libraries(foo ${HDF5_LIBRARIES})
  
  FindHDF5.cmake misuses CMAKE_BUILD_TYPE and CMAKE_CONFIGURATION_TYPES when
  assembling the HDF5_LIBRARIES variable.  If I clear out the
  CMAKE_BUILD_TYPE variable, then the problem goes away.
  
  Clint
 
 cmake 2.8.11.2:
 
 -- Found HDF5:
 debug;/usr/lib64/libz.so;debug;/usr/lib64/libdl.so;debug;/usr/lib64/libm.so;
 debug;/usr/lib64/libhdf5_hl.so;debug;/usr/lib64/libhdf5.so;optimized;/usr/li
 b64/libz.so;optimized;/usr/lib64/libdl.so;optimized;/usr/lib64/libm.so;optim
 ized;/usr/lib64/libhdf5_hl.so;optimized;/usr/lib64/libhdf5.so
 
 cmake 2.8.12-rc2:
 
 -- Found HDF5:
 debug;HDF5_hdf5_LIBRARY_DEBUG-NOTFOUND;debug;HDF5_z_LIBRARY_DEBUG-NOTFOUND;d
 ebug;HDF5_dl_LIBRARY_DEBUG-NOTFOUND;debug;HDF5_m_LIBRARY_DEBUG-NOTFOUND;debu
 g;HDF5_hdf5_hl_LIBRARY_DEBUG-NOTFOUND;debug;HDF5_hdf5_LIBRARY_DEBUG-NOTFOUND
 ;optimized;/usr/lib64/libz.so;optimized;/usr/lib64/libdl.so;optimized;/usr/l
 ib64/libm.so;optimized;/usr/lib64/libhdf5_hl.so;optimized;/usr/lib64/libhdf5
 .so
 
 
 In comparing the CMakeCache:
[ snip ]
 
 As Rolf noted, FindHDF5 has not changed.

Right, it hasn't changed.

I've narrowed it down to a regression caused by 04d4dc33.
Will Dicharry, is this something you can look at?  You are the maintainer for 
both FindHDF5 and SelectLibraryConfigurations.  A change in 
SelectLibraryConfigurations caused a break in FindHDF5.

Clint

--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] compile-defs-debugging and framework-interface-includes

[clinton]

- Original Message -
 
 Hi there,
 
 compile-defs-debugging is failing with some Visual Studio generators. I
 don't have those ides to figure out what is going wrong. My reading of the
 Preprocessor test indicates that if my new test fails, that one should too,
 so I don't understand where the problem is.
 
 The framework-interface-includes test is also failing on all macs, after I
 changed it to use a regex to match a framework. I don't have ready access to
 a mac for a few days to find out what is wrong there.
 
 Can I get some help with those issues?
 
 Thanks,
 
 Steve.
 

I've pushed a fix for you on stage/framework-interface-includes.

Clint
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] [CMake 0014274]: QtDialog Compiler Chooser Should Not Resolve Symlinks

[clinton]

- Original Message -
 Clinton,
 
 On 07/06/2013 07:09 AM, Mantis Bug Tracker wrote:
  http://www.cmake.org/Bug/view.php?id=14274
 
 The qtdialog-symlinks topic on the stage appears to be meant for this
 but has not been merged to 'next' for testing.  Did you mean to?  Please
 merge or remove it from the stage.
 

It was on stage so I could test on different operating systems.  But it didn't 
solve the problem so I'll remove it from stage.

Clint
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] rpath-on-mac topic

[clinton]

- Original Message -
 Clinton,
 
 On 07/17/2013 01:07 AM, Clinton Stimpson wrote:
  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=90993b9016abf241cd0a4de71e76eb738202c136
  commit 90993b9016abf241cd0a4de71e76eb738202c136
  Author: Clinton Stimpson clin...@elemtech.com
  AuthorDate: Tue Jul 16 23:01:50 2013 -0600
  Commit: Clinton Stimpson clin...@elemtech.com
  CommitDate: Tue Jul 16 23:05:28 2013 -0600
  
  ninja, OS X: fix regression handling frameworks
  
  Since the ninja file isn't aware of how framework symlinks work,
  we suppress symlink creation and let cmOSXBundleGenerator handle it.
  Also, use the real name of framework library in build rules as was done
  before,
  instead of the symlink.
 
 Should this be squashed into its parent or is this fixing a regression
 that was introduced earlier and exposed by the parent commit?  If the
 latter, please update the commit message to explain when the regression
 was introduced since it is already in master.
 
 Thanks,
 -Brad
 

It exposed a regression in a parent commit.  I've updating the commit message 
to give the parent commit with the regression.

Clint
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] CMAKE_SYSROOT vs CMAKE_OSX_SYSROOT

[clinton]

- Original Message -
 On 07/11/2013 10:41 AM, clin...@elemtech.com wrote:
  They also appear similar to me, so I would start with the
  assumption that they should be unified.
 
 I just dug into this a bit.
 
 One difference is that CMAKE_OSX_SYSROOT can be set to a logical
 SDK name rather than a path.  In Darwin.cmake there is code to
 transform it to a path by running
 
  xcodebuild -sdk ${CMAKE_OSX_SYSROOT} -version Path
 
 If we unify the two we will need to find a way to handle this.
 
 The value of CMAKE_OSX_SYSROOT is not used in any CMake modules
 outside of Darwin.cmake (and an old reference in Darwin-icc.cmake
 that should probably be refactored anyway).  It is used in only
 three C++ sources:
 
 * cmCoreTryCompile.cxx: The value of CMAKE_OSX_SYSROOT is passed
   into the build of the test project for a try-compile.  This
   will probably be needed for CMAKE_SYSROOT too.
 
 * cmGlobalXCodeGenerator.cxx: The value of CMAKE_OSX_SYSROOT is
   used to set the generated Xcode SDKROOT attribute.  The SDKROOT
   can be a logical name or a path but IIUC the logical name is
   preferred.  Xcode uses it to add the -isysroot flag.
 
 * cmLocalGenerator.cxx: The value of CMAKE_OSX_SYSROOT is used
   to add the -isysroot flags for generators besides Xcode (since
   Xcode uses the SDKROOT attribute).
 
 It looks to me like CMAKE_SYSROOT and CMAKE_OSX_SYSROOT are
 pretty much identical other than the logical name mapping.
 At a minimum we need to make them mutually exclusive (at most
 one can be set in a single build tree).  Ideally we should
 combine them so that one only needs to set CMAKE_SYSROOT on
 any platform.
 
 Combining them is safe only if we're sure CMAKE_SYSROOT will
 not be used for anything besides the toolchain system SDK.
 

I'm seeing slight hints that we should not merge them.

$ xcrun --help
  ...
  --sdk sdk name find the tool for the given SDK name
  --toolchain name   find the tool for the given toolchain
  ...

I currently have SDKs are under 
/Applications/Xcode.app/Contents/Developer/Platform
 - 10.7, 10.8, iPhoneOS6.1, iPhoneSimulator6.1

and toolchains found under /Applications/Xcode.app/Contents/Developer/Toolchains
 - XcodeDefault.xctoolchain (clang)

There's also the llvm/gcc in another place: /usr/llvm-gcc-4.2.

I'm also seeing some C/C++ includes under both the toolchain and SDK trees.
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/4.2/include/stdint.h
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/usr/include/stdint.h

The toolchain version of stdint.h includes the use of __STDC_HOSTED__, if that 
means anything here.
http://tigcc.ticalc.org/doc/cpp.html#SEC15_STDC_HOSTED

What do you think Brad?  Does it hint towards not merging them?

Clint
--

Powered by www.kitware.com

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

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

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

[cmake-developers] ninja support

[clinton]

Is there someone that can offer some ninja support? There is a regression from 
a while back exposed by a commit of mine yesterday. 
http://open.cdash.org/testDetails.php?test=199232514build=2967911 

With the framework refactor work, the soname for frameworks were fixed. As a 
result, code in the makefile generator to create symlinks was triggered. 
In the generator, it was suppressed in the case of frameworks because 
cmOSXBundleGenerator takes care of making the symlinks. 

But for the ninja generator, I just realized it isn't suppressed. And my 
attempt to fix that leads to a broken ninja file. 

Thanks, 
Clint 
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] ninja support

[clinton]

- Original Message -

 Is there someone that can offer some ninja support? There is a regression
 from a while back exposed by a commit of mine yesterday.
 http://open.cdash.org/testDetails.php?test=199232514build=2967911

 With the framework refactor work, the soname for frameworks were fixed. As a
 result, code in the makefile generator to create symlinks was triggered.
 In the generator, it was suppressed in the case of frameworks because
 cmOSXBundleGenerator takes care of making the symlinks.

 But for the ninja generator, I just realized it isn't suppressed. And my
 attempt to fix that leads to a broken ninja file.

 Thanks,
 Clint

Never mind... I've got it figured out. The ninja generator needs changed to not 
try to create symlinks and not use the framework symlink. So, the build.ninja 
files look the same as before. 
http://cmake.org/gitweb?p=cmake.git;a=commit;h=90993b 

Clint 
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] CMAKE_SYSROOT vs CMAKE_OSX_SYSROOT

[clinton]

- Original Message -
 On 7/3/2013 11:43 AM, Stephen Kelly wrote:
   To choose an SDK, you use the -isysroot option with the compiler and the -
  syslibroot option with the linker.
 [snip]
   Modules/Platform/Darwin-Clang.cmake:  set(CMAKE_${lang}_SYSROOT_FLAG
   -isysroot)
 [snip]
  I'm not familiar enough with OSX to know if the pre-existing OSX related
  sysroot features have any bearing on the new CMAKE_SYSROOT feature. Is it
  something to be concerned about? Should the features be unified? Should the
  new CMAKE_SYSROOT related variables be renamed to clarify difference?
 
 Clinton, can you comment on this?
 
 They do appear to be very similar.  Both are about the toolchain's
 system headers/libs and platform SDK location.
 

I don't really know much more than that.
They also appear similar to me, so I would start with the assumption that they 
should be unified.

Clint
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] Deprecating qt4_use_modules and qt4_automoc?

[clinton]

- Original Message -
 Stephen Kelly steveire@... writes:
  We could also probably add a runtime warning if enabled. You need to enable
  deprecation warnings with your compiler, so it would make sense to have to
  enable them with a cmake script too. CMAKE_ENABLE_DEPRECATION_WARNINGS
  could be used to determine whether to print a warning in the implementation
  of a macro or function.
 
  Comments?
 
 Bump!
 
 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/6002/focus=6004
 


What is the motivation for deprecating these?
Can we just let them fade away on their own as the world moves from Qt4 to Qt5?

Clint

--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] How should Mac frameworks work?

[Clinton Stimpson]

On Tuesday, July 02, 2013 05:12:00 PM Stephen Kelly wrote:
 Clinton Stimpson wrote:
  Yeah, I understand that is the issue.
  I don't quite get what is new for Qt 5.1.  I thought Qt 4.x only installed
  Qt headers inside the framework too.  Perhaps its new from 5.0 to 5.1?
 
 Yes.
 
  On a Mac with a prebuilt Qt 4.7
  qmake -query QT_INSTALL_HEADERS = /usr/include
  The only Qt headers under there are the headers for the QtUiTools module
  which is a static library and not a framework.
  That is why we had this in FindQt4.cmake/UseQt4.cmake
  include_directories(/path/to/QtCore.framework;/usr/include)
  which produced a -F/path/to and -I/usr/include compile flags.
 
 Ok, so maybe what I need is to add the path to the framework to the
 INTERFACE_INCLUDE_DIRECTORIES of each target?

Yes, I think that makes sense.

 
 As a feature, would it make sense to make that unnecessary in a future CMake
 version?
 

How would you make it unecessary?
Would you change CMake so the include directory would automatically be 
included for frameworks specified in target_link_libraries()?  That does sound 
like something CMake could do automatically.

Clint
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] How should Mac frameworks work?

[Clinton Stimpson]

On Monday, July 01, 2013 11:11:58 AM Brad King wrote:
 On 7/1/2013 10:08 AM, Stephen Kelly wrote:
  What path actually should be in the IMPORTED_LOCATION in order for the
  framework to be handled correctly?
 
 I don't remember for sure off the top of my head, but I think that
 the automatic -F options work when the path is /path/to/foo.framework
 but IMPORTED_LOCATION wants /path/to/foo.framework/foo.  The former
 is meant for find_* command results IIRC, and the latter was never
 meant to automatically add -F for imported targets because I didn't
 know about that feature when first working on imported frameworks.
 
 Take the above paragraph with a grain of salt because I wrote it off
 the top of my head and haven't had a chance to look at the code.
 
 Clinton, you refactored all of the internals for this recently.
 Can you comment, please?
 
 Thanks,
 -Brad

With the refactor IMPORTED_LOCATION in generated export files went from
/path/to/foo.framework/foo
to
/path/to/foo.framework/Version/A/foo
That change naturally came out of the refactor.

Since for non-frameworks, the property is the location of the actual file on 
disk, it seemed this was a good change.


However, I just realized the documentation in cmTarget says 
 For frameworks on OS X this is the location of the library file 
 symlink just inside the framework folder.  

-- 
Clinton Stimpson
Elemental Technologies, Inc
Computational Simulation Software, LLC
www.csimsoft.com
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] How should Mac frameworks work?

[Clinton Stimpson]

On Monday, July 01, 2013 07:36:24 PM Stephen Kelly wrote:
 Clinton Stimpson wrote:
  This change hasn't been released yet and will go into CMake 2.8.12.
 
 Ah, I see. I was mis-reading my gitk.
 
  If Qt were to put multiple versions of libraries into one framework, then
  I think the IMPORTED_LOCATION should be more specific.
 
 The issue is more about cmake using the correct -F and --framework flags for
 the Qt frameworks. As Qt includes are no longer installed to
 $prefix/include in the 5.1.0 RC2 (pending temporary reversal
 https://codereview.qt-project.org/#change,60232 ), and as there is no
 QtCore directory containing a QObject header, lines like
 
  #include QtCore/QObject
 
 are expected to behave in the standard way appropriate for frameworks, which
 I understand to mean:
 
  * Use -F to specify paths to look for frameworks
  * Compile with --framework QtCore
  * Look in $something/QtCore.framework/Headers for QObject to include
 
 That means that CMake is expected to generate a buildsystem which contains
 those -F and --framework flags, if I've understood everything.
 
 As far as I understand, that is not the case currently when trying to use
 CMake with the with the Qt frameworks (feel free to try the RC2 and hack
 around with the Config files).
 

Yeah, I understand that is the issue.
I don't quite get what is new for Qt 5.1.  I thought Qt 4.x only installed Qt 
headers inside the framework too.  Perhaps its new from 5.0 to 5.1?

On a Mac with a prebuilt Qt 4.7
qmake -query QT_INSTALL_HEADERS = /usr/include
The only Qt headers under there are the headers for the QtUiTools module which 
is a static library and not a framework.
That is why we had this in FindQt4.cmake/UseQt4.cmake
include_directories(/path/to/QtCore.framework;/usr/include) 
which produced a -F/path/to and -I/usr/include compile flags.

-- 
Clinton Stimpson
Elemental Technologies, Inc
Computational Simulation Software, LLC
www.csimsoft.com
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] Review request: qt4-macros-TARGET-arg

[Clinton Stimpson]

On Monday, June 03, 2013 10:09:41 AM Stephen Kelly wrote:
 Hi,
 
 I've pushed a qt4-macros-TARGET-arg branch to next. It refactors the Qt 4
 moc related macros to process a TARGET argument. The target is used as the
 source of include directories, which are then passed to moc as -I arguments.
 
 Previously, those macros read the INCLUDE_DIRECTORIES directory property,
 which is populated by the include_directories() command. So, this patch to
 the macros makes it possible to not require the use of include_directories()
 anymore to use the macros.
 
 Clinton, could you take a look before I merge to next please?
 

Looks good to me.

-- 
Clinton Stimpson
Elemental Technologies, Inc
Computational Simulation Software, LLC
www.csimsoft.com
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] [CMake] BundleUtilities and @rpath

[Clinton Stimpson]

Jc,

I see some good things in this topic.

A few questions I have:

GP_RPATH_DIR is set to ${bundle}/Contents.  What about other platforms such as 
Linux?  And what about Windows where the executable directory could be 
considered an rpath directory along with a few other directories that the 
Windows loader looks at.

And what if there are multiple rpath directories?  I had a case where a plugin 
had 2 rpath directories for dependencies, as some dependencies could be local, 
and some in a common directory.
Even on Windows, the executable could be in the common directory, and the 
plugin and some of its dependencies in another.  The loader on Windows has 
builtin paths for finding dependencies that include the executable directory 
and the plugin directory.  The same layout can be done on Mac and Linux with 
rpaths.

So, I don't see how the topic fully captures rpath behavior, or is it meant to 
be specific to simpler use cases?  However, I will admit that BundleUtilities 
was already specific to simpler use cases when it was just @executable_path and 
@loader_path.


Perhaps related, is a topic of mine in stage/rpath-on-mac.  It gives rpath 
support in the build/install tree much like one gets on other Unix platforms.

With that, you can compile code on Mac such that it already has @rpath and 
there is less or zero fixup necessary at install time.  The hope is that CMake 
will adopt this as the default behavior on Mac.  The only potential fixup 
necessary is external libraries that are not system libraries, but only if 
they don't use @rpath.

For my 3rd party libraries, I could decide to run install_name_tool to change 
them to use @rpath before compiling my code.
Or a script could do the same at install time.  For one app, I had written 
some basic scripts to use instead of BundleUtilties.  This freed me from the 
complexity required to also support @executable_path and @loader_path, but it 
wasn't matured enough to validate the completeness of the package/bundle.

Have you seen this thread?
http://public.kitware.com/pipermail/cmake-developers/2011-November/002572.html

So, a question I have for you is how do you think stage/rpath-on-mac could 
affect your topic?

Clint

On Thursday, May 16, 2013 07:57:01 PM Jean-Christophe Fillion-Robin wrote:
 Hi Clinton,
 
 This is to create bundle that use @rpath. Particularly useful when you want
 to support plugin.
 
 Let me know what you think, I just updated my the toy project.
 Other list of changes have been pushed into CMake stage:
 http://cmake.org/gitweb?p=stage/cmake.git;a=shortlog;h=refs/heads/tweak-bund
 leutilities-for-rpath
 
 Thanks
 Jc
 
 On Thu, May 2, 2013 at 11:51 AM, Clinton Stimpson 
clin...@elemtech.comwrote:
  On Wednesday, April 24, 2013 06:45:11 PM Jean-Christophe Fillion-Robin
  
  wrote:
   Hi Folks,
   
   I have been working on improving BundleUtilities and GetPrerequisites
   module so that it can be used to easily fixup a MacOSX bundle using
  
  @rpath.
  
   The set of changes I would like to propose is here:
  https://github.com/jcfr/CMakeBundleUtilitiesExample/compare/f7a594ffba72b8
  cb 
   83df9a166d7887bedc49f38b...75fa538
   
   To try out the change, you could build the small project I created for
  
  that
  
   purpose: https://github.com/jcfr/CMakeBundleUtilitiesExample#readme
   
   Let me know what you think.
   
   Thanks
   Jc
  
  Is it to help make the same @executable_path based bundles but support
  copying
  in libraries and frameworks that used @rpath and change them over to be
  @executable_path based?
  
  Or is this to help create bundles that result in the use of @rpath?
  
  --
  Clinton Stimpson
  Elemental Technologies, Inc
  Computational Simulation Software, LLC
  www.csimsoft.com
  --
  
  Powered by www.kitware.com
  
  Visit other Kitware open-source projects at
  http://www.kitware.com/opensource/opensource.html
  
  Please keep messages on-topic and check the CMake FAQ at:
  http://www.cmake.org/Wiki/CMake_FAQ
  
  Follow this link to subscribe/unsubscribe:
  http://www.cmake.org/mailman/listinfo/cmake
-- 
Clinton Stimpson
Elemental Technologies, Inc
Computational Simulation Software, LLC
www.csimsoft.com
--

Powered by www.kitware.com

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

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

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

[cmake-developers] Xcode and dylib versioning

[Clinton Stimpson]

Does anyone know if/how Xcode can handle versioning of dylibs that include 
symbolic links?

When creating versioned shared libraries with Makefiles, I get the symbolic 
links.  But, I don't get that when building with Xcode.

I realize CMake generated Xcode projects don't support this, but I'm wondering 
Xcode can still do it.

Thanks,
Clint
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] Need some pointers on learning the code

[Clinton Stimpson]

On Monday, May 13, 2013 02:30:32 PM Brad King wrote:
 On 05/13/2013 02:07 PM, Robert Dailey wrote:
  Actually now that I think about this a littler closer, changing the
  generator expressions may not work for a specific case I'm blocked on.
  
  I store my third party library binaries in a debug and release
  directories. I have a custom target that I define to copy the
  appropriate debug or release DLLs to the appropriate output
  directories, so that when I debug my applications, they find the
  appropriate DLLs in the same directory. So the copy mapping should be
  as follows:
  
  debug - Debug
  release - Release
  release - RelWithDebInfo
  release - MinSizeRel
  
  Specifically for the RELEASE case. I can't use $CONFIGURATION for
  the source directory, since the name is release between all 3
  release configurations. This case is easily solved with issue 9974,
  however. Any thoughts?
 
 This looks like the common use case I explain here:
 
  http://www.cmake.org/Bug/view.php?id=9974#c29033
 
 You don't need any new features for it.

To avoid the copy step, would it be useful to make generator expressions work 
in target properties?

set_target_properties(mylib PROPERTIES
  LIBRARY_OUTPUT_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/$CONFIGURATION/lib)
set_target_properties(myexe PROPERTIES
  RUNTIME_OUTPUT_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/$CONFIGURATION/bin)

Currently, I can have more code than that to loop over 
CMAKE_CONFIGURATION_TYPES and set those properties myself, and it results in 
the libraries and executables being together without a copy step and without 
an extra config directory separating them.

Clint
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] Need some pointers on learning the code

[Clinton Stimpson]

On Monday, May 13, 2013 12:55:39 PM Clinton Stimpson wrote:
 On Monday, May 13, 2013 02:30:32 PM Brad King wrote:
  On 05/13/2013 02:07 PM, Robert Dailey wrote:
   Actually now that I think about this a littler closer, changing the
   generator expressions may not work for a specific case I'm blocked on.
   
   I store my third party library binaries in a debug and release
   directories. I have a custom target that I define to copy the
   appropriate debug or release DLLs to the appropriate output
   directories, so that when I debug my applications, they find the
   appropriate DLLs in the same directory. So the copy mapping should be
   as follows:
   
   debug - Debug
   release - Release
   release - RelWithDebInfo
   release - MinSizeRel
   
   Specifically for the RELEASE case. I can't use $CONFIGURATION for
   the source directory, since the name is release between all 3
   release configurations. This case is easily solved with issue 9974,
   however. Any thoughts?
  
  This looks like the common use case I explain here:
   http://www.cmake.org/Bug/view.php?id=9974#c29033
  
  You don't need any new features for it.
 
 To avoid the copy step, would it be useful to make generator expressions
 work in target properties?
 
 set_target_properties(mylib PROPERTIES
   LIBRARY_OUTPUT_DIRECTORY
 ${CMAKE_CURRENT_BINARY_DIR}/$CONFIGURATION/lib)
 set_target_properties(myexe PROPERTIES
   RUNTIME_OUTPUT_DIRECTORY
 ${CMAKE_CURRENT_BINARY_DIR}/$CONFIGURATION/bin)
 
 Currently, I can have more code than that to loop over
 CMAKE_CONFIGURATION_TYPES and set those properties myself, and it results in
 the libraries and executables being together without a copy step and
 without an extra config directory separating them.

Actually, I guess not, because for that to work I would have to set the 
LIBRARY_OUTPUT_DIRECTORY_* property instead.

So, I'm back to this:
set_target_properties(mylib PROPERTIES
  LIBRARY_OUTPUT_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/bin)
set_target_properties(myexe PROPERTIES
  RUNTIME_OUTPUT_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/bin)

foreach(config ${CMAKE_CONFIGURATION_TYPES})
  string(TOUPPER ${config} CONFIG)
  set_target_properties(mylib PROPERTIES
LIBRARY_OUTPUT_DIRECTORY_${CONFIG}
  ${CMAKE_CURRENT_BINARY_DIR}/${config}/bin)
  set_target_properties(myexe PROPERTIES
RUNTIME_OUTPUT_DIRECTORY_${CONFIG}
  ${CMAKE_CURRENT_BINARY_DIR}/${config}/bin)
endforeach()

Clint

--

Powered by www.kitware.com

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

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

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