The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=15130
==
Reported By:tim blechmann
Assigned To:
> Please run the CMake test:
> ctest -C Debug -R BundleUtilities -V
> locally on these platforms and revise accordingly.
Okay, will do tommorow. Thanks for follow up.
--Adam
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=15129
==
Reported By:yaoyansi
Assigned To:
===
On 09/04/2014 12:45 PM, Adam Strzelecki wrote:
>> Thanks. I've applied the series and merged to 'next' for testing:
>
> Thanks!
I had to revert the topic because it fails the BundleUtilities test
on Linux and Windows on our continuous builds:
http://open.cdash.org/testDetails.php?test=27887342
On 9/4/2014 1:43 PM, Adam Strzelecki wrote:
First of all, it looks if "find" exists on system, otherwise it falls back to old (slow)
behavior. So "find" is optional dependency.
My main concern is that it finds a "find" that does not work as you
expect. Also, if it were done in C++ it would aut
> I would be concerned with the portability of the arguments to find.
find DIR -perm +FLAGS is part of POSIX/SUS
http://pubs.opengroup.org/onlinepubs/007904875/utilities/find.html
I guess it exists on systems dated 199x.
> How much faster is this?
With CMake.app build, about 50x. Really going
On 9/4/2014 12:49 PM, Brad King wrote:
On 09/04/2014 12:43 PM, Adam Strzelecki wrote:
Generally specifying UNIX mask for present/missing bits
Rather than trying to do this with file(GLOB), perhaps we should
consider a file(FIND) command for this purpose. It could have
more options, including
On 09/04/2014 12:43 PM, Adam Strzelecki wrote:
> Generally specifying UNIX mask for present/missing bits
Rather than trying to do this with file(GLOB), perhaps we should
consider a file(FIND) command for this purpose. It could have
more options, including pattern matching, and eventually
supersed
> Thanks. I've applied the series and merged to 'next' for testing:
Thanks!
> For the last change, might something like that be needed on
> Windows too?
Yes, this is very likely. I can investigate that how it looks for Windows apps.
--Adam
--
Powered by www.kitware.com
Please keep messages
> On 09/04/2014 11:15 AM, Rolf Eike Beer wrote:
>> I wonder if the "right" solution would instead be to add some additional
>> flags to GLOB/GLOB_RECURSE where one could e.g. specify that the file is
>> executable, or is a directory.
>
> That would be useful functionality regardless of this appl
On 09/04/2014 09:31 AM, Bach, Pascal wrote:
> With the current implementation I sent this seems to work and the SDK ends up
> in
> The generated vxproj files for try compile.
I don't see anything in the patch that could do that.
CMakeDetermineCompilerId generates a test .vcxproj file that
gets
On 09/04/2014 05:53 PM, Brad King wrote:
Most commands just implement InitialPass, which gets the expanded
arguments. Some implement InvokeInitialPass which gets the args
before expansion. The cmIfCommand does this already, and its
call to cmMakefile::ExpandArguments could be updated to request
On 09/04/2014 11:41 AM, Nils Gladitz wrote:
> I assume the fact that arguments were quoted would have to be preserved
> and the implementation of all existing commands touched so that they can
> actually make use of that information (even if only if() would currently
> make use of it).
Most com
On 09/04/2014 05:13 PM, Brad King wrote:
As I have explained every other time it has come up there is exactly
one way to fix it: a policy that makes expansion happen only for
unquoted arguments. Someone just has to do it.
The fact that this behaviour has persisted this long and that no one ha
On 09/04/2014 11:15 AM, Rolf Eike Beer wrote:
> I wonder if the "right" solution would instead be to add some additional
> flags to GLOB/GLOB_RECURSE where one could e.g. specify that the file is
> executable, or is a directory.
That would be useful functionality regardless of this application.
Am 04.09.2014 15:11, schrieb Adam Strzelecki:
It makes whole executable process quicker on UNIX, especially for large
bundles
containing many files, since using find narrows results to only files
having
executable flags then all further tests follow.
---
Modules/BundleUtilities.cmake | 19
On 09/04/2014 10:51 AM, Nils Gladitz wrote:
> I am rather used to "if()" as well but safe_if()/if_noexpand() might
> still be more readable than the workarounds that people are using now to
> get something close to the expected behavior with regular if() [1].
If "if()" is never fixed people will
On 09/04/2014 04:40 PM, Brad King wrote:
On 09/04/2014 10:25 AM, Nils Gladitz wrote:
I think a new command would ("if_noexpand") would make the "correct"
code less readable than the "incorrect" code. Also the implicit-bool
conversion of variables is more readable IMO; consider
if(${FOO_FOUND}
On 09/04/2014 10:25 AM, Nils Gladitz wrote:
> This keeps coming up and there probably have been many discussions on
> how this might be "fixed" as well.
As I have explained every other time it has come up there is exactly
one way to fix it: a policy that makes expansion happen only for
unquoted a
Another approach might be to add STRING_EQUAL and STRING_MATCHES (or
similarly unambiguous names) operators that do not do the variable
lookup.
The documentation would start with:
if( STRING_EQUAL )
if( STRING_MATCHES )
...i.e., not mentioning anywhere for these operators.
D
--
Powered by w
This keeps coming up and there probably have been many discussions on
how this might be "fixed" as well.
I am wondering if we could provide an alias for the "if" command (e.g.
"safe_if") that would inherit cmIfCommand but would reimplement
GetVariableOrString() without the variable lookup.
T
Hi Adam,
Thanks. I've applied the series and merged to 'next' for testing:
BundleUtilities: Use 'find' on UNIX for fast executable lookup
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=634b4d5a
GetPrerequisites: Make sure dyld placeholders are prefixes
http://cmake.org/gitweb?p=cmake.gi
> > This won't' work as the code gets called multiple times
>
> Right, it gets called inside try_compile projects too. Actually
> the SDK information will have to be propagated into those too.
> That means it needs to go in files like CMakeSystem.cmake or
> CMakeCCompiler.cmake that are configure
On 09/03/2014 05:20 PM, Chuck Atkins wrote:
> stage/use-consistent-regex-for-info-strings
The proposed regex is now:
INFO:[A-Za-z0-9_]+\\[[^]]*\\]
It looks good to me.
Thanks,
-Brad
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.or
On 09/04/2014 06:42 AM, Bach, Pascal wrote:
> This won't' work as the code gets called multiple times
Right, it gets called inside try_compile projects too. Actually
the SDK information will have to be propagated into those too.
That means it needs to go in files like CMakeSystem.cmake or
CMakeCC
Therefore we need to bundle it (if present) too when fixing Mac OS X app bundle.
---
Modules/BundleUtilities.cmake | 8
1 file changed, 8 insertions(+)
diff --git a/Modules/BundleUtilities.cmake b/Modules/BundleUtilities.cmake
index 5823813..5759e24 100644
--- a/Modules/BundleUtilities.c
Otherwise CMake.app bundle will not run when using Qt5.
---
Source/QtDialog/CMakeLists.txt | 28 +++-
1 file changed, 27 insertions(+), 1 deletion(-)
diff --git a/Source/QtDialog/CMakeLists.txt b/Source/QtDialog/CMakeLists.txt
index 8da88c1..03c2fb4 100644
--- a/Source/QtD
This is done by gathering LC_RPATH commands for main bundle executable and
using it for @rpath lookup in dependent frameworks.
To achieve this all utility functions now take path to executable rather than
path to its directory.
This enabled apps using @rpath to be bundled correctly, which will be
Mac OS X dyld placeholders should be always prefixes, otherwise this can lead
to some undefined behavior.
---
Modules/GetPrerequisites.cmake | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Modules/GetPrerequisites.cmake b/Modules/GetPrerequisites.cmake
index 05c2edb..4944
This makes rpaths populated (if any), so libraries containing @rpath will be
resolved properly.
---
Modules/BundleUtilities.cmake | 30 +++---
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/Modules/BundleUtilities.cmake b/Modules/BundleUtilities.cmake
index
It makes whole executable process quicker on UNIX, especially for large bundles
containing many files, since using find narrows results to only files having
executable flags then all further tests follow.
---
Modules/BundleUtilities.cmake | 19 ++-
1 file changed, 18 insertions(+),
- Allow setting CMAKE_VS_WINCE_SDK to specify the SDK.
- The user is warned if he uses a version different Windows CE different
from 8.0 and not CMAKE_PLATFORM_TOOLSET is specified.
- Docuentation for WINCE and CMAKE_VS_WINCE_SDK added.
---
Help/variable/CMAKE_VS_WINCE_SDK.rst | 13 +++
> > + else if (this->SystemName == "WindowsCE")
> > +{
> > +this->SystemIsWindowsCE = true;
> > +if (!this->InitializeWindowsCE(mf))
>
> At the beginning of this block you should check/reject when
> the generator name specified a platform name. Something like:
>
> if(this->Pla
33 matches
Mail list logo
