Hi,
I have:
SET_TARGET_PROPERTIES(MyTarget PROPERTIES
XCODE_ATTRIBUTE_LD_RUNPATH_SEARCH_PATHS ~/Library/Application
Support/MyTarget/Plugins)
and it comes through nicely when running the Xcode IDE, but when using
cmake build (cmd line), the linker gets this:
-Xlinker -rpath -Xlinker
Ok, I escaped the string as \~/Library/Application
Support/MyTarget/Plugins\, and then it comes out OK to the linker.
However... it doesn't work. Dylib dependencies are not found, whereas in
the Xcode IDE, they are! :( :( :(
About to jump from a very high place. Help ?
/Rob
Robert Bielik
For those who couldn't understand my jibberish.. I apologize, never send email
from a phone...
Ill restate...
In general, I want all my unit tests to be built when I do a make all, but I
really don't care if they are up to date for a make install.
Is that a possibility? Ie, add the exclude
In general, I want unit tests, are build when I do a make all, but I really
don't care if they are up to date for a install..
Is that a possibility?
Scott
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware
I found it. You have to create a group on the CDash project admin interface
first, with the same name as what's specified after --track. It is not very
flexible, though.
Is there a way to create groups via the command line? I could set up a git
hook to create the group when a new branch is
Is there anything in the latest CMake version to add additional entries into
the plist file for .app packages? I specifically need the following:
keyNSPrincipalClass/key
stringNSApplication/string
keyNSHighResolutionCapable/key
stringTrue/string
to support Retina displays for our app. Should I
Hi.
You're already (partially) doing it, with the CMAKE_SOURCE_DIR and
Boost_INCLUDE_DIRS variables. You can store whatever list of arguments you
want in a variable and expand it in the proper place. For example this:
set(MyArgs -d sqlite --sqlite-override-null --std c++11 --profile boost
Hi,
With CMake 3.1.2, I don't see my specified COMMENT for a POST_BUILD
command on a library target, viz:
add_custom_command(TARGET ${LIB_TARGET}
POST_BUILD
COMMAND ln -sf $TARGET_LINKER_FILE_NAME:${LIB_TARGET}
Hi,
is there a way in the cmakelists syntax to generate a build script
(make/ninja/...) that will invoke the C/C++ compiler with an '-include file'
or '-include macros' option?
From the GNU cpp man page:
-include file
Process file as if #include file appeared as the first line of
On 3/20/15 12:11 PM, Christopher H Green wrote:
Indeed it might, thank you, but I believe I'm seeing the same behavior
with ninja also.
I can confirm that with CMake 3.2.1, the expected COMMENT is printed
with the UNIX Makefile generator, but not for the Ninja generator. Any
chance of getting
On 20.03.2015 19:41, Chris Green wrote:
On 3/20/15 12:11 PM, Christopher H Green wrote:
Indeed it might, thank you, but I believe I'm seeing the same
behavior with ninja also.
I can confirm that with CMake 3.2.1, the expected COMMENT is printed
with the UNIX Makefile generator, but not for the
Found a solution by adding new functions to the API.
See it here:
https://github.com/espakm/CDash/commit/c12b2726a5a336b7b3a700ef3490ed4e54f6fd45
Any interest in merging this?
Cheers,
Miklos
On 20 March 2015 at 13:43, Miklos Espak m.es...@ucl.ac.uk wrote:
I found it. You have to create a
Indeed it might, thank you, but I believe I'm seeing the same behavior with
ninja also.
Thanks,
Chris.
Sent from my cell.
Original message
From: Nils Gladitz
Date:2015/03/20 11:57 (GMT-06:00)
To: Christopher H Green ,cmake@cmake.org
Subject: Re: [CMake] COMMENT ignored for
On 20.03.2015 16:47, Chris Green wrote:
The documentation doesn't suggest that this is intended behavior. Is
this a bug, or am I doing something wrong? The desired action does get
carried out during a build as desired, but there is no screen output
of COMMENT to herald the generation of the
On 3/20/15 2:10 PM, Nils Gladitz wrote:
On 20.03.2015 19:41, Chris Green wrote:
On 3/20/15 12:11 PM, Christopher H Green wrote:
Indeed it might, thank you, but I believe I'm seeing the same
behavior with ninja also.
I can confirm that with CMake 3.2.1, the expected COMMENT is printed
with
Hi,
I ran into a problem with SunPro Fortran compiler not being able to
create a shared library since the -KPIC flag was missing. The patch
that is attached fixes this. I didn't add a -KPIE as that doesn't
exist for SunPro.
Looking at other compiler configurations, it seems it might be better
to
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 0beaa3508ad731dc0ca1b198b0a5a28b60e682ca (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 5ac4b4738ac4eccf5546d2308268035538020a94 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 6d64981a1e9a676ea076f9d4420e536f7b108dbc (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, master has been updated
via 4faa4c60ce6d66f2789255d94ef90d1a3c7bb6de (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, master has been updated
via c3f416726bee2175804b3004641eac6091df796d (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, master has been updated
via f447027307f32b9caa126631faaeab55b7e2133c (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, master has been updated
via d4d56f636b653c1b5d169be8c476b2f872bc6558 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, master has been updated
via ac7d8684c56063469b3ee03cd4f5a60a4a01789e (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, master has been updated
via 543b20f269df537f3cde6cee1dfaeab6dd31e942 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 820fa8a738a1d988d3cbe4aec834643448072be3 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, master has been updated
via 1b1144b91dcaae05a0caffd3d238e76268600af7 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, master has been updated
via c95e523db87cd503c97ca2a6021614393bb33e0b (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via f855c4e9157360d4f7bd8f13dc5dc1ed1aeb74a6 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 8c1e8b7cf477e0f11e374b435ff8e2e3374f0759 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 15ef2b1ba46c8e4fdcc91b4de6070f3b8cdfab28 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 2c99728ad123267ffb654fd47636b6df600a7c89 (commit)
via
20150320)
+set(CMake_VERSION_PATCH 20150321)
#set(CMake_VERSION_RC 1)
---
Summary of changes:
Source/CMakeVersion.cmake |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
hooks/post-receive
--
CMake
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 3caa1a1c5afc83628dae8312f94b20f32c18c623 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 95e89a6bfa0917ed99ff58c698d8260eabb4dcc9 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 09b0ec9428c45f7d95bf4f2aedac27f2ccec80c6 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via a745e32037c7dfd326a0776decf3592686f8200c (commit)
via
* 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
My solution needs to generate additional target indeed for one pre-generated
header, so if all your 1000+ targets will share same precompiled header
(given the compiler flags don't change) then you will have just one (single)
additional target.
It's very rare (not to mention risky) to be
Sorry, I'm also very late on this thread, but there was a suggestion
that codesigning should be in CMake instead of CPack. I agree and also
say it needs to be integrated as part of the build process when
specified.
Here's a real world workflow. I use JavaScriptCore in my Mac
application which
On 03/19/2015 09:57 AM, Geoffrey Viola wrote:
Fixed.
Great, thanks. I'll take another look at the updated patch next week.
-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
On 03/18/2015 05:50 PM, Alex Merry wrote:
I made some changes in a copy of this module for work that separated out the
target creation, as well as adding debug/release support. I'll check about
being allowed to release that work, but I doubt it'll be an issue.
Great. Will you be able to
Two requests please:
* The option to use existing headers instead of autogenerated ones.
* Implementing PCH support without additional targets. ReactOS already has like
1000+ targets, and we currently use PCH on almost all of them, so imagine if
this official implementation doubles our targets
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 4bf20848b81d98a2d138862f47aba20a19c92652 (commit)
via
On 03/20/2015 04:23 AM, Steven Vancoillie wrote:
I ran into a problem with SunPro Fortran compiler not being able to
create a shared library since the -KPIC flag was missing. The patch
that is attached fixes this. I didn't add a -KPIE as that doesn't
exist for SunPro.
Applied, thanks:
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via c583042c126d064d75eb6cecefc80b4e644c2abd (commit)
via
On 03/13/2015 08:44 AM, Daniel Pfeifer wrote:
I pushed some work to https://github.com/purpleKarrot/CMake/commits/pch
Thanks for working on this. I'm hoping others will respond because
I have little experience with PCH.
target_precompile_headers(bar INTERFACE bar.h)
[snip]
This command is
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via ac6036ba4216f1059b2e9531676de6a99e79227e (commit)
via
On Fri, Mar 20, 2015 at 6:35 PM, Amine Khaldi amine.kha...@reactos.org wrote:
Two requests please:
* The option to use existing headers instead of autogenerated ones.
That is an implementation detail. It should not make a difference
whether the precompiled header is used through your existing
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=15461
==
Reported By:Chris Green
Assigned To:
50 matches
Mail list logo
