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] [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] [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

[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] 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 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 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 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 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] [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] 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

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

[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] 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

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 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] 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

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

[Clinton Stimpson]

On Monday, May 13, 2013 03:03:27 PM Brad King wrote:
 On 05/13/2013 02:55 PM, Clinton Stimpson wrote:
  To avoid the copy step, would it be useful to make generator expressions
  work in target properties?
 
 The copy in my example in the issue is for an external dependency.
 
  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)
 For in-project targets one can simply set the output directory to
 be the same for .dll and .exe files.
 
 -Brad

Yeah.  I was thinking something like Xcode where there are configurations, but 
I could put the libraries in a 'lib' directory and the executables in a 'bin' 
directory, where lib and bin have the same parent.

In other words, I want:
Debug/lib/
Debug/bin/
Debug/plugins/

instead of: 
lib/Debug/
bin/Debug/
plugins/Debug/

If I have plugins and resources, I'd want the first, even on Windows, where the 
bin and lib directory could be merged.

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] if (FOO == BAR) ...

[Clinton Stimpson]

Is there a best practices using existing functionality to always avoid 
automatic dereference when comparing strings?

Clint

On Thursday, March 21, 2013 02:56:51 PM David Cole wrote:
 Unfortunately, this entire discussion nicely demonstrates and
 reinforces my belief that we ought not to do this == thing...
 
 If Alex, Brad, Matthew and I can't understand each other's meanings
 within the context of this discussion, what chance does a poor user
 reading through the CMake IF documentation have of getting it right?
 
 Adding a new better way to do something without eliminating the old
 not-so-good way of doing the same thing is not necessarily a good
 thing. Multiple ways to do things just make people shake their heads
 and ask Why?
 
 I am still voting no on this one.
 
 
 David C.
 
 
 -Original Message-
 From: Alexander Neundorf neund...@kde.org
 To: cmake-developers cmake-developers@cmake.org
 Sent: Thu, Mar 21, 2013 2:43 pm
 Subject: Re: [cmake-developers] if (FOO == BAR) ...
 
 On Thursday 21 March 2013, Matthew Woehlke wrote:
  On 2013-03-20 17:42, Alexander Neundorf wrote:
   On Wednesday 20 March 2013, Matthew Woehlke wrote:
   On 2013-03-20 17:10, David Cole wrote:
   Are you proposing that == behaves as STREQUAL, or as EQUAL?
   
   What's the difference?
   
   Okay, for , , there is an obvious answer, but for ==, I am
 
 trying and
 
   failing to think of a situation where treating the arguments as
 
 numbers
 
   would give a different result vs. treating them as strings.
   
   E.g. 0 vs. 0.0
  
  Is 0.0 a floating-point number or a version string? In the context
 
 of
 
  CMake, I would have rather expected it to be the latter. (Does CMake
  even understand floating point?) If '==' assumes numbers, how do I
 
 tell
 
  it I really meant a version string?
 
 EQUAL tries to convert to double:
 
   if (argP1 != newArgs.end()  argP2 != newArgs.end() 
 (*(argP1) == LESS || *(argP1) == GREATER ||
  *(argP1) == EQUAL))
 {
 def = cmIfCommand::GetVariableOrString(arg-c_str(), makefile);
  def2 = cmIfCommand::GetVariableOrString((argP2)-c_str(),
 makefile);
 double lhs;
 double rhs;
 bool result;
 if(sscanf(def, %lg, lhs) != 1 ||
sscanf(def2, %lg, rhs) != 1)
 
 
 My == implementation simply compares the strings on both sides in the
 most
 simple and straightforward way.
 
 
 Alex
 --
 
 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
-- 
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] Qt 4 and 5 on the same system - qmake binary name priority

[Clinton Stimpson]

On Monday, March 11, 2013 11:23:31 AM Brad King wrote:
 On 03/08/2013 02:52 PM, Clinton Stimpson wrote:
  Its not as simple as changing the order.
  If I have my own build of Qt4, and if FindQt4.cmake had this:
  find_program(QT_QMAKE_EXECUTABLE NAMES qmake4 qmake-qt4 qmake-mac qmake
  ...) and I try to use my build of Qt
  CMAKE_PREFIX_PATH=/home/me/qt/qt-4.7.2 cmake ../
  It finds /usr/bin/qmake-qt4 instead, because it searched for qmake-qt4 in
  all possible paths before searching for qmake.
  
  Currently, I think we need to keep qmake first.
 
 FYI, you changed it to the current order here:
 
  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=61ad5242#patch1
 
 but we used to have qmake last.  I think it may have flip-flopped a
 few times before that too but I do not remember for sure.
 
  The proposed patch does improve the situation by making a separate
  find_program() call for each executable name.  It also verifies the
  results of each find_program().
 
 Is the patch acceptable?  Do you have an alternative?
 
 I'd like this to be worked out ASAP.
 
 We're planning 2.8.11-rc1 later this week.
 
 Thanks,
 -Brad

The patch is not acceptable.  It breaks FindQt4.cmake on my system.
I can look into this.

-- 
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] Qt 4 and 5 on the same system - qmake binary name priority

[Clinton Stimpson]

On Monday, March 11, 2013 10:05:48 AM Clinton Stimpson wrote:
 On Monday, March 11, 2013 11:23:31 AM Brad King wrote:
  On 03/08/2013 02:52 PM, Clinton Stimpson wrote:
   Its not as simple as changing the order.
   If I have my own build of Qt4, and if FindQt4.cmake had this:
   find_program(QT_QMAKE_EXECUTABLE NAMES qmake4 qmake-qt4 qmake-mac qmake
   ...) and I try to use my build of Qt
   CMAKE_PREFIX_PATH=/home/me/qt/qt-4.7.2 cmake ../
   It finds /usr/bin/qmake-qt4 instead, because it searched for qmake-qt4
   in
   all possible paths before searching for qmake.
   
   Currently, I think we need to keep qmake first.
  
  FYI, you changed it to the current order here:
   http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=61ad5242#patch1
  
  but we used to have qmake last.  I think it may have flip-flopped a
  few times before that too but I do not remember for sure.
  
   The proposed patch does improve the situation by making a separate
   find_program() call for each executable name.  It also verifies the
   results of each find_program().
  
  Is the patch acceptable?  Do you have an alternative?
  
  I'd like this to be worked out ASAP.
  
  We're planning 2.8.11-rc1 later this week.
  
  Thanks,
  -Brad
 
 The patch is not acceptable.  It breaks FindQt4.cmake on my system.
 I can look into this.

I fixed a few bugs with that patch, and it is now merged with next.

-- 
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] Qt 4 and 5 on the same system - qmake binary name priority

[Clinton Stimpson]

Its not as simple as changing the order.
If I have my own build of Qt4, and if FindQt4.cmake had this:
find_program(QT_QMAKE_EXECUTABLE NAMES qmake4 qmake-qt4 qmake-mac qmake ...)
and I try to use my build of Qt
CMAKE_PREFIX_PATH=/home/me/qt/qt-4.7.2 cmake ../
It finds /usr/bin/qmake-qt4 instead, because it searched for qmake-qt4 in all 
possible paths before searching for qmake.

Currently, I think we need to keep qmake first.

The proposed patch does improve the situation by making a separate 
find_program() call for each executable name.  It also verifies the results of 
each find_program().

Clint

On Friday, March 08, 2013 02:35:53 PM Marcus D. Hanwell wrote:
 Hi,
 
 I notice that Arch has already patched this, but CMake master as of
 aa027af9 still finds /usr/bin/qmake when a /usr/bin/qmake-qt4 is
 available. This bug is reported here,
 
 http://public.kitware.com/Bug/view.php?id=13985
 
 Is there any issue with changing the order so that if qmake-qt4 is
 found that is used preferentially over qmake which it seems will tend
 to be the Qt 5 qmake? Stephen mentions qtchooser but it isn't clear
 how relevant that is to making the find module prefer a qt4 specific
 suffix if one is found. I didn't look at the proposed patch that
 closely, but would like to understand any constraints on changing the
 binary name search order before proposing anything.
 
 Thanks,
 
 Marcus
 --
 
 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
-- 
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] Fwd: [Bug 894805] Re: QT_IMPORTS_DIR is not defined when no QML plugins are installed

[Clinton Stimpson]

This is interesting...

The intent of FindQt4.cmake is to find the Qt installation so it can be used.  
But in that bug report, the QT_IMPORTS_DIR variable is being used to determine 
the qt_dir/imports directory to install their qml plugins - which is into 
the Qt installation.  Its a problem for them because there is no imports 
directory to begin with.

In other words... they have something like this:
find_package(Qt4)
...
install( ... DESTINATION ${QT_IMPORTS_DIR})


Is there a CMake convention for this kind of thing?


On Monday, February 04, 2013 09:13:06 AM Bill Hoffman wrote:
 FYI
 
  Original Message 
 Subject: [Bug 894805] Re: QT_IMPORTS_DIR is not defined when no QML
 plugins   are installed
 Date: Thu, 31 Jan 2013 19:30:37 -
 From: Launchpad Bug Tracker 894...@bugs.launchpad.net
 Reply-To: Bug 894805 894...@bugs.launchpad.net
 To: cm...@packages.qa.debian.org
 
 ** Branch linked: lp:ubuntu/raring-proposed/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

Re: [cmake-developers] Fwd: [Bug 894805] Re: QT_IMPORTS_DIR is not defined when no QML plugins are installed

[Clinton Stimpson]

