Awesome! Thanks for sorting that out. Hope it will now serve well for Amine.
Would it be default for projects targeting min 3.3?
-- Adam
Wiadomość napisana przez Brad King brad.k...@kitware.com w dniu 23 mar
2015, o godz. 14:49:
On 03/18/2015 01:41 PM, Adam Strzelecki wrote:
IIUC
* The option to use existing headers instead of autogenerated ones.
My solution (which is about PCH support to existing CMake version) does not
auto generate any headers.
* Implementing PCH support without additional targets. ReactOS already has
like 1000+ targets, and we currently use PCH
Could we rename this? Currently target_* functions are all related to
usage requirements and these are not usage requirements.
Honestly I don't understand your request. What would be then the name that
better represents what the function does.
Also please note this is proposed API to be
Does your solution support Ninja generator? I ask because any existing
solution based on upstream CMake won't work with the Ninja generator. Peter's
solution is the only existing solution we know about.
Yes, it was meant to work with Makefiles and Ninja.
Does your solution support C source
Dear CMake developers,
I wish to raise up the subject about native precompiled header support in
CMake. There are obvious reasons to use precompiled headers with big source
code bases, and there were several requests on the list for precompiled header
support and several 3rd party
Hi. It makes me curious why CUDA support is not just implemented as compiler
via proper CMakeDetermineCUDACompiler and other files defining how to handle
.cu files, but rather it uses just awkward 3rd party functions, cmake script
wrappers, etc, which basically obscure whole process and instead
Let me put my 2¢. I have feeling that we are mixing up signing (install)
packages, such as .pkg (OSX) or .msi (Windows), with signing bundles .app or
whatever OSX binaries (that can keep signature inside macho).
I think that CPack should be responsible of signing only what it creates. Since
The nightly binary works again. The first working version after
this gap is now:
Great! Now, do you plan code signing the CMake.app? Do you guys have Mac
Developer ID?
--Adam
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
Please hold your breath, and don't yet revert my patches because you will end
up with bundle that you cannot code-sign anyway for 10.10 and =10.9.5 and it
will be bad release that will be rejected by Gatekeeper upon launch.
First of all this is in fact Qt bug, please follow discussion at:
We have never symlinked Resources/ to Version/Current/Resources since we
place icons on other images under the Resources/ folder.
The Info.plist has always been placed in the root of Contents, and is still
there after the changes.
Sorry, maybe I it wasn't clear enough but I am talking
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:
f9fcea6803f636adfc9f5755d9c92c802cdc2fb6
Author: Adam Strzelecki o...@java.pl
Date: Tue Oct 21 16:42:33 2014 +0200
Ensure framework symlinks and Info.plist exist
This restores Qt SDK 4.8 and = 10.6.5 codesign compatibility improving
embedding frameworks using correct bundle layout described at:
https
Following discussion regarding fix-OSX-bundle-rpaths-and-Qt5 topic I just
wanted to share with you how CMake looks with Qt4 vs Qt5 on Yosemite:
https://www.dropbox.com/s/knnybhed8fahste/CMake3.1rc1-Qt4.8.6-Yosemite.png
$
/Volumes/cmake-3.0.20140930-g37776-Darwin64-universal/CMake.app/Contents/bin/cmake-gui
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.
Did you
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.
AFAIR it is about installing correct app bundle PlugIns. Qt provides half-baked
Side note: this is not a fair characterization of Qt's support for CMake.
(…)
Furthermore, all the CMake-related files come with Qt5 and are maintained
there rather than in CMake. This is much easier than Qt4, where FindQt4
in CMake has needed maintenance with every new upstream version.
Of
I was looking at the BundleUtilities failure after the above fixes, and I
noticed it unconditionally removes paths.
It does that because all bundles frameworks/libraries are referenced by
@executable/loader_path and all @rpath references will be replaced, so there no
point to have LC_RPATH
FYI pushed e646a14f61 BundleUtilities: Check install_name_tool has
-delete_rpath which is safest way to check if we can use -delete_rpath as it
was introduced somewhere in 10.6 SDK, but there's no guarantee what SDK user
has even it runs more recent OSX.
--Adam
--
Powered by www.kitware.com
This is the simplest solution for the upcoming 3.1 release because
it just restores behavior to what 3.0 does. I've done it here:
Okay. But still I feel like this is just workaround rather than solution for
the problem.
This is not about supporting projects that do it wrong. Ninja
wants
To clarify as far as I understand it this particular issue is with building
ReactOS on regular Windows rather than using CMake under ReactOS.
Which of course doesn't mean that there shouldn't be a dashboard for it
nonetheless :)
Yup, this is what I understand. It isn't a problem with
As a result of this, it's no longer possible to use the new CMake to compile
ReactOS, which makes us see this as a severe regression, considering that
CMake is the build system we use to compile the project.
Adam, Brad and co, can you please help ?
If I understand correctly the change
From what I remember from the IRC discussion ...
They are regular (not generated) source files that are listed as dependencies
(but not outputs) of custom commands.
Okay now I get it. So actually 7243c951 (Ninja: Don't limit custom cmd
side-effects to build folder (#14972)) is to blame not
This will not be done before the freeze for 3.1 on Thursday.
Reverting 7243c951 will resolve the problem for ReactOS in
out-of-source builds. So, we either revert that or hope Ninja can
be fixed to deal with the large dependency lists w/out crashing.
In meantime I've pushed
Sure, I think it would be good to require 10.6.
We also have uses of the -delete_rpath/-add_rpath parameters in
cmInstallTargetGenerator.cxx, and the test of that already requires 10.6 or
greater.
Moreover I believe nobody nowadays builds for 10.5 on 10.5. Since 10.6 with
Xcode 3 supports
A test for both OS X and Linux will help justify the API changes.
Well. All I can say that failing tests were already addressed in latest version
of this branch. Also it does not break existing functions signature or
behavior. All new parameters are optional.
I have no other means to prove
Please merge the topic to 'next' for testing when you're ready.
We can at least see if the dashboard stays clean with it.
Done.
--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
I think the delayed-\n approach is the simplest. In the
case that the output is interrupted by other content it
almost certainly means something is going wrong anyway.
Does CMake use popen to launch processes? Or it just spawns them providing them
direct access to stdin/out/err? If it was
FYI stage/compact-status-log was updated with more elegant C++ implementation
introducing new cmStdoutFilter cmThread utility classes enabled when certain
headers are present in the system, so in cmakemain.cxx we simply put:
cmStdoutFilter stdoutFilter(-- );
--Adam
--
Powered by
Not an big issue but official DMG bundles are 40 MB where my manually built one
is 21 MB (half of it).
So any reason for:
* providing universal FAT binaries instead of 64-bit only for =10.6 Darwin64
build, as anyway there is 32-bit build for these who have 32-bit only CPU?
* using DMG zlib
What happens if something else occurs in between that prints
a message?
That's why my solution is completely automatic, does not require any changes in
existing modules, and it works as desired so only:
-- Doing something
-- Doing something - Result
That arrive to stdout are compacted
We will *NOT* be introducing use of *THREADS* in CMake just
to filter our own output.
Yeah, got it. Are subprocess allowed then?
(…) just to filter our own output.
Please note that such solution that filters stdout low level is superior to
doing it as CMake owns level because cmake may be
Again, shouldn't we consider having CMP0011 always NEW for internal modules /
or do implicit pushpop for include when CMP0011 is NEW *OR* when included
module is part of CMake own modules?
--Adam
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
What if stdout's buffer happens to fill up and flush anyway?
I think I can provide other terminal-less solution via filtering stdout and
stderr via pipe and background thread.
I got some proof-of-concept program already. Idea is:
stdout stderr are duped and proxied by some background thread.
e464a698e773dcbaba26b5af0327561312717b58
Author: Adam Strzelecki o...@java.pl
Date: Mon Sep 22 20:53:48 2014 +0200
Automatically compact two subsequent status lines
This is done with background thread acting as stdout/stderr proxy monitoring
subsequent lines emitted to stdout. Only lines beginning
CMake.app on
10.9.5 and Yosemite.
commit e6cdf62d3a7d8b30466bb82f04026f8a06222c8a
Author: Adam Strzelecki o...@java.pl
Date: Thu Sep 4 15:01:17 2014 +0200
Framework codesign Resources/Info.plist Current
We need to ensure copied framework has proper layout with
Resources/Info.plist
FYI unfortunately this solution does not work for CMakeFiles.txt with
cmake_minimum_required(VERSION 2.6.1) or earlier because of CMP0011 that does
implicit PUSH/POP does not work there. So setting cmake_policy(SET CMP0054 NEW)
is internal modules will cause this policy to be not popped and
Addendum: Maybe CMP0011 should be forced implicitly for all built-in modules?
--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
I've pushed stage/CMP0054-FindCUDA:
commit 8998557e7c9a7542e78e07b8b06fd728604f0bdf
Author: Adam Strzelecki o...@java.pl
Date: Tue Sep 16 23:31:44 2014 +0200
FindCUDA: Audit for modern CMP0054 if() syntax
Enables CMP0054 for whole module to silence quoted variable expansion
Since the policy may or may not be active (depending on the user's project)
they might be using FindCUDA.cmake with CMP0054 set to NEW or OLD. To get
identical (and warning free) behavior irregardless of the current policy
setting Adam added the proposed ugliness.
Putting my 2¢, we can
After that change is dropped, I give a +1 for the patch set.
Done, both in attached 3/5 patch and GitHub branch of mine.
--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
This is done by gathering LC_RPATH commands for main bundle executable and
using it for @rpath lookup in dependent frameworks.
All functions that need to carry rpaths to now take optional rpaths argument.
This enabled apps using @rpath to be bundled correctly, which will be necessary
for
FYI I pushed stage/fix-OSX-bundle-rpaths-and-Qt5 topic for final review.
Regards,
--
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
If I understand correctly all modules included via include/find_package have
implicit POLICY PUSH and POP at the EOF. Wouldn't it be reasonable to require
all internal .cmake files to begin with:
cmake_policy(VERSION 3.1) # or whatever version the module was tested
against
Then before
This silents possible CMP0054 related warnings.
---
Modules/FindCUDA.cmake | 14 +++---
Modules/FindCUDA/run_nvcc.cmake | 2 +-
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/Modules/FindCUDA.cmake b/Modules/FindCUDA.cmake
index 9348aa5..2e2b21c 100644
---
Wait, what? This is actually the opposite of what that policy is for, no?
Adam, I don't blame you, just to get that said first. The question is: does
this policy warning trigger far too often?
Yes, you are absolutely right. But the problem is that internal modules run in
whatever policy is
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
I had to revert again because it causes the Qt4Deploy to
fail. The topic changes the signature of gp_file_type.
User projects could be calling that, so we can't change it.
In this case it is the Modules/DeployQt4.cmake file that
was calling it.
Thanks for spotting that. I've send updated
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
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
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
No? These functions are called by other codes and we can't just change the
meaning of the arguments.
You are completely right. I am changing all stuff back, once I pass rpath as
optional argument we can have exepath everywhere. Thanks for your feedback.
Regards,
--
Adam
--
Powered by
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
--
Powered by www.kitware.com
Please keep messages on-topic and
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,
--
Adam
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
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
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
I have sent updated 3/6 4/6. Rest of patches remain the same. I've tested on
all 3 platforms: OSX, Windows Linux. Tests are now running fine.
Regards
--
Adam
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
I think it would be nice to move
get_item_rpaths() from BundleUtilities.cmake to gp_item_get_rpaths() in
GetPrerequisites.cmake.
Well, this function is generic enough to (possible) serve other routines or
even in CMakeLists.txt, so I'd leave it as it is.
And how does your patch or patch
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
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
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
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
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
---
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
---
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.
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
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
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:
Ninja generator ensures that all custom commands being target dependencies are
run before other sources compilation. However in case there are no such
dependencies it does currently generate empty phony rules which clutter build
graph.
This change make Ninja generator produce this rules only when
Actually custom command can write wherever it wants to, such as temporary
folder or source folder, possibly violating rules that only build folder should
be affected. Therefore we should consider custom command dependency at any path
as possible side effect adding phony rule.
---
Previously all explicit dependencies inside build folder were considered as
possible build command side-effects and phony rules were produced for them in
case they don't exist yet starting build. This however incorrect since regular
compile inputs need to exist otherwise cmake will fail. Moreover
Excuse me if it was discussed already, reported, etc. Even it doesn't affect me
anyway since I use Ninja, but some of my colleagues still use Make and do
parallel builds and fancy output is produced: (now some HTML format ;P)
[ 5%] [ 15%] [ 21%] [ 26%] [ 26%] Building CXX object
Intel Composer XE 2015 Beta 2 deprecates all options starting with -o for sake
of compatibility with other compilers expecting anything goes after -o... is
output file name.
---
Modules/FindOpenMP.cmake | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git
This is related to discussion at http://www.cmake.org/Bug/view.php?id=14972 and
your commit 539356f12. I am writing it here since you are not following this
bug, and maybe somebody else can also elaborate on this subject.
As you can see Brad me managed to fix some duplicated phony rules issue
FYI I have submitted patches that fix these issues at:
http://www.cmake.org/Bug/view.php?id=14972
Regards,
--
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
Consider following example:
CMakeLists.txt
==
cmake_minimum_required(VERSION 2.6)
project(TestCUDA CXX)
find_package(CUDA)
cuda_add_executable(test_cuda test_cuda.cu)
test_cuda.cu
int main(int argc, char const *argv[]) { return 0; }
Running: cmake -GNinja ninja
This is same example sent in my previous mail to this ML:
CMakeLists.txt
==
cmake_minimum_required(VERSION 2.6)
project(TestCUDA CXX)
find_package(CUDA)
cuda_add_executable(test_cuda test_cuda.cu)
test_cuda.cu
int main(int argc, char const *argv[]) { return 0; }
Now
76 matches
Mail list logo
