Re: [cmake-developers] RFC/Review Request: Topic GNUInstallDirs_debian-multiarch-fix
On 15/01/14 20:37, Brad King wrote: > This topic looks good to me. Please merge to 'next' for testing. Merged. Thanks, Daniele -- 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] RFC: add version to project() call
On 2014-01-15 16:25, Alexander Neundorf wrote:
On Wednesday 15 January 2014, Alexander Neundorf wrote:
And, to actually produce the breakage, at some place the VERSION argument
must have been added.
With the current state of my branch, this could be worked around by
unsetting the guard variable:
project(Foo VERSION 1.2.3)
unset(CMAKE_PROJECT_VERSION_SET_BY_PROJECT_COMMAND)
add_subdir(B)
This way B would be protected from that change in behaviour.
I could also add more logic, to try to detect if PROJECT_VERSION has been set
manually, e.g. project() could reset PROJECT_VERSION only if it has the same
value as ${${ParentProjectName}_VERSION}. Then it would only break if there
was a manual set(PROJECT_VERSION ...) before a project() call without VERSION,
and if that manually set version was the same as the version in the "parent
project".
IMHO your last suggestion (very good idea, btw!) is more than adequate,
especially given the original weakness of my "objection" (which was
always more along the lines of "did you consider this case, and should
we worry about it?").
--
Matthew
--
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] RFC: add version to project() call
On Wednesday 15 January 2014, Alexander Neundorf wrote:
> On Wednesday 15 January 2014, Matthew Woehlke wrote:
> > On 2014-01-14 18:00, Alexander Neundorf wrote:
> > > On Tuesday 14 January 2014, Matthew Woehlke wrote:
> > >> While that sounds good for 99.9% of cases, what about the case of
> > >> project A that includes project B, where B is not updated, but A
> > >> decides to start using project(...VERSION...). Now if B was using
> > >> PROJECT_VERSION internally, it is broken. (Note that I'm implying that
> > >> B is e.g. a separate repository that may not be "as easy to
> > >> update/fix as A".)
> > >
> > > You mean
> > > CMakeLists.txt:
> > >
> > > project(Foo VERSION 1.2.3)
> > >
> > >
> > >
> > > add_subdir(B)
> > >
> > > B/CMakeLists.txt:
> > >
> > > set(PROJECT_VERSION "4.5.6")
> > > project(Bar)
> > >
> > >
> > > Indeed.
> > > In that case, PROJECT_VERSION will be unset afterwards.
> >
> > Exactly. I wanted to point it out, but as that's probably unusual, I
> > would be okay ignoring that case.
> >
> > > If it would be
> > >
> > > B/CMakeLists.txt:
> > >
> > >
> > > project(Bar)
> > > set(PROJECT_VERSION "4.5.6")
> > >
> > > everything is fine.
> >
> > ...until B/C/CMakeLists.txt also calls project() :-). Basically, you
> > (can) get into trouble if you "update" your project to use
> > project(VERSION) and also have an "external" sub-project that tries to
> > use PROJECT_VERSION. However, as much as folks¹ occasionally bleat about
> > this use case (having an embedded "external" project), I suspect it's
> > not actually very common², and anyway there is only a problem when the
> > sub-project *also* uses PROJECT_VERSION (which I suspect is also rare in
> > general, and more so the intersection of the two).
> >
> > Again, given the above, I've no objection to breaking that case, which
> > may well only exist in the hypothetical sense with no 'in the wild'
> > instances actually existing.
>
> And, to actually produce the breakage, at some place the VERSION argument
> must have been added.
> With the current state of my branch, this could be worked around by
> unsetting the guard variable:
>
>
> project(Foo VERSION 1.2.3)
>
>
> unset(CMAKE_PROJECT_VERSION_SET_BY_PROJECT_COMMAND)
> add_subdir(B)
>
> This way B would be protected from that change in behaviour.
I could also add more logic, to try to detect if PROJECT_VERSION has been set
manually, e.g. project() could reset PROJECT_VERSION only if it has the same
value as ${${ParentProjectName}_VERSION}. Then it would only break if there
was a manual set(PROJECT_VERSION ...) before a project() call without VERSION,
and if that manually set version was the same as the version in the "parent
project".
Or, maybe, project() without VERSION should simply NOT clear PROJECT_VERSION.
Then it may be a somewhat inconsistent or not ideal behaviour, but OTOH there
is zero chance for breaking an existing build by adding a VERSION somewhere.
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
Re: [cmake-developers] [PATCH] Help: Fix typo in `if's documentation.
On 01/15/2014 02:51 PM, Raphael Kubo da Costa wrote: > --- > Help/command/if.rst | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Applied, thanks! Help: Fix typo in 'if()' command documentation http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5968b6e0 -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
[cmake-developers] [PATCH] Help: Fix typo in `if's documentation.
--- Help/command/if.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Help/command/if.rst b/Help/command/if.rst index 49c356e..a45b995 100644 --- a/Help/command/if.rst +++ b/Help/command/if.rst @@ -187,7 +187,7 @@ above-documented signature accepts : variables, if so their defined values are used otherwise the original value is used. -* Both left and right hand argumemnts to ``VERSION_LESS``, +* Both left and right hand arguments to ``VERSION_LESS``, ``VERSION_EQUAL``, and ``VERSION_GREATER`` are independently tested to see if they are defined variables, if so their defined values are used otherwise the original value is used. -- 1.8.5.2 -- 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] RFC/Review Request: Topic GNUInstallDirs_debian-multiarch-fix
On 01/15/2014 12:31 PM, Daniele E. Domenichelli wrote: > Is there any issue in using > get_property(_libdir_set CACHE CMAKE_INSTALL_LIBDIR PROPERTY TYPE SET) > instead? That should be fine. > It is a bit complicated, but I added some documentation... Thanks. > I'm still not completely sure about what should happen if both the > cache and normal variable exist [snip] > The user should still see > the normal one, until he goes out of scope, though. When set() sets a CACHE entry it erases the normal variable from the current scope to expose the value of the cache entry. However, the set_property method of setting the cache value does not do this so the normal one should persist as desired. I did some manual testing and it seems to work as expected. This topic looks good to me. Please merge to 'next' for testing. Thanks, -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
Re: [cmake-developers] RFC/Review Request: Topic GNUInstallDirs_debian-multiarch-fix
On 15/01/14 16:27, Brad King wrote:
> On 01/15/2014 10:11 AM, Daniele E. Domenichelli wrote:
>> +get_property(_libdir_set CACHE PROPERTY CMAKE_INSTALL_LIBDIR SET)
>
> That should be
>
> get_property(_libdir_set CACHE CMAKE_INSTALL_LIBDIR PROPERTY TYPE)
Is there any issue in using
get_property(_libdir_set CACHE CMAKE_INSTALL_LIBDIR PROPERTY TYPE SET)
instead?
When reading the code, the "SET" makes it easier for me to understand
that I want to know whether the variable is set or not, and I don't
care about the value... But I don't know if there is some performance
issue or any other reason not to use it.
Also perhaps it is possible that the user will set it to an empty
string? (Not sure if it really makes sense)
> Also I realized that __LAST_CMAKE_INSTALL_PREFIX should be called
> _GNUInstallDirs_LAST_CMAKE_INSTALL_PREFIX since it holds the value
> that this *module* last used as CMAKE_INSTALL_PREFIX.
Ok, renamed.
> Hmm...will this logic work correctly if GNUInstallDirs is included
> in more than one place in a project? The test:
>
> +if(NOT DEFINED CMAKE_INSTALL_LIBDIR
> +OR NOT "${__LAST_CMAKE_INSTALL_PREFIX}" STREQUAL
> "${CMAKE_INSTALL_PREFIX}")
>
> should not succeed the second time. Please verify with manual
> testing. Also this line should be tweaked to not consider the
> __LAST_CMAKE_INSTALL_PREFIX if it is not defined.
I moved the test for _libdir_set at the beginning, and added a check if
__LAST_CMAKE_INSTALL_PREFIX (now
_GNUInstallDirs_LAST_CMAKE_INSTALL_PREFIX) is defined. Now the test is
this:
get_property(_libdir_set CACHE CMAKE_INSTALL_LIBDIR PROPERTY TYPE SET)
if(NOT DEFINED CMAKE_INSTALL_LIBDIR OR (_libdir_set
AND DEFINED _GNUInstallDirs_LAST_CMAKE_INSTALL_PREFIX
AND NOT "${_GNUInstallDirs_LAST_CMAKE_INSTALL_PREFIX}" STREQUAL
"${CMAKE_INSTALL_PREFIX}"))
If CMAKE_INSTALL_LIBDIR is not defined, it is always executed.
Otherwise
* if _libdir_set is false it is not executed (meaning that it is not
a cache variable)
* if _GNUInstallDirs_LAST_CMAKE_INSTALL_PREFIX is not defined it is
not executed
* if _GNUInstallDirs_LAST_CMAKE_INSTALL_PREFIX and CMAKE_INSTALL_PREFIX
are the same string it is not executed.
_GNUInstallDirs_LAST_CMAKE_INSTALL_PREFIX is updated after the
execution, of this part of code, therefore at the next inclusion
of the file, CMAKE_INSTALL_LIBDIR is defined, and the 2 strings are
equal, meaning that the if is not executed the code the second time.
It is a bit complicated, but I added some documentation...
I'm still not completely sure about what should happen if both the
cache and normal variable exist, i.e. if one runs cmake
-DCMAKE_INSTALL_LIBDIR=foo, and inside the code, before the inclusion
of GNUInstallDirs there is a set(CMAKE_INSTALL_LIBDIR bar).
Is this a possible use case? I think that at the moment the code is
still executed, but the comparison will be between the value computed
from the previous prefix and the _normal_ variable, but eventually the
replaced variable will be the _cache_ one. The user should still see
the normal one, until he goes out of scope, though.
I believe it should either skip this code (but I don't know if it is
possible to check if a normal variable exists, or instead compared with
the cache variable, and update it if required. What do you think?
Thanks,
Daniele
--
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] RFC: add version to project() call
On Wednesday 15 January 2014, Matthew Woehlke wrote: > On 2014-01-14 18:00, Alexander Neundorf wrote: > > On Tuesday 14 January 2014, Matthew Woehlke wrote: > >> While that sounds good for 99.9% of cases, what about the case of > >> project A that includes project B, where B is not updated, but A decides > >> to start using project(...VERSION...). Now if B was using > >> PROJECT_VERSION internally, it is broken. (Note that I'm implying that B > >> is e.g. a separate repository that may not be "as easy to update/fix as > >> A".) > > > > You mean > > CMakeLists.txt: > > > > project(Foo VERSION 1.2.3) > > > > > > > > add_subdir(B) > > > > B/CMakeLists.txt: > > > > set(PROJECT_VERSION "4.5.6") > > project(Bar) > > > > > > Indeed. > > In that case, PROJECT_VERSION will be unset afterwards. > > Exactly. I wanted to point it out, but as that's probably unusual, I > would be okay ignoring that case. > > > If it would be > > > > B/CMakeLists.txt: > > > > > > project(Bar) > > set(PROJECT_VERSION "4.5.6") > > > > everything is fine. > > ...until B/C/CMakeLists.txt also calls project() :-). Basically, you > (can) get into trouble if you "update" your project to use > project(VERSION) and also have an "external" sub-project that tries to > use PROJECT_VERSION. However, as much as folks¹ occasionally bleat about > this use case (having an embedded "external" project), I suspect it's > not actually very common², and anyway there is only a problem when the > sub-project *also* uses PROJECT_VERSION (which I suspect is also rare in > general, and more so the intersection of the two). > > Again, given the above, I've no objection to breaking that case, which > may well only exist in the hypothetical sense with no 'in the wild' > instances actually existing. And, to actually produce the breakage, at some place the VERSION argument must have been added. With the current state of my branch, this could be worked around by unsetting the guard variable: project(Foo VERSION 1.2.3) unset(CMAKE_PROJECT_VERSION_SET_BY_PROJECT_COMMAND) add_subdir(B) This way B would be protected from that change in behaviour. 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
Re: [cmake-developers] RFC/Review Request: Topic GNUInstallDirs_debian-multiarch-fix
On 01/15/2014 10:11 AM, Daniele E. Domenichelli wrote:
> -set_property(CACHE CMAKE_INSTALL_LIBDIR PROPERTY VALUE
> "${_LIBDIR_DEFAULT}")
> +get_property(_libdir_set CACHE PROPERTY CMAKE_INSTALL_LIBDIR SET)
That should be
get_property(_libdir_set CACHE CMAKE_INSTALL_LIBDIR PROPERTY TYPE)
Also I realized that __LAST_CMAKE_INSTALL_PREFIX should be called
_GNUInstallDirs_LAST_CMAKE_INSTALL_PREFIX since it holds the value
that this *module* last used as CMAKE_INSTALL_PREFIX.
Hmm...will this logic work correctly if GNUInstallDirs is included
in more than one place in a project? The test:
+if(NOT DEFINED CMAKE_INSTALL_LIBDIR
+OR NOT "${__LAST_CMAKE_INSTALL_PREFIX}" STREQUAL "${CMAKE_INSTALL_PREFIX}")
should not succeed the second time. Please verify with manual
testing. Also this line should be tweaked to not consider the
__LAST_CMAKE_INSTALL_PREFIX if it is not defined.
Thanks,
-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
Re: [cmake-developers] Review Request for ExternalProjects: Only update certain git submodules
Hi Folks, That would be a great contribution. I will give a try to the patch by the beginning of next week. This is something that would be useful for CTK [1]. Thanks for working on this, Jc [1] http://www.commontk.org On Wed, Jan 15, 2014 at 10:03 AM, Brad King wrote: > On 01/10/2014 08:58 AM, David Cole wrote: > > Not that I'm a skeptic (well, ok, maybe a smidge...) but I would > > like to have *independent* confirmation from somebody else that it at > > least "works for them" before we merge this into CMake. > > The silence in this thread indicates no one is planning to step forward > for this. > > David, if the implementation looks correct, the smoke test case works, > and no existing test cases regress then I think this is ready. Please > shepherd this topic through 'next'. > > Thanks, > -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 > -- +1 919 869 8849 -- 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] RFC/Review Request: Topic GNUInstallDirs_debian-multiarch-fix
On 15/01/14 15:29, Brad King wrote:
> On 01/14/2014 11:47 AM, Daniele E. Domenichelli wrote:
>> Updated the topic to behave in this way. Can you please review it again?
>
> Please update the comment introducing __LAST_LIBDIR_DEFAULT to explain
> that it is the default we compute from __LAST_CMAKE_INSTALL_PREFIX,
> not a cache entry for the value that was last used as the default.
Fixed.
>
> This line:
>
> + if(DEFINED ${__LAST_CMAKE_INSTALL_PREFIX})
>
> should not have the ${}, right?
Yes, sorry... Fixed.
> In this line:
>
> +set(__LAST_CMAKE_INSTALL_PREFIX "${CMAKE_INSTALL_PREFIX}" CACHE INTERNAL
> "CMAKE_INSTALL_PREFIX during last run" FORCE)
>
> you don't need FORCE for INTERNAL cache entries. Since the user cannot
> edit them anyway the set() command always forces the value.
I didn't know that, thanks for explaining. Fixed.
> There is one issue I neglected to raise last time around. One of the
> design features of the current GNUInstallDirs implementation is that
> all the cache entries are created inside "if(NOT DEFINED ...)" guards.
> This allows projects to set the values as normal variables before
> including GNUInstallDirs to avoid having the entries cached or user-
> editable.
>
> In order to preserve this feature you'll need to use get_property(CACHE)
> when CMAKE_INSTALL_LIBDIR is defined to make sure it is actually a cache
> entry before updating it. If it is a plain variable then we should
> trust that the project intentionally set it as desired.
I changed it in this way:
-set_property(CACHE CMAKE_INSTALL_LIBDIR PROPERTY VALUE
"${_LIBDIR_DEFAULT}")
+get_property(_libdir_set CACHE PROPERTY CMAKE_INSTALL_LIBDIR SET)
+if(_libdir_set)
+ set_property(CACHE CMAKE_INSTALL_LIBDIR PROPERTY VALUE
"${_LIBDIR_DEFAULT}")
+endif()
+unset(_libdir_set)
Will this work?
I updated the topic. Thanks!
Cheers,
Daniele
--
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 for ExternalProjects: Only update certain git submodules
On 01/10/2014 08:58 AM, David Cole wrote: > Not that I'm a skeptic (well, ok, maybe a smidge...) but I would > like to have *independent* confirmation from somebody else that it at > least "works for them" before we merge this into CMake. The silence in this thread indicates no one is planning to step forward for this. David, if the implementation looks correct, the smoke test case works, and no existing test cases regress then I think this is ready. Please shepherd this topic through 'next'. Thanks, -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
Re: [cmake-developers] RFC/Review Request: Topic GNUInstallDirs_debian-multiarch-fix
On 01/14/2014 11:47 AM, Daniele E. Domenichelli wrote:
> Updated the topic to behave in this way. Can you please review it again?
Please update the comment introducing __LAST_LIBDIR_DEFAULT to explain
that it is the default we compute from __LAST_CMAKE_INSTALL_PREFIX,
not a cache entry for the value that was last used as the default.
This line:
+ if(DEFINED ${__LAST_CMAKE_INSTALL_PREFIX})
should not have the ${}, right?
In this line:
+set(__LAST_CMAKE_INSTALL_PREFIX "${CMAKE_INSTALL_PREFIX}" CACHE INTERNAL
"CMAKE_INSTALL_PREFIX during last run" FORCE)
you don't need FORCE for INTERNAL cache entries. Since the user cannot
edit them anyway the set() command always forces the value.
There is one issue I neglected to raise last time around. One of the
design features of the current GNUInstallDirs implementation is that
all the cache entries are created inside "if(NOT DEFINED ...)" guards.
This allows projects to set the values as normal variables before
including GNUInstallDirs to avoid having the entries cached or user-
editable.
In order to preserve this feature you'll need to use get_property(CACHE)
when CMAKE_INSTALL_LIBDIR is defined to make sure it is actually a cache
entry before updating it. If it is a plain variable then we should
trust that the project intentionally set it as desired.
Thanks,
-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
Re: [cmake-developers] QtCreator breaks with cmake master
On 13.01.2014 23:59, Nils Gladitz wrote: Has anyone else tried running QtCreator (3.0) on windows with cmake master? I tried and got "Qt Creator has no kits that are suitable for CMake projects. Please configure a kit". Apparently I was running 2.8.1 and this has been fixed in 3.0: https://bugreports.qt-project.org/browse/QTCREATORBUG-10452 Which also explains why this was working fine on Linux where I actually did run 3.0. Nils -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0014701]: check_include_file never re-runs because it use the variable as cache
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=14701 == Reported By:Andreas Pakulat Assigned To: == Project:CMake Issue ID: 14701 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2014-01-15 05:17 EST Last Modified: 2014-01-15 05:17 EST == Summary:check_include_file never re-runs because it use the variable as cache Description: When using check_include_file to verify a certain header can be used, the result of the try_compile is cached by check_include_file using the same variable that is passed in to check_include_file. This means a second run of cmake will not run the try-compile again because the variable is already defined and hence the check at the top of check_include_file goes into the else branch. This breaks the common idiom of running cmake for a project to find out which dependencies might be missing, then installing needed dependencies and simply re-run cmake (without deleting the build directory). In addition this is rather hard to debug for someone that just uses a project and is not overly familiar with CMake. == Issue History Date ModifiedUsername FieldChange == 2014-01-15 05:17 Andreas PakulatNew Issue == -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0014700]: Errors in FILE COPY operations don't report failing cause
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=14700 == Reported By:Lluís Batlle Assigned To: == Project:CMake Issue ID: 14700 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2014-01-15 03:59 EST Last Modified: 2014-01-15 03:59 EST == Summary:Errors in FILE COPY operations don't report failing cause Description: If a syscall makes copy fail (no space left on device, permission denied, ...), cmake does not report anything beyond "file COPY cannot copy file". It would be very helpful to have the actual system error related to the failed copy. == Issue History Date ModifiedUsername FieldChange == 2014-01-15 03:59 Lluís Batlle New Issue == -- 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