On Thursday, February 07, 2013 05:51:59 PM Stephen Kelly wrote:
 Clinton Stimpson wrote:
  This is interesting...
  
  The intent of FindQt4.cmake is to find the Qt installation so it can be
  used. But in that bug report, the QT_IMPORTS_DIR variable is being used to
  determine the qt_dir/imports directory to install their qml plugins -
  which is into
  the Qt installation.  Its a problem for them because there is no imports
  directory to begin with.
  
  In other words... they have something like this:
  find_package(Qt4)
  ...
  install( ... DESTINATION ${QT_IMPORTS_DIR})
  
  
  Is there a CMake convention for this kind of thing?
 
 Another relevant question is whether there is a Qt convention for this kind
 of thing.
 
 From the bug report:
 
When requiring the Qt4 package in a CMakeLists.txt, among the
available variables the one called QT_IMPORTS_DIR should point to
where QML plugins are to be installed (its value would typically be
/usr/lib/qt4/imports).
 
 This is not true. The QT_INSTALL_IMPORTS reported by qmake does not have the
 meaning where QML plugins are to be installed. It has the meaning where
 QML assets from Qt itself are installed.
 
 That said, the reported problem in the bug report, that qmake reports the
 path, but cmake does not make it available, seems like something to look
 into.
 

Do you have something in mind when you say it should be looked into?

qmake is reporting a non-existant directory, and CMake doesn't make it 
available because it doesn't exist (not found).

I'm leaning towards saying this is a user error because the user is assuming 
it has the meaning where QML plugins are to be installed.

-- 
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 interface includes and defines (Was Re: Interface includes and defines plumbing)

[Clinton Stimpson]

On Monday, January 07, 2013 08:55:40 PM Stephen Kelly wrote:
 Stephen Kelly wrote:
  Brad King wrote:
  On 01/04/2013 12:09 PM, Stephen Kelly wrote:
  Brad King wrote:
  Yes, please.  Thanks for splitting this out.
  
  Done, thanks,
  
  Thanks for cleaning up the dashboard trouble.  I've merged this
  to master!
  
  Great, thanks!
  
  I've pushed two new branches to my gitorious clone.
 
 I also re-pushed the qt4-target-depends branch to add
 INTERFACE_INCLUDE_DIRECTORIES and INTERFACE_COMPILE_DEFINTIONS to the Qt 4
 targets.
 
 Alex, Clinton, could you review before I merge to next?
 

Looks fine to me except that the Qt3Support module needs
-DQT3_SUPPORT

-- 
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-target-depends

[Clinton Stimpson]

On Monday, December 31, 2012 07:09:23 PM Stephen Kelly wrote:
 clin...@elemtech.com wrote:
  I'm already aware of the distinction.
 
 Great. That wasn't clear from your email talking about all dependencies of
 QtDeclarative instead of just the public ones.
 
  Granted, UseQt4.cmake doesn't know
  if imported targets are being used or not, and probably cannot be reduced
  to the public dependencies.
 
 Yes, I think the 'module dependencies' from the point of view of cmake
 determining that the library exists and has been found on the system is
 different to the 'public link dependencies'.
 
  But, aren't you still missing the private dependencies so that the
  -rpath-link flag (for Linux/GNU) can be added to specify the location of
  the private dependencies?
 
 That is not in the intended scope of my change. My change is about the
 public link dependencies.
 
 If you know how to specify the private dependencies correctly, we can have
 that patch depend on my patch. I'm focussing on the public link
 dependencies.
 
  Maybe we can always use imported targets in FindQt4.cmake, then end up
  with one place to specify public  private dependencies.
 
 The IMPORTED targets are available in UseQt4.cmake. The public dependencies
 (and private dependencies, if you populate them there in some way) can be
 read from the IMPORTED targets in UseQt4.cmake.
 
 That's also out of the scope of my patch though. I'm trying to get a patch
 that is self-contained and useful in. I'm not trying to fix all possible
 issues with FindQt4 at once. There are more other and useful things to do,
 but this is the largest issue and the one with the biggest gain.
 
 Do you think my patch is not self-contained and useful enough as it is to go
 in?
 

For some reason I thought you needed the private ones too because a custom 
built Qt could be without rpaths.  But the ones I checked seem to be fine.
So, +1 for the patch.

-- 
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] Incomplete gfortran library link command sometimes mysteriously occurs with MinGW/MSYS on Wine-1.5.15 platform

[Clinton Stimpson]

 
 Astronomical research affiliation with Department of Physics and Astronomy,
 University of Victoria (astrowww.phys.uvic.ca).
 
 Programming affiliations with the FreeEOS equation-of-state
 implementation for stellar interiors (freeeos.sf.net); the Time
 Ephemerides project (timeephem.sf.net); PLplot scientific plotting
 software package (plplot.sf.net); the libLASi project
 (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
 and the Linux Brochure Project (lbproject.sf.net).
 __
 
 Linux-powered Science
 __
-- 
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] Incomplete gfortran library link command sometimes mysteriously occurs with MinGW/MSYS on Wine-1.5.15 platform

[Clinton Stimpson]

On Oct 25, 2012, at 9:42 PM, Bill Hoffman wrote:

 
 On Oct 25, 2012 11:15 PM, Clinton Stimpson clin...@elemtech.com wrote:
 
 
  On Oct 25, 2012, at 4:18 PM, Bill Hoffman wrote:
 
   On 10/25/2012 6:06 PM, Alan W. Irwin wrote:
  
   I have just discovered an extremely simple test case of the whole
  
   We have already found the problem and have an even smaller test case.
  
   cat info.cmake
   file(STRINGS a.exe _strings LIMIT_COUNT 4 REGEX INFO:)
   foreach(info ${_strings})
message(STATUS [${info}])
   endforeach()
  
   Build the CMake test case into a.exe like this:
   gfortran CMakeFortranCompilerABI.F
  
   Then run cmake -P info.cmake,
   It should print this:
   -- [INFO:compiler[GNU]INFO:platform[]]
  
   If not it is broken and will not detect the compiler correctly.
 
 
  Bill, are you sure you meant CMakeFortranCompilerABI.F?
  I get something like this
  INFO:sizeof_dptr[8]ABI Detection
  no matter what I do, even on native Linux with /usr/bin/gfortran.
 
  The other file, CMakeFortranCompilerId.F, should give the 
  compiler/platform.  Is that the one you meant?
 
 Either one should show the issue. I did show the wrong output. When it fails 
 you get no output.
 
  Clint
 
Ok, I was able to reproduce the problem.

Alan, you are in luck.  They fixed it two days ago!!  At first, I was confused 
because I was not able to reproduce it, then trying it against an older version 
of Wine showed the problem.

commit 4a566ed3d6acd8a6e18eeaeb41d55d0f793029de
Author: Piotr Caban pi...@codeweavers.com
Date:   Tue Oct 23 18:11:06 2012 +0200

msvcp90: Convert characters to unsigned char before passing them to 
functions operating on integers.

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] rpm/deb component issue

[Clinton Stimpson]

I have a problem with the rpm  deb cpack generators.

I've set the following:
set(CPACK_COMPONENTS_ALL_IN_ONE_PACKAGE 1)
set(CPACK_DEB_COMPONENT_INSTALL 1)
set(CPACK_RPM_COMPONENT_INSTALL 1)

I get this implementation detail string ALL_COMPONENTS_IN_ONE being put in 
the package name (that is name, not the filename), so I end up with mypackage-
ALL_COMPONENTS_IN_ONE.  To remove it, I do yum remove mypackage-
ALL_COMPONENTS_IN_ONE.
I would rather just have mypackage since that is the name I've specified.
But I don't see a way to override it.

Does anyone have a suggested way for me to fix cmCPack*Generator.cxx and/or 
CPackDeb.cmake, CPackRPM.cmake?  This is the first time I've looked at 
modifying those particular files.

-- 
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] rpm/deb component issue

[Clinton Stimpson]

On Wednesday, October 24, 2012 11:59:52 AM Clinton Stimpson wrote:
 I have a problem with the rpm  deb cpack generators.
 
 I've set the following:
 set(CPACK_COMPONENTS_ALL_IN_ONE_PACKAGE 1)
 set(CPACK_DEB_COMPONENT_INSTALL 1)
 set(CPACK_RPM_COMPONENT_INSTALL 1)
 
 I get this implementation detail string ALL_COMPONENTS_IN_ONE being put in
 the package name (that is name, not the filename), so I end up with
 mypackage- ALL_COMPONENTS_IN_ONE.  To remove it, I do yum remove
 mypackage- ALL_COMPONENTS_IN_ONE.
 I would rather just have mypackage since that is the name I've specified.
 But I don't see a way to override it.
 
 Does anyone have a suggested way for me to fix cmCPack*Generator.cxx and/or
 CPackDeb.cmake, CPackRPM.cmake?  This is the first time I've looked at
 modifying those particular files.

I have an idea that I'm comfortable with.  I'm effectively separating a 
variable into two, one for the component name, and another for the directory 
where it can be found.  For the ALL_COMPONENTS_IN_ONE mode, the directory can 
be ALL_COMPONENTS_IN_ONE/, but the component name empty.
Let me know if you disagree.

-- 
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] rpm/deb component issue

[Clinton Stimpson]

