[cmake-developers] $BUILD_INTERFACE genex regression
cmTarget: Refactor ComputeLinkImplementation (24637979):
http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=24637979
Seems to have broken this reduced testcase:
cmake_minimum_required(VERSION 3.0)
set(LIBRARIES
foobar.lib
barfoo.lib
)
add_executable(foo foo.cpp)
target_link_libraries(foo PUBLIC $BUILD_INTERFACE:${LIBRARIES})
For the Ninja generator in 3.0 this produces a build.ninja with:
LINK_LIBRARIES = -rdynamic -lfoobar.lib -lbarfoo.lib
Since 24637979 this produces:
LINK_LIBRARIES = -rdynamic $BUILD_INTERFACE:foobar.lib -lbarfoo.lib
I can work around this by wrapping the libraries with $BUILD_INTERFACE
individually or by quoting the entire genex.
Given the title of the commit I'm guessing this wasn't an intentional
change of behavior?
Nils
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] New command 'file(LOCK_DIRECTORY ...)'
On 08-Oct-14 16:45, Brad King wrote:
On 10/08/2014 07:52 AM, Ruslan Baratov wrote:
Okay :) I just not sure that I understand to pass to some other
process goal correctly.
That was just an example of why one might want to drop management
of the lock by CMake without actually unlocking it. Perhaps the
code is starting a daemon and passes off responsibility for the
unlock side to the daemon process.
Okay, got it.
* we just need to `unlock` file so the other instance will use it:
file(UNLOCK_FILE /path/to/shared/file)
# now anybody can do the lock
Yes. We also need the locking API to return information about
whether we really acquired the lock.
So it can be TRY_LOCK and LOCK. But does the TRY_LOCK really needed?
With LOCK we can try to lock and spin until acquire, but what to do with
TRY_LOCK? Just give up?
* we need other process to inherit the lock (what for?), i.e. move
ownership (?):
file(LOCK_FILE /path/to/shared/file)
execute_process(${CMAKE_COMMAND} --take-ownership /path/to/shared/file
...)
# unlocked by execute_process
I think all we need there is a way to ask CMake to take over
responsibility for a lock that it did not originally create.
It can also be in the file() command.
Thanks,
-Brad
Okay, so here is the commands inspired by C++:
file(TRY_LOCK /path/to/file result) # try to lock and return TRUE
on success (needed?)
file(LOCK ...) # lock until unlock (unlock by further code (what if
exit/crashed?) or by deamon)
file(LOCK_GUARD ...) # lock for scope of current function or until exit
file(UNLOCK ...) # explicit unlock of LOCK/LOCK_GUARD
Locking directory is equivalent to locking file `cmake.lock` in
directory /path/to/shared/directory/:
file(DIRECTORY_TRY_LOCK ...)
file(DIRECTORY_LOCK /path/to/shared/directory/) # == file(LOCK
/path/to/shared/directory/cmake.lock)
file(DIRECTORY_LOCK_GUARD ...)
file(DIRECTORY_UNLOCK ...)
If any of this commands failed (e.g. have no permissions) - exit with
unsuccessful code (i.e. FATAL_ERROR) ?
* http://en.cppreference.com/w/cpp/thread/try_lock
* http://en.cppreference.com/w/cpp/thread/lock
* http://en.cppreference.com/w/cpp/thread/lock_guard
* http://en.cppreference.com/w/cpp/thread/mutex/unlock
--
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] Ninja RC cmcldeps regression
On 10/10/2014 01:10 PM, Nils Gladitz wrote:
Ninja on windows invokes the resource compiler through cmcldeps.
When passing ${CMAKE_BINARY_DIR} as an include directory CMake used to
(3.0) add the absolute path to the command line; now -I. is being
added instead.
The relative path does not seem to work in context of cmcldeps/rc since
headers in ${CMAKE_BINARY_DIR} aren't found anymore.
This seems to have broken with cmLocalGenerator: Simplify
GetIncludeFlags output formatting (b9aa5041):
http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=b9aa5041
I used the following test case to reproduce the issue:
cmake_minimum_required(VERSION 3.0)
file(WRITE foo.cpp int main() {})
file(WRITE foo.rc #include bar.rc)
file(WRITE ${CMAKE_BINARY_DIR}/bar.rc )
add_executable(foo foo.cpp foo.rc)
target_include_directories(foo PRIVATE ${CMAKE_BINARY_DIR})
Nils
--
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] Call for volunteer for CPackRPM, CPackDeb maintenance.
On 10/09/2014 10:58 AM, Eric Noulard wrote: This message is an open request to find volunteer maintainers for CPackRPM and CPackDeb I did contribute to CMake/CPack for some time (~2007) now but my CMake free time is now too small to be able to test and integrate contribution/patches to CPackDeb and CPackRPM. Thank you for your help over all these years, Eric! -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] New command 'file(LOCK_DIRECTORY ...)'
What is the main use case for locking files and directories from the
CMake language?
I feel slightly uncomfortable, without being able to put my finger on
exactly why, with the prospect of adding this to CMake...
Behavior when there's a lock that still exists (by bug/mistake) after
CMake is done running is going to be strange and possibly
hard-to-diagnose / hard-to-understand.
Let's make sure the use case is quite strong before we accept the
possibility of stale locks in CMake.
Thanks,
David C.
On Fri, Oct 10, 2014 at 7:45 AM, Ruslan Baratov via cmake-developers
cmake-developers@cmake.org wrote:
On 08-Oct-14 16:45, Brad King wrote:
On 10/08/2014 07:52 AM, Ruslan Baratov wrote:
Okay :) I just not sure that I understand to pass to some other
process goal correctly.
That was just an example of why one might want to drop management
of the lock by CMake without actually unlocking it. Perhaps the
code is starting a daemon and passes off responsibility for the
unlock side to the daemon process.
Okay, got it.
* we just need to `unlock` file so the other instance will use it:
file(UNLOCK_FILE /path/to/shared/file)
# now anybody can do the lock
Yes. We also need the locking API to return information about
whether we really acquired the lock.
So it can be TRY_LOCK and LOCK. But does the TRY_LOCK really needed? With
LOCK we can try to lock and spin until acquire, but what to do with
TRY_LOCK? Just give up?
* we need other process to inherit the lock (what for?), i.e. move
ownership (?):
file(LOCK_FILE /path/to/shared/file)
execute_process(${CMAKE_COMMAND} --take-ownership /path/to/shared/file
...)
# unlocked by execute_process
I think all we need there is a way to ask CMake to take over
responsibility for a lock that it did not originally create.
It can also be in the file() command.
Thanks,
-Brad
Okay, so here is the commands inspired by C++:
file(TRY_LOCK /path/to/file result) # try to lock and return TRUE on
success (needed?)
file(LOCK ...) # lock until unlock (unlock by further code (what if
exit/crashed?) or by deamon)
file(LOCK_GUARD ...) # lock for scope of current function or until exit
file(UNLOCK ...) # explicit unlock of LOCK/LOCK_GUARD
Locking directory is equivalent to locking file `cmake.lock` in directory
/path/to/shared/directory/:
file(DIRECTORY_TRY_LOCK ...)
file(DIRECTORY_LOCK /path/to/shared/directory/) # == file(LOCK
/path/to/shared/directory/cmake.lock)
file(DIRECTORY_LOCK_GUARD ...)
file(DIRECTORY_UNLOCK ...)
If any of this commands failed (e.g. have no permissions) - exit with
unsuccessful code (i.e. FATAL_ERROR) ?
* http://en.cppreference.com/w/cpp/thread/try_lock
* http://en.cppreference.com/w/cpp/thread/lock
* http://en.cppreference.com/w/cpp/thread/lock_guard
* http://en.cppreference.com/w/cpp/thread/mutex/unlock
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] $BUILD_INTERFACE genex regression
On 10/10/2014 05:09 AM, Nils Gladitz wrote:
set(LIBRARIES
foobar.lib
barfoo.lib
)
add_executable(foo foo.cpp)
target_link_libraries(foo PUBLIC $BUILD_INTERFACE:${LIBRARIES})
This is basically writing:
target_link_libraries(foo PUBLIC $BUILD_INTERFACE:foobar.lib barfoo.lib)
which was never intended to be supported. It worked only as an accident
of the 3.0 implementation. In 2.8.12.2 it did not work.
I can work around this by wrapping the libraries with $BUILD_INTERFACE
individually or by quoting the entire genex.
This was the intended interface.
I'm willing to regress this because:
- It restores 2.8.12 behavior
- The quoting is easy to do
- It is very hard to fix this without un-doing all the other
improvements enabled by the refactoring that broke this.
I will add mention of this in the 3.1 release notes.
Thanks,
-Brad
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] $BUILD_INTERFACE genex regression
On 10/10/2014 03:14 PM, Brad King wrote: I can work around this by wrapping the libraries with $BUILD_INTERFACE individually or by quoting the entire genex. This was the intended interface. I'm willing to regress this because: - It restores 2.8.12 behavior - The quoting is easy to do - It is very hard to fix this without un-doing all the other improvements enabled by the refactoring that broke this. I will add mention of this in the 3.1 release notes. Good enough for me, thanks! Nils -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] New command 'file(LOCK_DIRECTORY ...)'
On 10-Oct-14 16:58, David Cole wrote:
What is the main use case for locking files and directories from the
CMake language?
I feel slightly uncomfortable, without being able to put my finger on
exactly why, with the prospect of adding this to CMake...
I've described the situation in the first message of this thread:
sharing resources between different cmake builds. If you want the
particular case: I'm developing cmake-based package manager that share
the builds of ExternalProject_Add. I'm experienced problems even when
working on my local machine (I've started long-build in one console,
then accidentally connect to the same shared directory in other
console), but the main problem here is the server auto-builds which
usually start multiple jobs simultaneously.
Behavior when there's a lock that still exists (by bug/mistake) after
CMake is done running is going to be strange and possibly
hard-to-diagnose / hard-to-understand.
That's *exactly* the problem I have and why I start this discussion.
Currently I'm using mkdir command which return 0 only if directory
created by current process (just to clarify, not the cmake -E
make_directory). This works fine for me (tested on windows (mingw,
cygwin), linux and mac). But I can't (or I don't know how) make remove
this directory when I Ctrl+C my build (or abort the job on jenkins
server). My current implementation just keep spinning with message:
Directory locked by cmake, build started in directory
cmake-binary-dir at timestamp.
Let's make sure the use case is quite strong before we accept the
possibility of stale locks in CMake.
Command `file(LOCK_GUARD ...)` will cover 100% of my needs. Other
commands that I've mentioned used to cover suggestions from Brad K. (may
be I've just understand them wrong).
Ruslo
Thanks, David C. On Fri, Oct 10, 2014 at 7:45 AM, Ruslan Baratov via
cmake-developers cmake-developers@cmake.org wrote:
On 08-Oct-14 16:45, Brad King wrote:
On 10/08/2014 07:52 AM, Ruslan Baratov wrote:
Okay :) I just not sure that I understand to pass to some other
process goal correctly.
That was just an example of why one might want to drop management
of the lock by CMake without actually unlocking it. Perhaps the
code is starting a daemon and passes off responsibility for the
unlock side to the daemon process.
Okay, got it.
* we just need to `unlock` file so the other instance will use it:
file(UNLOCK_FILE /path/to/shared/file)
# now anybody can do the lock
Yes. We also need the locking API to return information about
whether we really acquired the lock.
So it can be TRY_LOCK and LOCK. But does the TRY_LOCK really needed? With
LOCK we can try to lock and spin until acquire, but what to do with
TRY_LOCK? Just give up?
* we need other process to inherit the lock (what for?), i.e. move
ownership (?):
file(LOCK_FILE /path/to/shared/file)
execute_process(${CMAKE_COMMAND} --take-ownership /path/to/shared/file
...)
# unlocked by execute_process
I think all we need there is a way to ask CMake to take over
responsibility for a lock that it did not originally create.
It can also be in the file() command.
Thanks,
-Brad
Okay, so here is the commands inspired by C++:
file(TRY_LOCK /path/to/file result) # try to lock and return TRUE on
success (needed?)
file(LOCK ...) # lock until unlock (unlock by further code (what if
exit/crashed?) or by deamon)
file(LOCK_GUARD ...) # lock for scope of current function or until exit
file(UNLOCK ...) # explicit unlock of LOCK/LOCK_GUARD
Locking directory is equivalent to locking file `cmake.lock` in directory
/path/to/shared/directory/:
file(DIRECTORY_TRY_LOCK ...)
file(DIRECTORY_LOCK /path/to/shared/directory/) # == file(LOCK
/path/to/shared/directory/cmake.lock)
file(DIRECTORY_LOCK_GUARD ...)
file(DIRECTORY_UNLOCK ...)
If any of this commands failed (e.g. have no permissions) - exit with
unsuccessful code (i.e. FATAL_ERROR) ?
* http://en.cppreference.com/w/cpp/thread/try_lock
* http://en.cppreference.com/w/cpp/thread/lock
* http://en.cppreference.com/w/cpp/thread/lock_guard
* http://en.cppreference.com/w/cpp/thread/mutex/unlock
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on
Re: [cmake-developers] Ninja RC cmcldeps regression
On 10/10/2014 04:11 PM, Brad King wrote: Thanks, fixed and test added: Ninja: Fix RC include directories regression http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=23c8eeb7 Thanks! Nils -- 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] $BUILD_INTERFACE genex regression
On 10/10/2014 10:18 AM, Nils Gladitz wrote: As a side node for post-3.1 development it might be nice to have the Ninja generator properly escape the $ from e.g. those broken generator expressions that leak through or alternatively have CMake produce an error during generation. I think the most user-friendly approach would be an error during generation, or at least a warning. Perhaps a policy to make the warning an error. The main challenge will be deciding what to actually consider wrong without breaking real use cases. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] $BUILD_INTERFACE genex regression
On 10/10/2014 09:17 AM, Nils Gladitz wrote: On 10/10/2014 03:14 PM, Brad King wrote: I will add mention of this in the 3.1 release notes. Good enough for me, thanks! Here is a release note entry: Help: Add note about restoring pre-3.0 link libraries genex behavior http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8bd81981 -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
On 10/09/2014 11:19 AM, Brad King wrote: I merged it for testing in 'next'. Everything tested cleanly! Adam, Clinton, thanks for your help bringing this topic to maturity. It was the last non-regression topic I'm planning to take for 3.1. I squashed the fixes and revised commit messages slightly. Then I merged to 'master': Merge topic 'fix-OSX-bundle-rpaths-and-Qt5' http://www.cmake.org/gitweb?p=cmake.git;a=commitdiff;h=26bffa6e -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic
Clinton Stimpson wrote: 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). Picking a message randomly, to respond to - Can someone tell me what this comment is referring to? # FIXME: This should be part of Qt5 CMake scripts, but unfortunatelly # Qt5 Mac support is missing there. Thanks, Steve. -- 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 0015203]: CheckStructHasMember breaks on -Wunused-value
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=15203
==
Reported By:Lekensteyn
Assigned To:
==
Project:CMake
Issue ID: 15203
Category: Modules
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2014-10-10 17:46 EDT
Last Modified: 2014-10-10 17:46 EDT
==
Summary:CheckStructHasMember breaks on -Wunused-value
Description:
When CMAKE_C_FLAGS containg -Wall -Werror, CheckStructHasMember will always fail
due to the generated code appearing as:
int main()
{
struct FOO* s;
s-MEMBER;
return 0;
}
See the attached patch for a fix. Don't know whether some -std flag will also
bail out on int main() rather than int main(void), but that's a different issue.
This one is about breakage due to very strict warnings on a modern compiler (GCC
4.9.1).
==
Issue History
Date ModifiedUsername FieldChange
==
2014-10-10 17:46 Lekensteyn New Issue
2014-10-10 17:46 Lekensteyn File Added:
0001-CheckStructHasMember-avoid-breakage-on-Wall.patch
==
--
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