On Wednesday, October 24, 2012 09:27:38 PM Eric Noulard wrote:
 2012/10/24 Clinton Stimpson clin...@elemtech.com:
  On Wednesday, October 24, 2012 11:59:52 AM Clinton Stimpson wrote:
  I have a problem with the rpm  deb cpack generators.
  
  I've set the following:
  set(CPACK_COMPONENTS_ALL_IN_ONE_PACKAGE 1)
  set(CPACK_DEB_COMPONENT_INSTALL 1)
  set(CPACK_RPM_COMPONENT_INSTALL 1)
  
  I get this implementation detail string ALL_COMPONENTS_IN_ONE being put
  in the package name (that is name, not the filename), so I end up with
  mypackage- ALL_COMPONENTS_IN_ONE.  To remove it, I do yum remove
  mypackage- ALL_COMPONENTS_IN_ONE.
  I would rather just have mypackage since that is the name I've
  specified.
  But I don't see a way to override it.
 
 This is clearly a bug, I can't see any way to fix without a small patch.
 Note that the DEB generator does not seem to suffer from this, is it?
 
 When the xx.deb file is generated you can check it (without installing)
 using dpkg-deb --info xx.deb
 dpkg-deb --contents xx.deb
 dpkg-deb --show xx.deb
 
  Does anyone have a suggested way for me to fix cmCPack*Generator.cxx
  and/or
  CPackDeb.cmake, CPackRPM.cmake?  This is the first time I've looked at
  modifying those particular files.
 
 I think the best current workaround is to change CPackRPM.cmake.
 
  I have an idea that I'm comfortable with.  I'm effectively separating a
  variable into two, one for the component name, and another for the
  directory where it can be found.  For the ALL_COMPONENTS_IN_ONE mode, the
  directory can be ALL_COMPONENTS_IN_ONE/, but the component name empty.
  Let me know if you disagree.D
 
 I agree and ended-up with the same patch (in CPackRPM.cmake).
 You'll find my patch (against CMake master) proposal attached,
 I'm not really sure it's the right final fix though.
 
 Clint would you be kind enough to open a bug report for that please?


The Deb generator suffers from the same problem.
Attached is my patch which is working fine for me.  Does it look OK?  I did the 
approach of simplifying the .cmake files and putting the implementation 
specific 
logic in the cmCPack*.cxx files.

-- 
Clinton Stimpson
Elemental Technologies, Inc
Computational Simulation Software, LLC
www.csimsoft.comFrom b3363e7847a9214b4daa81ac2d990d7cf4c31a89 Mon Sep 17 00:00:00 2001
From: Clinton Stimpson clin...@elemtech.com
Date: Wed, 24 Oct 2012 13:37:18 -0600
Subject: [PATCH] RPM/Deb: Fix package names to not include
 ALL_COMPONENTS_IN_ONE

---
 Modules/CPackDeb.cmake   |  6 ++
 Modules/CPackRPM.cmake   |  6 ++
 Source/CPack/cmCPackDebGenerator.cxx | 10 --
 Source/CPack/cmCPackRPMGenerator.cxx | 10 --
 4 files changed, 20 insertions(+), 12 deletions(-)

diff --git a/Modules/CPackDeb.cmake b/Modules/CPackDeb.cmake
index 106b44c..75ff3be 100644
--- a/Modules/CPackDeb.cmake
+++ b/Modules/CPackDeb.cmake
@@ -385,15 +385,13 @@ endif()
 # Are we packaging components ?
 if(CPACK_DEB_PACKAGE_COMPONENT)
   set(CPACK_DEB_PACKAGE_COMPONENT_PART_NAME -${CPACK_DEB_PACKAGE_COMPONENT})
-  set(CPACK_DEB_PACKAGE_COMPONENT_PART_PATH /${CPACK_DEB_PACKAGE_COMPONENT})
-  set(WDIR ${CPACK_TOPLEVEL_DIRECTORY}/${CPACK_PACKAGE_FILE_NAME}/${CPACK_DEB_PACKAGE_COMPONENT})
   string(TOLOWER ${CPACK_PACKAGE_NAME}${CPACK_DEB_PACKAGE_COMPONENT_PART_NAME} CPACK_DEBIAN_PACKAGE_NAME)
 else()
   set(CPACK_DEB_PACKAGE_COMPONENT_PART_NAME )
-  set(CPACK_DEB_PACKAGE_COMPONENT_PART_PATH )
-  set(WDIR ${CPACK_TOPLEVEL_DIRECTORY}/${CPACK_PACKAGE_FILE_NAME})
 endif()
 
+set(WDIR ${CPACK_TOPLEVEL_DIRECTORY}/${CPACK_PACKAGE_FILE_NAME}${CPACK_DEB_PACKAGE_COMPONENT_PART_PATH})
+
 # Print out some debug information if we were asked for that
 if(CPACK_DEBIAN_PACKAGE_DEBUG)
message(CPackDeb:Debug: CPACK_TOPLEVEL_DIRECTORY  = ${CPACK_TOPLEVEL_DIRECTORY})
diff --git a/Modules/CPackRPM.cmake b/Modules/CPackRPM.cmake
index 0cec897..34d0045 100644
--- a/Modules/CPackRPM.cmake
+++ b/Modules/CPackRPM.cmake
@@ -311,14 +311,12 @@ endif()
 # Are we packaging components ?
 if(CPACK_RPM_PACKAGE_COMPONENT)
   set(CPACK_RPM_PACKAGE_COMPONENT_PART_NAME -${CPACK_RPM_PACKAGE_COMPONENT})
-  set(CPACK_RPM_PACKAGE_COMPONENT_PART_PATH /${CPACK_RPM_PACKAGE_COMPONENT})
-  set(WDIR ${CPACK_TOPLEVEL_DIRECTORY}/${CPACK_PACKAGE_FILE_NAME}/${CPACK_RPM_PACKAGE_COMPONENT})
 else()
   set(CPACK_RPM_PACKAGE_COMPONENT_PART_NAME )
-  set(CPACK_RPM_PACKAGE_COMPONENT_PART_PATH )
-  set(WDIR ${CPACK_TOPLEVEL_DIRECTORY}/${CPACK_PACKAGE_FILE_NAME})
 endif()
 
+set(WDIR ${CPACK_TOPLEVEL_DIRECTORY}/${CPACK_PACKAGE_FILE_NAME}${CPACK_RPM_PACKAGE_COMPONENT_PART_PATH})
+
 #
 # Use user-defined RPM specific variables value
 # or generate reasonable default value from
diff --git a/Source/CPack/cmCPackDebGenerator.cxx b/Source/CPack/cmCPackDebGenerator.cxx
index 4bd5d5c..8a41d0e 100644
--- a/Source/CPack/cmCPackDebGenerator.cxx
+++ b/Source/CPack/cmCPackDebGenerator.cxx
@@ -76,6 +76,10 @@ int cmCPackDebGenerator::PackageOnePack(std

Re: [cmake-developers] rpm/deb component issue

[Clinton Stimpson]

On Wednesday, October 24, 2012 10:08:29 PM Eric Noulard wrote:
 2012/10/24 Clinton Stimpson clin...@elemtech.com:
  On Wednesday, October 24, 2012 09:27:38 PM Eric Noulard wrote:
  2012/10/24 Clinton Stimpson clin...@elemtech.com:
   On Wednesday, October 24, 2012 11:59:52 AM Clinton Stimpson wrote:
   I have a problem with the rpm  deb cpack generators.
   
   I've set the following:
   set(CPACK_COMPONENTS_ALL_IN_ONE_PACKAGE 1)
   set(CPACK_DEB_COMPONENT_INSTALL 1)
   set(CPACK_RPM_COMPONENT_INSTALL 1)
   
   I get this implementation detail string ALL_COMPONENTS_IN_ONE being
   put
   in the package name (that is name, not the filename), so I end up with
   mypackage- ALL_COMPONENTS_IN_ONE.  To remove it, I do yum remove
   mypackage- ALL_COMPONENTS_IN_ONE.
   I would rather just have mypackage since that is the name I've
   specified.
   But I don't see a way to override it.
  
  This is clearly a bug, I can't see any way to fix without a small patch.
  Note that the DEB generator does not seem to suffer from this, is it?
  
  When the xx.deb file is generated you can check it (without installing)
  using dpkg-deb --info xx.deb
  dpkg-deb --contents xx.deb
  dpkg-deb --show xx.deb
  
   Does anyone have a suggested way for me to fix cmCPack*Generator.cxx
   and/or
   CPackDeb.cmake, CPackRPM.cmake?  This is the first time I've looked at
   modifying those particular files.
  
  I think the best current workaround is to change CPackRPM.cmake.
  
   I have an idea that I'm comfortable with.  I'm effectively separating a
   variable into two, one for the component name, and another for the
   directory where it can be found.  For the ALL_COMPONENTS_IN_ONE mode,
   the
   directory can be ALL_COMPONENTS_IN_ONE/, but the component name empty.
   Let me know if you disagree.D
  
  I agree and ended-up with the same patch (in CPackRPM.cmake).
  You'll find my patch (against CMake master) proposal attached,
  I'm not really sure it's the right final fix though.
  
  Clint would you be kind enough to open a bug report for that please?
  
  The Deb generator suffers from the same problem.
 
 Ok you are right my test was not done properly.
 
  Attached is my patch which is working fine for me.  Does it look OK?  I
  did the approach of simplifying the .cmake files and putting the
  implementation specific logic in the cmCPack*.cxx files.
 
 Looks good, I'll give it a more thorough look  test tomorrow or the day
 after.

Ok thanks.  I'll go ahead and put in on stage then.

Also, when I run the tests, CPackComponents fails for me, and its because I 
don't have nsis installed on this Linux machine.  I'm looking at 
Tests/CMakeLists.txt and I don't see a way to turn off that test.  Only on 
Windows does it check the existence of nsis and disables the test.  Or am I 
looking at it wrong?

-- 
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: FindQt4-nonfatal-if-Qt5-found

[Clinton Stimpson]

It looks like that branch removes the error if
find_package(Qt4 REQUIRED)
doesn't find Qt 4.x.  No?

If it does remove the error, that seems wrong.  Is there another way to avoid 
the error in the cmake unit tests?

On Friday, October 19, 2012 03:08:26 PM Stephen Kelly wrote:
 Hi,
 
 I've just pushed the FindQt4-nonfatal-if-Qt5-found branch, and before
 merging it to next, I'd like some review (Alex? Clinton?).
 
 Thanks!
 
 Steve.
 
 
 --
 
 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
-- 
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] FindQt4 DBus framework problem on the Mac

[Clinton Stimpson]

On Thursday, September 06, 2012 03:17:33 PM David Cole wrote:
 I still get bit by issues with QtDBus when building VTK with Qt
 support on my Mac... It gets found as a .framework, but there's not
 actually a library inside the framework folder, so link errors occur.
 It would be fine if it simply didn't get found.
 
 I waste some time every few months when I rebuild VTK again, encounter
 this problem, then figure out how to fix it manually one more time,
 and then forget about it again. This patch would allow me to NEVER
 HAVE THE PROBLEM AGAIN.
 
 Would the attached patch be reasonable to put into FindQt4, or should
 we actually build similar functionality into the find_library code
 internal to CMake?
 
 
 Thanks,
 David

As far as I can tell, recent versions of Qt do not have this problem.
Except possibly if you configure with -prefix /path/to/qt/build to avoid a make 
install step.

The patch to FindQt4 is fine with 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] FindQt4 DBus framework problem on the Mac

[Clinton Stimpson]

I remember it being a problem in 4.6.0, 4.6.1 and then it was fixed in 4.6.2.

I meant recent by looking at my 4.8.2 build I made a few weeks back and seeing 
that it doesn't have the empty framework.  However, it is there in the build 
tree.  So maybe they regressed again in 4.8.0 and fixed it.

For Qt 5.0, I noticed they avoid making the empty framework in the build tree.
https://bugreports.qt-project.org/browse/QTBUG-25522

Clint

On Thursday, September 06, 2012 04:19:14 PM David Cole wrote:
 I am using a Qt 4.8.0 build, and I am seeing this problem in the Qt
 install tree.
 
 What's recent in your book? (If I upgrade to 4.8.2 will the problem
 also just go away...?)
 
 On Thu, Sep 6, 2012 at 3:55 PM, Clinton Stimpson clin...@elemtech.com 
wrote:
  On Thursday, September 06, 2012 03:17:33 PM David Cole wrote:
  I still get bit by issues with QtDBus when building VTK with Qt
  support on my Mac... It gets found as a .framework, but there's not
  actually a library inside the framework folder, so link errors occur.
  It would be fine if it simply didn't get found.
  
  I waste some time every few months when I rebuild VTK again, encounter
  this problem, then figure out how to fix it manually one more time,
  and then forget about it again. This patch would allow me to NEVER
  HAVE THE PROBLEM AGAIN.
  
  Would the attached patch be reasonable to put into FindQt4, or should
  we actually build similar functionality into the find_library code
  internal to CMake?
  
  
  Thanks,
  David
  
  As far as I can tell, recent versions of Qt do not have this problem.
  Except possibly if you configure with -prefix /path/to/qt/build to avoid
  a make install step.
  
  The patch to FindQt4 is fine with me.
  
  --
  Clinton Stimpson
  Elemental Technologies, Inc
  Computational Simulation Software, LLC
  www.csimsoft.com
-- 
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] Porting QtDialog to Qt 5

[Clinton Stimpson]

On Tuesday, August 21, 2012 11:18:44 AM Stephen Kelly wrote:
 Hi,
 
 I've pushed the qt5-qtdialog-port branch to stage. It makes it possible to
 build the QtDialog with Qt 5 (and some other clean-ups). I don't have Qt 4
 in my Qt 5 environment, and I do need cmake in my Qt 5 environment, so this
 ensures that I get a usable dialog when building cmake in my Qt 5
 environment.
 
 In the branch, Qt 5 is preferred if found.
 
 Any objection to merging it to next?
 

Nice.

However, I get this error:

$ CMAKE_PREFIX_PATH=/dir/to/qt5-build/ cmake ../CMake
CMake Error at Source/QtDialog/CMakeLists.txt:20 (qt5_wrap_ui):
  Unknown CMake command qt5_wrap_ui.
Call Stack (most recent call first):
  Source/QtDialog/CMakeLists.txt:57 (QT4_WRAP_UI)

Any ideas?

-- 
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] Porting QtDialog to Qt 5

[Clinton Stimpson]

On Tuesday, August 21, 2012 07:23:05 PM Stephen Kelly wrote:
 Clinton Stimpson wrote:
  On Tuesday, August 21, 2012 11:18:44 AM Stephen Kelly wrote:
  Hi,
  
  I've pushed the qt5-qtdialog-port branch to stage. It makes it
  possible
  to build the QtDialog with Qt 5 (and some other clean-ups). I don't
  have
  Qt 4 in my Qt 5 environment, and I do need cmake in my Qt 5
  environment,
  so this ensures that I get a usable dialog when building cmake in my
  Qt 5 environment.
  
  In the branch, Qt 5 is preferred if found.
  
  Any objection to merging it to next?
  
  Nice.
  
  However, I get this error:
  
  $ CMAKE_PREFIX_PATH=/dir/to/qt5-build/ cmake ../CMake
  
  CMake Error at Source/QtDialog/CMakeLists.txt:20 (qt5_wrap_ui):
Unknown CMake command qt5_wrap_ui.
  
  Call Stack (most recent call first):
Source/QtDialog/CMakeLists.txt:57 (QT4_WRAP_UI)
  
  Any ideas?
 
 Interesting.
 
 Is your qtbase up to date?

Its about 1 week old, plus some of your patches going through review.
(https://codereview.qt-project.org/33193)

 Have you done a clean build recently?

Not totally clean, but I can delete the 
lib/cmake/Qt5Widgets/Qt5WidgetsConfig.cmake file and regenerate it.

 Does /dir/to/qt5-build/lib/cmake/Qt5Widgets/Qt5WidgetsConfig.cmake contain
 the line: include(${CMAKE_CURRENT_LIST_DIR}/Qt5WidgetsMacros.cmake) ?

No, it does not contain that line at the end.

 Does /dir/to/qt5-build/lib/cmake/Qt5Widgets/Qt5WidgetsMacros.cmake contain
 the qt5_wrap_ui function?
 Is this on OSX?

Linux.

Oh... if I go back to the master branch, then the Qt5WidgetsConfig.cmake file 
has the include.  Perhaps something broke with that recent patch of yours.

Clint

 
 I also just realized that I'll have to add a line to handle -fPIC in the
 patch too...
 
 Thanks,
 
 Steve.
 
 
 --
 
 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
-- 
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] qt4_use_modules

[Clinton Stimpson]

On Wednesday, August 15, 2012 11:53:28 AM Brad King wrote:
 On 08/15/2012 11:41 AM, Stephen Kelly wrote:
  Brad King wrote:
  Please rebase the topic on master so you can drop the middle commit
  that removes trailing whitespace.
  
  I did this and squashed it into one commit.
 
 Thanks.  The change looks good to me, though I'll still be more
 comfortable if a Qt expert reviews it.
 

Stephen,

I've been playing with for a bit and was wondering how to handle the qtmain 
library with it?
Do I actually have to put a if(WIN32) around that, like this?
if(WIN32)
  qt4_use_modules(myapp main)
endif()

Previously, I could do 
target_link_libraries(cmake-gui CMakeLib ${QT_QTMAIN_LIBRARY} ${QT_LIBRARIES})
and on those platforms without qtmain, the variable is simply empty.

Besides that question, the patch looks fine 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] qt4_use_modules

[Clinton Stimpson]

On Aug 11, 2012, at 10:36 AM, Alexander Neundorf wrote:

 On Friday 10 August 2012, Stephen Kelly wrote:
  David Cole wrote:
   I assume it's the qt4_use_modules branch on the stage?
  
  Yes, sorry, I should have pointed that out.
 What was the plan with the more generic target_use_package() or how it was 
 named ?
 This would do something similar, right ?
 Alex
 --

I was wondering the same.  And how close are we to having the more generic one 
working?

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] After using CMake 2.8 VS produces QT Add-in error

[Clinton Stimpson]

On Tuesday, July 10, 2012 02:38:58 PM Gerenrot, Mikhail wrote:
 Hi Team,
 
 We have a C++ project that uses QT3. We run CMake to generate the project
 and run VS 2008 to compile. With CMake 2.6 everything was OK, but now we
 have upgraded to CMake 2.8. It generates the project, but VS does not
 compile, it gives Qt Visual Studio Add-in error that says ERROR: Can't
 find the Qt version that's associated with this project..
 
 We really need this upgrade to CMake 2.8 and any help will be greatly
 appreciated.
 
 Thank you all in advance,
 
 Mike Gerenrot, Stryker Corp.

I'm not familiar with a way that a cmake upgrade can cause this error.

How are you putting the Qt version into the CMake generated visual studio 
project?

Also, there are other things that can cause this, e.g.
https://bugreports.qt-project.org/browse/QTBUG-4838
https://bugreports.qt-project.org/browse/QTBUG-5143

-- 
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] Use OBJECT_DEPENDS in qt4_generate_moc() ?

[Clinton Stimpson]

On Friday, June 15, 2012 09:56:51 PM Alexander Neundorf wrote:
 Hi,
 
 attached is a small patch which sets the OBJECT_DEPENDS  property of a moced
 file to the generated moc file.
 This has the effect that before the cpp file is built, moc has been run on
 it. We have that in KDE's version of qt4_generate_moc() this way since 2006
 and it works for us.
 In cmake's version, it was removed January 11th 2008, the removed call to
 MACRO_ADD_FILE_DEPENDENCIES():
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=510f578f8b53858fbb541c4e7
 e4731de9bfbd483
 
 Now since we are trying to get rid of our custom stuff in KDE, we hit that
 issue when trying to build parts of KDE with FindQt4.cmake from cmake.
 
 Do you remember why this line was removed ?
 What do you think about adding it again, as the attached patch does ?
 
 Alex

It was probably removed because I thought add_custom_command() already added 
the needed dependency information.

It should already have this:
mocable.h - moc_mocable.cpp -  moc_mocable.o
or
mocable.h - mocable.moc - mocable.cpp (includes mocable.moc)

Why do we need the extra dependency like this?
mocable.h - mocable.cpp

-- 
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] Use OBJECT_DEPENDS in qt4_generate_moc() ?

[Clinton Stimpson]

On Thursday, July 05, 2012 06:20:56 PM Alexander Neundorf wrote:
 On Thursday, 5. July 2012 17:37:21 Clinton Stimpson wrote:
  On Friday, June 15, 2012 09:56:51 PM Alexander Neundorf wrote:
   Hi,
   
   attached is a small patch which sets the OBJECT_DEPENDS  property of
   a
   moced file to the generated moc file.
   This has the effect that before the cpp file is built, moc has been
   run
   on it. We have that in KDE's version of qt4_generate_moc() this way
   since 2006 and it works for us.
   In cmake's version, it was removed January 11th 2008, the removed
   call to MACRO_ADD_FILE_DEPENDENCIES():
   http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=510f578f8b53858fb
   b541c 4e7 e4731de9bfbd483
   
   Now since we are trying to get rid of our custom stuff in KDE, we
   hit
   that issue when trying to build parts of KDE with FindQt4.cmake from
   cmake.
   
   Do you remember why this line was removed ?
   What do you think about adding it again, as the attached patch does
   ?
   
   Alex
  
  It was probably removed because I thought add_custom_command() already
  added the needed dependency information.
  
  It should already have this:
  mocable.h - moc_mocable.cpp -  moc_mocable.o
 
 This works if the generated moc file is listed as source file for a target.
 In several places we did not do this, and relied instead on the
 OBJECT_DEPENDS.
 Ahh, this was in places where the moc file is generated from a cpp file,
 which includes the moc file.
 In those cases the OBJECT_DEPENDS makes it work.
 
 We fixed this in the meantime by adding the generated moc file to the source
 list (which is not too bad, since the developer explicitely names the moc
 file, so it is ok).
 
 So, I would like to have that dependency, but I'm unsure whether it might
 have any unwanted side effects.
 

Ah, so for the case
mocable.h - mocable.moc - mocable.cpp (includes mocable.moc)
the mocable.moc is not listed in the sources of the target.

I can't think of any possible unwanted side effects.
I agree that we need to have this patch.

-- 
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] Improvements to Qt4 macros

[Clinton Stimpson]

On Jun 20, 2012, at 5:51 AM, Rolf Eike Beer wrote:

 Hi,
 
 while wrestling with QtDBus today I found out the hard way (i.e. reading the 
 source) that QT4_ADD_DBUS_INTERFACE is much more powerful than its 
 documentation tells. To fix that the first patch now tells about the 
 properties you may set on the input file. While at it I also added a 
 reference 
 from QT4_AUTOMOC macro to the new AUTOMOC property.
 
 The other 2 patches improve some things I found while reading the source code.
 
 Patch #2 uses get_filename_component to strip the path from the given input 
 file (why implement something again that we already have?). It also applies 
 string(TOLOWER) earlier so that an XML file with an upper or mixed case 
 extension (FAT anyone?) will also be properly handled.
 
 Patch #3 finally wraps a lot of set(...) in quotes when the argument may 
 contain spaces, e.g. CMAKE_CURRENT_BINARY_DIR. It also uses LIST(APPEND) to 
 add to the list of source files instead of just using set(). Together with 
 additional quotes this should make things much less likely to screw up things.
 
 If noone objects I'll merge this to next tonight. Running the testsuite 
 locally did not show any errors.
 
 Eike0001-FindQt4-extend-documentation.patch0002-Qt4Macros-improve-basename-extraction-in-QT4_ADD_DBU.patch0003-Qt4Macros-add-some-quotes-to-prevent-damage-from-spa.patch

I don't think the test suite covers QtDbus.  Perhaps that can be added?
What about a case sensitive file system with .XML instead of .xml?  Does your 
second patch break that?
Other than that question, I have no objections.

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] Regression when using multiple Qt installations (FindQt4.make)

[Clinton Stimpson]

On Sunday, May 06, 2012 04:27:17 am Benoit Walter wrote:
 Hi CMake developers,
 
 as I need to maintain different projects using different Qt versions, I
 needed to have a look at FindQt4.cmake.
 
 Based on the path of qmake, I can successfully decide which Qt version is
 used (for example using Debian's update-alternatives).
 
 Ex:
 /opt/qt4.7 (custom version)
 /usr/include/qt4 (default version)
 
 However, even if I set qmake to the directory of the custom version, I see
 that cmake uses the headers of the default version.
 
 It seems to me like a regression in commit
 0ae8a3405bb32afadda13f43100484e85f7ef74f (Add qt4/QtCore to help find Qt
 headers when cross-compiling.)
 
 qt4/QtCore is found in /usr/include instead of /opt/qt4.7/include, in
 contradiction with the qmake information (qmake -query QT_INSTALL_HEADERS).
 
 Corresponding lines in FindQt4.make:
   FIND_PATH(QT_QTCORE_INCLUDE_DIR QtCore
 HINTS ${qt_headers} ${QT_LIBRARY_DIR}
 PATH_SUFFIXES QtCore qt4/QtCore
 )
 
 Removing qt4/QtCore fixes the problem, but I guess that the commit was
 useful for other reasons :)
 So my suggestion is to either revert the commit because it invalidates a
 common scenario when using cmake with several Qt installations, or to fix
 the FIND_PATH call, making sure that the custom location is found before
 the default one.
 
 Any idea?
 
 Best regards,
 Benoit.

What version of cmake are you using?

I also have
/usr/include/qt4
and a custom Qt, but do not see this problem with the latest cmake.

The FIND_PATH(QT_QTCORE_INCLUDE_DIR QtCore
HINTS ${qt_headers} ${QT_LIBRARY_DIR}
PATH_SUFFIXES QtCore qt4/QtCore

It should first look for ${qt_headers}/QtCore, which should be 
/opt/qt4.7/include/QtCore.

I tried these 3 ways, but was not able to reproduce.
1. PATH=/path/to/custom/qt/bin:$PATH cmake ..
2. CMAKE_PREFIX_PATH=/path/to/custom/qt cmake ..
3. cmake ..  - modify CMakeCache.txt to use custom qmake then re-run cmake.

I have no /usr/include in my CMakeCache.txt file.

Can you expand the ${qt_headers} and tell me what you have?

-- 
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] Regression when using multiple Qt installations (FindQt4.make)

[Clinton Stimpson]

On Monday, May 07, 2012 08:43:07 am Benoit Walter wrote:
 On Monday 07 May 2012, Clinton Stimpson wrote:
  On Sunday, May 06, 2012 04:27:17 am Benoit Walter wrote:
   Hi CMake developers,
   
   as I need to maintain different projects using different Qt versions, I
   needed to have a look at FindQt4.cmake.
   
   Based on the path of qmake, I can successfully decide which Qt version
   is used (for example using Debian's update-alternatives).
   
   Ex:
   /opt/qt4.7 (custom version)
   /usr/include/qt4 (default
   version)PATH=/PATH=/path/to/custom/qt/bin:$PATH
 
 cmake ..path/to/custom/qt/bin:$PATH cmake ..
 
   However, even if I set qmake to the directory of the custom version, I
   see that cmake uses the headers of the default version.
   
   It seems to me like a regression in commit
   0ae8a3405bb32afadda13f43100484e85f7ef74f (Add qt4/QtCore to help find
   Qt headers when cross-compiling.)
   
   qt4/QtCore is found in /usr/include instead of /opt/qt4.7/include, in
   contradiction with the qmake information (qmake -query
   QT_INSTALL_HEADERS).
   
   Corresponding lines in FindQt4.make:
 FIND_PATH(QT_QTCORE_INCLUDE_DIR QtCore
 
   HINTS ${qt_headers} ${QT_LIBRARY_DIR}
   PATH_SUFFIXES QtCore qt4/QtCore
   
   )
   
   Removing qt4/QtCore fixes the problem, but I guess that the commit was
   useful for other reasons :)
   So my suggestion is to either revert the commit because it invalidates
   a common scenario when using cmake with several Qt installations, or
   to fix the FIND_PATH call, making sure that the custom location is
   found before the default one.
   
   Any idea?
   
   Best regards,
   Benoit.
  
  What version of cmake are you using?
  
  I also have
  /usr/include/qt4
  and a custom Qt, but do not see this problem with the latest cmake.
  
  The FIND_PATH(QT_QTCORE_INCLUDE_DIR QtCore
  
  HINTS ${qt_headers} ${QT_LIBRARY_DIR}
  PATH_SUFFIXES QtCore qt4/QtCore
  
  It should first look for ${qt_headers}/QtCore, which should be
  /opt/qt4.7/include/QtCore.
  
  I tried these 3 ways, but was not able to reproduce.
  1. PATH=/path/to/custom/qt/bin:$PATH cmake ..
  2. CMAKE_PREFIX_PATH=/path/to/custom/qt cmake ..
  3. cmake ..  - modify CMakeCache.txt to use custom qmake then re-run
  
   cmake.
  
  I have no /usr/include in my CMakeCache.txt file.
  
  Can you expand the ${qt_headers} and tell me what you have?
 
 I am using CMake 2.8.7. I would also expect that it first looks for
 ${qt_headers}/QtCore and then qt4/QtCore but this is unfortunately not the
 case for me.
 
 qt_header points to the right directory (/opt/qt4.7/include), so my guess
 is that the problem is related to the FIND_PATH() function. It seems that
 it first checks the default path (/usr/include). If I add the
 NO_DEFAULT_PATH argument, it works as expected and QT_QTCORE_INCLUDE_DIR
 points to the right directory (the custom one):
 
   FIND_PATH(QT_QTCORE_INCLUDE_DIR QtCore
 HINTS ${qt_headers} ${QT_LIBRARY_DIR}
 PATH_SUFFIXES QtCore qt4/QtCore
 NO_DEFAULT_PATH
)
 
 Maybe because of a recent CMake change in FIND_PATH()?
 
 Note: On my system, the PATH is not changed (/usr/bin is *before*
 /opt/qt4.7/bin) and /usr/bin/cmake is linked to /opt/qt4.7/bin/cmake using
 update-alternatives. But that should not change anything and the first
 steps (including _qt4_query_qmake(QT_INSTALL_HEADERS qt_headers)) are
 successful.
 
 Regards,
 Benoit.

According to the docs, /usr/include is searched after any paths given by 
HINTS.  However, I can reproduce your problem by doing this:
export CMAKE_PREFIX_PATH=/usr
cmake -DQT_QMAKE_EXECUTABLE=/path/to/custom/qt/bin/qmake ../

but that can easily be fixed by a more standard approach of specifying a 
desired package (in this case, Qt) in CMAKE_PREFIX_PATH instead.
export CMAKE_PREFIX_PATH=/path/to/qt:/usr
cmake ../

So, are you setting either CMAKE_PREFIX_PATH or CMAKE_INCLUDE_PATH in the 
environment or in your CMakeLists.txt files?

-- 
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] Regression when using multiple Qt installations (FindQt4.make)

[Clinton Stimpson]

On Monday, May 07, 2012 09:14:55 am Benoit Walter wrote:
 On Monday 07 May 2012, you wrote:
  On Monday, May 07, 2012 08:43:07 am Benoit Walter wrote:
   On Monday 07 May 2012, Clinton Stimpson wrote:
On Sunday, May 06, 2012 04:27:17 am Benoit Walter wrote:
 Hi CMake developers,
 
 as I need to maintain different projects using different Qt
 versions, I needed to have a look at FindQt4.cmake.
 
 Based on the path of qmake, I can successfully decide which Qt
 version is used (for example using Debian's update-alternatives).
 
 Ex:
 /opt/qt4.7 (custom version)
 /usr/include/qt4 (default
 version)PATH=/PATH=/path/to/custom/qt/bin:$PATH
   
   cmake ..path/to/custom/qt/bin:$PATH cmake ..
   
 However, even if I set qmake to the directory of the custom
 version, I see that cmake uses the headers of the default version.
 
 It seems to me like a regression in commit
 0ae8a3405bb32afadda13f43100484e85f7ef74f (Add qt4/QtCore to help
 find Qt headers when cross-compiling.)
 
 qt4/QtCore is found in /usr/include instead of /opt/qt4.7/include,
 in contradiction with the qmake information (qmake -query
 QT_INSTALL_HEADERS).
 
 Corresponding lines in FindQt4.make:
   FIND_PATH(QT_QTCORE_INCLUDE_DIR QtCore
   
 HINTS ${qt_headers} ${QT_LIBRARY_DIR}
 PATH_SUFFIXES QtCore qt4/QtCore
 
 )
 
 Removing qt4/QtCore fixes the problem, but I guess that the commit
 was useful for other reasons :)
 So my suggestion is to either revert the commit because it
 invalidates a common scenario when using cmake with several Qt
 installations, or to fix the FIND_PATH call, making sure that the
 custom location is found before the default one.
 
 Any idea?
 
 Best regards,
 Benoit.

What version of cmake are you using?

I also have
/usr/include/qt4
and a custom Qt, but do not see this problem with the latest cmake.

The FIND_PATH(QT_QTCORE_INCLUDE_DIR QtCore

HINTS ${qt_headers} ${QT_LIBRARY_DIR}
PATH_SUFFIXES QtCore qt4/QtCore

It should first look for ${qt_headers}/QtCore, which should be
/opt/qt4.7/include/QtCore.

I tried these 3 ways, but was not able to reproduce.
1. PATH=/path/to/custom/qt/bin:$PATH cmake ..
2. CMAKE_PREFIX_PATH=/path/to/custom/qt cmake ..
3. cmake ..  - modify CMakeCache.txt to use custom qmake then re-run

 cmake.

I have no /usr/include in my CMakeCache.txt file.

Can you expand the ${qt_headers} and tell me what you have?
   
   I am using CMake 2.8.7. I would also expect that it first looks for
   ${qt_headers}/QtCore and then qt4/QtCore but this is unfortunately not
   the case for me.
   
   qt_header points to the right directory (/opt/qt4.7/include), so my
   guess is that the problem is related to the FIND_PATH() function. It
   seems that it first checks the default path (/usr/include). If I add
   the
   NO_DEFAULT_PATH argument, it works as expected and
   QT_QTCORE_INCLUDE_DIR
   
   points to the right directory (the custom one):
 FIND_PATH(QT_QTCORE_INCLUDE_DIR QtCore
 
   HINTS ${qt_headers} ${QT_LIBRARY_DIR}
   PATH_SUFFIXES QtCore qt4/QtCore
   NO_DEFAULT_PATH
  
  )
   
   Maybe because of a recent CMake change in FIND_PATH()?
   
   Note: On my system, the PATH is not changed (/usr/bin is *before*
   /opt/qt4.7/bin) and /usr/bin/cmake is linked to /opt/qt4.7/bin/cmake
   using update-alternatives. But that should not change anything and the
   first steps (including _qt4_query_qmake(QT_INSTALL_HEADERS
   qt_headers)) are successful.
   
   Regards,
   Benoit.
  
  According to the docs, /usr/include is searched after any paths given by
  HINTS.  However, I can reproduce your problem by doing this:
  export CMAKE_PREFIX_PATH=/usr
  cmake -DQT_QMAKE_EXECUTABLE=/path/to/custom/qt/bin/qmake ../
  
  but that can easily be fixed by a more standard approach of specifying a
  desired package (in this case, Qt) in CMAKE_PREFIX_PATH instead.
  export CMAKE_PREFIX_PATH=/path/to/qt:/usr
  cmake ../
  
  So, are you setting either CMAKE_PREFIX_PATH or CMAKE_INCLUDE_PATH in the
  environment or in your CMakeLists.txt files?
 
 You got it! CMAKE_PREFIX_PATH is set in my environment. I agree that it can
 easily be fixed, it is however likely to happen again to other users.
 Furthermore, changing CMAKE_PREFIX_PATH when selecting another Qt version
 is probably not the best approach (especially for update-alternatives
 fans).
 
 As for /usr/include, CMAKE_PREFIX_PATH and CMAKE_INCLUDE_PATH should
 actually be searched after the paths given by HINTS. Maybe this behavior
 should be adjusted for FIND_PATH?
 

I doubt FIND_PATH can be adjusted for this.

But we can

Re: [cmake-developers] Target usage requirements and conventions

[Clinton Stimpson]

On Thursday, May 03, 2012 10:21:10 am Stephen Kelly wrote:
 On 05/03/2012 06:19 PM, Ben Boeckel wrote:
  On Thu, May 03, 2012 at 09:35:44 -0600, Clinton Stimpson wrote:
  The include, defines, etc... can be properties on a target when when
  target_use_target() is used, it could extract those properties and apply
  them on the using target.
  
  So we'll also need a way to define private values for these things as
  well. Linking some abstraction library should not automatically link the
  abstracted library, add its header path, or add any defines for it to
  targets that use the abstraction library.
  
  --Ben
 
 You guys should read the wiki page :) You're a few months behind the
 discussions that have already happened.

:) But I don't see anything in the wiki about using this functionality without 
a find_package().

If I have a large project with many shared libraries, can I use this concept 
you are developing to help manage the compile flags for my own libraries within 
my own project?  Or is this strictly for imported targets/find_package()?

-- 
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] Making GUI applications by default

[Clinton Stimpson]

On Mar 4, 2012, at 3:29 PM, Stephen Kelly wrote:

 Stephen Kelly steveire@... writes:
 
 
 Brad King wrote:
 
 The implementation is not what I had in mind when I said implies
 the platform-specific property.  This should be its own property
 that one can set/get normally with no special C++-implemented
 mapping to the other two properties.  The generators should look
 for this property first and only if not set look for the platform-
 specific property.  If either is set the effect is the same.
 
 I see. That's a bit more painful. That will mean touching all generators, 
 and I don't have the easy visual studio or mac access to implement or test 
 them.
 
 I happened to read a little bit about CPack recently
 
 http://www.cmake.org/Wiki/CMake:CPackPackageGenerators#Overview
 
 The recommendation is to not use MACOSX_BUNDLE when using cpack,

I don't see that as a general recommendation for GUI applications on Mac OS X.
Its only true if you use the Bundle generator, which does the equivalent of the 
MACOSX_BUNDLE conversion at cpack time (not install time).  I wouldn't base a 
general statement on a generator where one has a broken make install just to 
make a cpack generator work.

If you use any other cpack generator with a GUI application, you do use 
MACOSX_BUNDLE.

Clint

 so I thought
 maybe that makes it different enough to WIN32_EXECUTABLE that they should be
 different CMAKE_ properties.
 
 set(CMAKE_WIN32_EXECUTABLE ON)
 set(CMAKE_MACOSX_BUNDLE ON)
 
 That would also mean that I can actually submit the patch. I'm not so keen on
 having to change every generator instead. Actually I think the existing patch 
 is
 better than touching every generator anyway (that's at least in part why there
 is an abstraction).
 
 Thanks,
 
 Steve.
 
 
 --
 
 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] Usage of Qt4 for Tests

[Clinton Stimpson]

On Wednesday, February 29, 2012 02:23:47 am Rolf Eike Beer wrote:
 The tests using Qt4 on my machine are failing:
 
 http://open.cdash.org/testDetails.php?test=136849123build=2048757
 http://open.cdash.org/testDetails.php?test=136849126build=2048757
 
 This is because this machine only has QtCore installed, but nothing else.
 I think something like this should be done to only run the tests if all of
 the Qt4 dependencies are found:
 
 diff --git a/Tests/CMakeLists.txt b/Tests/CMakeLists.txt
 index e1dbfe2..bf9bce3 100644
 --- a/Tests/CMakeLists.txt
 +++ b/Tests/CMakeLists.txt
 @@ -274,7 +274,7 @@ IF(BUILD_TESTING)
 
  # run test for DeployQt4 on supported platforms/compilers (which
 depends on BundleUtilities)
  # this test also depends on the existence of the standard qtiff plugin
 -if(QT4_WORKS)
 +if(QT4_WORKS AND QT_QTGUI_FOUND AND QT_QTSQL_FOUND)
ADD_TEST(Qt4Deploy ${CMAKE_CTEST_COMMAND}
  --build-and-test
  ${CMake_SOURCE_DIR}/Tests/Qt4Deploy
 @@ -912,7 +912,7 @@ ${CMake_BINARY_DIR}/bin/cmake -DVERSION=master -P
 ${CMake_SOURCE_DIR}/Utilities/
  )
LIST(APPEND TEST_BUILD_DIRS ${CMake_BINARY_DIR}/Tests/Environment)
 
 -  IF(QT4_WORKS)
 +  IF(QT4_WORKS AND QT_QTGUI_FOUND)
  ADD_TEST(QtAutomoc ${CMAKE_CTEST_COMMAND}
--build-and-test
${CMake_SOURCE_DIR}/Tests/QtAutomoc
 
 Opinions?
 

The Qt4Deploy test can have its QtGui dependency easily removed.  I can take 
care of that one.

The part of your patch for QtAutomoc looks good.

-- 
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] Convention driven CMAKE_USE_PACKAGE macro

[Clinton Stimpson]

 depend on
 ECM, which would be undesirable. I think CMake is the best place for it.
 
 I would like the KDE frameworks use a similar macro too.
 


What about a more generic approach like the following?

add_library(foo IMPORTED ...)
set_target_properties(foo PROPERTIES 
  DEPENDENT_COMPILE_DEFINITIONS FOO_DEFINE 
  DEPENDENT_INCLUDE_DIRECTORIES /path/to/foo/include)

add_executable(bar ...)
target_link_libraries(foo bar)

And that could automatically add -DFOO_DEFINE and -I/path/to/foo/include to 
the bar executable.
So basically any DEPENDENT_property can be pushed to property on the other 
target.

-- 
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] Convention driven CMAKE_USE_PACKAGE macro

[Clinton Stimpson]

On Feb 24, 2012, at 12:00 PM, Brad King wrote:

 On 2/24/2012 1:56 PM, Clinton Stimpson wrote:
 What about a more generic approach like the following?
 
 add_library(foo IMPORTED ...)
 set_target_properties(foo PROPERTIES
   DEPENDENT_COMPILE_DEFINITIONS FOO_DEFINE
   DEPENDENT_INCLUDE_DIRECTORIES /path/to/foo/include)
 
 add_executable(bar ...)
 target_link_libraries(foo bar)
 
 And that could automatically add -DFOO_DEFINE and -I/path/to/foo/include to
 the bar executable.
 So basically any DEPENDENT_property  can be pushed toproperty  on the 
 other
 target.
 
 Nice.  This is exactly the kind of interface I had in mind for the
 usage requirements approach Alex and I were discussing elsewhere
 in this thread.  We will have to think about how to define transitive
 properties of these requirements though.
 

Good.  And I like how it takes CMake into a more declarative direction, for 
places where it makes sense.
A non-declarative approach involves worrying about scoping, ordering, etc...

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] Build faild on Darwin? Don't know why?

[Clinton Stimpson]

On Feb 20, 2012, at 8:21 AM, David Cole wrote:

 On Mon, Feb 20, 2012 at 9:25 AM, Brad King brad.k...@kitware.com wrote:
 On 2/18/2012 5:47 PM, Eric Noulard wrote:
 My recent commit on CPack-dynamicDocSection
 http://cmake.org/gitweb?p=cmake.git;a=shortlog;h=e175af3e74006e6f3a4fdaead20522b29034c45b
 
 may have broken this build
 http://open.cdash.org/testDetails.php?test=135708291build=2018382
 
 the trouble is I cannot imagine why
 
 It seems okay today.  It may have been an intermittent problem
 with the continuous build not being in a fresh tree.
 
 -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
 
 
 The lesson here is:
 
 - ignore dashboard failures for the BundleGenerator test on Mac machines 
 unless it is happening consistently build after build after build
 
 - also ignore any test failures that contain references to a failed run of 
 hdiutil which fails sporadically -- only consider it a real problem with 
 the CMake code if it happens consistently
 

Is it just the Mac OS X 10.4 machines that do this?  I remember having this 
problem on one of our Macs a few times a week, but haven't had that problem for 
a while.  Its running 10.5 now.

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] QtAutomoc dashboard failure?

[Clinton Stimpson]

On Monday, December 19, 2011 02:28:37 pm Alexander Neundorf wrote:
 On Monday 19 December 2011, Clinton Stimpson wrote:
  On Monday, December 19, 2011 01:59:37 pm Alexander Neundorf wrote:
   On Monday 19 December 2011, David Cole wrote:
Alex,

Can you take a look at this and see if you know why QtAutomoc is
failing on this one dashboard?

http://cdash.org/CDash/testDetails.php?test=126108609build=1833949
   
   I had a look, the output looks good:
   Automoc for target codeeditorLib
   AUTOMOC: warning:
   C:/Users/cjstimp/cmake_nightly/cmake/Tests/QtAutomoc/codeeditor.cpp:
   The file includes the moc file codeeditor.moc, but does not contain a
   Q_OBJECT macro. Running moc on
   C:/Users/cjstimp/cmake_nightly/cmake/Tests/QtAutomoc/codeeditor.h !
   Better include moc_codeeditor.cpp for a robust build.
   
   This is what it should say, and this means that the included
   codeeditor.moc has been created, otherwise it would not have compiled.
   
   Clinton, can you please send me the Tests/QtAutomoc/  build directory
   zipped together ?
   
   Thanks
   Alex
  
  I sent a .zip file.  Let me know if you didn't get it.
  Did you see the link error?
 
 The generated codeeditor.moc is empty (0 bytes), but it shouldn't be empty.
 It should have been generated from codeeditor.h.
 I have no idea why this happens.
 Can you run the build with the environment variable VERBOSE set to 1 ?
 Then automoc will print more log messages.
 
  I also noticed it was using the wrong Qt build.  It is building with
  Visual Studio 2005 but using a Qt built with Visual Studio 2008.  I just
  made a change to use a compatible Qt.
 
 Maybe that helps...
 

That does help.  The test now passes for me so we should be fine on cdash 
tomorrow.

-- 
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] QtAutomoc dashboard failure?

[Clinton Stimpson]

On Monday, December 19, 2011 01:59:37 pm Alexander Neundorf wrote:
 On Monday 19 December 2011, David Cole wrote:
  Alex,
  
  Can you take a look at this and see if you know why QtAutomoc is
  failing on this one dashboard?
  
  http://cdash.org/CDash/testDetails.php?test=126108609build=1833949
 
 I had a look, the output looks good:
 Automoc for target codeeditorLib
 AUTOMOC: warning:
 C:/Users/cjstimp/cmake_nightly/cmake/Tests/QtAutomoc/codeeditor.cpp:
 The file includes the moc file codeeditor.moc, but does not contain a
 Q_OBJECT macro. Running moc on
 C:/Users/cjstimp/cmake_nightly/cmake/Tests/QtAutomoc/codeeditor.h !
 Better include moc_codeeditor.cpp for a robust build.
 
 This is what it should say, and this means that the included codeeditor.moc
 has been created, otherwise it would not have compiled.
 
 Clinton, can you please send me the Tests/QtAutomoc/  build directory
 zipped together ?
 
 Thanks
 Alex

I sent a .zip file.  Let me know if you didn't get it.
Did you see the link error?

I also noticed it was using the wrong Qt build.  It is building with Visual 
Studio 2005 but using a Qt built with Visual Studio 2008.  I just made a 
change to use a compatible Qt.

-- 
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] [PATCH] QtDialog: Set Ctrl+Q as the shortcut for quitting the program.

[Clinton Stimpson]

On Tuesday, December 13, 2011 04:51:16 pm Raphael Kubo da Costa wrote:
 QKeySequence::Quit does not work on all platforms, and since it
 translates to Ctrl+Q on all platforms where it does work, Ctrl+Q was
 hardcoded instead.
 ---
  Source/QtDialog/CMakeSetupDialog.cxx |2 ++
  1 files changed, 2 insertions(+), 0 deletions(-)
 
 diff --git a/Source/QtDialog/CMakeSetupDialog.cxx
 b/Source/QtDialog/CMakeSetupDialog.cxx index 1c058d3..338eaff 100644
 --- a/Source/QtDialog/CMakeSetupDialog.cxx
 +++ b/Source/QtDialog/CMakeSetupDialog.cxx
 @@ -26,6 +26,7 @@
  #include QMimeData
  #include QUrl
  #include QShortcut
 +#include QKeySequence
  #include QMacInstallDialog.h
 
  #include QCMake.h
 @@ -99,6 +100,7 @@ CMakeSetupDialog::CMakeSetupDialog()
QObject::connect(this-DeleteCacheAction, SIGNAL(triggered(bool)),
 this, SLOT(doDeleteCache()));
this-ExitAction = FileMenu-addAction(tr(Exit));
 +  this-ExitAction-setShortcut(QKeySequence(Qt::CTRL + Qt::Key_Q));
QObject::connect(this-ExitAction, SIGNAL(triggered(bool)),
 this, SLOT(close()));

Can you instead make that 
+  this-ExitAction-setShortcut(QKeySequence::Quit);

Do you want to redo the patch, or shall we just make the change to use Quit?

-- 
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] [PATCH] QtDialog: Set Ctrl+Q as the shortcut for quitting the program.

[Clinton Stimpson]

On Thursday, December 15, 2011 08:20:14 am Raphael Kubo da Costa wrote:
 Clinton Stimpson clin...@elemtech.com writes:
  On Tuesday, December 13, 2011 04:51:16 pm Raphael Kubo da Costa wrote:
  QKeySequence::Quit does not work on all platforms, and since it
  translates to Ctrl+Q on all platforms where it does work, Ctrl+Q was
  hardcoded instead.
  ---
  
   Source/QtDialog/CMakeSetupDialog.cxx |2 ++
   1 files changed, 2 insertions(+), 0 deletions(-)
  
  diff --git a/Source/QtDialog/CMakeSetupDialog.cxx
  b/Source/QtDialog/CMakeSetupDialog.cxx index 1c058d3..338eaff 100644
  --- a/Source/QtDialog/CMakeSetupDialog.cxx
  +++ b/Source/QtDialog/CMakeSetupDialog.cxx
  @@ -26,6 +26,7 @@
  
   #include QMimeData
   #include QUrl
   #include QShortcut
  
  +#include QKeySequence
  
   #include QMacInstallDialog.h
   
   #include QCMake.h
  
  @@ -99,6 +100,7 @@ CMakeSetupDialog::CMakeSetupDialog()
  
 QObject::connect(this-DeleteCacheAction, SIGNAL(triggered(bool)),
 
  this, SLOT(doDeleteCache()));
 
 this-ExitAction = FileMenu-addAction(tr(Exit));
  
  +  this-ExitAction-setShortcut(QKeySequence(Qt::CTRL + Qt::Key_Q));
  
 QObject::connect(this-ExitAction, SIGNAL(triggered(bool)),
 
  this, SLOT(close()));
  
  Can you instead make that
  +  this-ExitAction-setShortcut(QKeySequence::Quit);
  
  Do you want to redo the patch, or shall we just make the change to use
  Quit?
 
 As I mentioned in the commit message, QKeySequence::Quit will not work
 on all platforms (the documentation says it translates to nothing on
 Windows, for example, and I couldn't use it on the i3 window manager,
 for example). I can change it if you prefer, though.

Ok, the patch is fine.
Is this something that needs brought up to the Qt developer's attention?

-- 
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] Generating imported library targets without the cmake executable

[Clinton Stimpson]

On Wednesday, November 30, 2011 07:33:48 am Stephen Kelly wrote:
 Brad King wrote:
  On 11/30/2011 9:09 AM, Stephen Kelly wrote:
  Brad King wrote:
  Alex was proposing simply to provide the singular name as a variable
  but not
  to cache it.  The only reason to cache a variable is when we're
  searching and
  need to let the user help out or override.  In a Config.cmake file we
  know the answer.
  
  Ok, so you're saying the user should definitely not be able to override
  the value, so it shouldn't be cached. The remaining question is whether
  it should be provided anyway uncached for the reasons Alex described. If
  that should be done, then I can do that.
  
  I don't mind providing it for convenience.  However more variables means
  more variables.  Users may not know which one to use when.  I don't have
  a strong opinion either way.
 
 Ok, my opinion is to provide one variable in plural form for now. If there
 is a reason to provide a singular form, we can add that later. Let's just
 see what Alex and CLinton say before I do that.
 

I have the same opinion -- only providing the plural form, at least for now.

-- 
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] rpaths on Mac

[Clinton Stimpson]

On Monday, November 21, 2011 01:41:57 pm James Bigler wrote:
 Would what you are proposing make the following easier?  This is how I
 setup @rpath on my system.
 
 Why do you need something special?  I use @rpath for the install name by
 doing the following:
 
   if(RELEASE_PUBLIC)
 set_target_properties( my_target PROPERTIES
   INSTALL_NAME_DIR @rpath
   BUILD_WITH_INSTALL_RPATH ON
   )
   endif()
 
 Then I do the following for my executables:
 
 if( RELEASE_INSTALL_BINARY_SAMPLES )
   target_link_libraries( ${target_name}
 -Wl,-rpath,@executable_path/.
 -Wl,-rpath,@executable_path/../../lib
 )
 elseif( RELEASE_PUBLIC)
   target_link_libraries( ${target_name}
 -Wl,-rpath,@executable_path/../lib
 )
 endif()
 
 I also have some code to do some special stuff for BundleUtilities, but I'm
 not sure if it's related to the rpath stuff.

Yes, it'll be simpler.  You'll be able to avoid setting the link flags like 
that.  Instead you can do
set_target_properties(${target_name} PROPERTIES INSTALL_RPATH 
@executable_path)
which is similar to Linux's
set_target_properties(${target_name} PROPERTIES INSTALL_RPATH \$ORIGIN)

BUILD_WITH_INSTALL_RPATH will then become optional.

Then perhaps we can make 
INSTALL_NAME_DIR=@rpath be the default.

-- 
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] rpaths on Mac

[Clinton Stimpson]

On Friday, November 18, 2011 04:59:36 am David Cole wrote:
 On Thu, Nov 17, 2011 at 5:26 PM, Clinton Stimpson clin...@elemtech.com 
wrote:
  On Thursday, November 17, 2011 02:03:15 pm Brad King wrote:
  On 11/17/2011 11:49 AM, Clinton Stimpson wrote:
   I'm experimenting with using @rpath instead of @executable_path and
   @loader_path, because @rpath is useful in some situations where the
   others don't work as well.  For example, I want to avoid setting
   DYLD_LIBRARY_PATH when using a relocatable SDK.  Using @rpath allows a
   user to embed a path in their executable/library that gives the
   location of the SDK libraries that they linked with.  Public SDK
   libraries would also know how to find private SDK libraries with an
   rpath of
   @loader_path and dependencies starting with @rpath.
   
   What needs to be considered if the following is added to
   Platforms/Darwin.cmake?
   
  set(CMAKE_SHARED_LIBRARY_RUNTIME_C_FLAG -Wl,-rpath,)
  set(CMAKE_SHARED_LIBRARY_RUNTIME_C_FLAG_SEP :)
  
  Is that all that is necessary to get the standard RPATH behavior on OS
  X? Nice!
  
  Basically, yes, along with:
   set(CMAKE_INSTALL_NAME_DIR @rpath)
   set(CMAKE_INSTALL_RPATH ...)
  
  To get the desired behavior, we can automate
   set(CMAKE_INSTALL_NAME_DIR @rpath)
  I think it would be nice to have it be @rpath even in the build tree, but
  I don't see that as a requirement.  It could help avoid install name
  changes at install time, or allow people to copy the libraries.
  
   Would that have undesirable side effects?
  
  Since the original RPATH support in CMake pre-dated the feature on OS X
  we implemented INSTALL_NAME_DIR instead.  We need to investigate how the
  two features would/should interact.
  
  We still need a separate INSTALL_NAME_DIR setting and RPATH setting.
  But from what I can tell, INSTALL_NAME_DIR can be fixed to @rpath.
  
   One possibility is adding -rpath link flags to those who currently
   don't have/want it.
  
  We may need a switch to choose between RPATH and INSTALL_NAME_DIR.  The
  default of the switch can be chosen based on the minimum required
  version of CMake.  Over time everyone will start using RPATH instead.
  
  It does look like we need a switch.  But overall, it looks like CMake is
  quite close to having this feature.
  Any idea what the switch can be called?
  
  As a side note, I had been using BundleUtilities and that falls apart
  with @rpath so that is something to fix before having everyone use this.
  
  --
  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
 
 But shouldn't BundleUtilities simply be unnecessary after adopting
 this @rpath strategy/technique?

It would be unnecessary only if all 3rd party libraries also did this.

Consider this:
The Qt libraries in /Library/Frameworks have an identification name like 
QtCore.framework/Versions/4/QtCore.  That is just fine for an installation 
location like /Library/Frameworks, if they adopted the @rpath, then they would 
require their users to link with -rpath.
Also, since they aren't system libraries, one likely wants to package them in 
a bundle, and any binary that links against Qt will need to be fixed by 
install_name_tool, even if cmake-built libraries used @rpath.

For compatibility, I was thinking BundleUtilities could be modified to 
understand @rpath, but still change everything to @executable_path and give 
the same end result as before.  We've had talks in the past about 
BundleUtilities(or a similar thing) taking another argument for the prefix of 
the installation, so we don't have the same parameter used for the install 
names.  I think we'll need that going forward with rpaths.

-- 
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