Very little. The whole point is to test that the compiler works the way
CMake will invoke it in the generated build system.
But the user does have tons of control over the generated build system so why
can't he have same control have test program compilation? I think in this case
someone
On 06/16/2015 09:31 AM, Ette, Anthony (CDS) wrote:
rts1-4:/home/bzpl46/test2/CMakeFiles/CMakeTmp /usr/ccs/bin/cf77
CMakeFiles/cmTryCompileExec3453195864.dir/testFortranCompiler.f.o -o
cmTryCompileExec3453195864 -rdynamic
/usr/ccs/release/7.3/lib_ia32/ld: cannot find -lrt
That shows it can
rts1-4:/home/bzpl46/test2/CMakeFiles/CMakeTmp /usr/ccs/bin/cf77
CMakeFiles/cmTryCompileExec3453195864.dir/testFortranCompiler.f.o -o
cmTryCompileExec3453195864 -rdynamic
/usr/ccs/release/7.3/lib_ia32/ld: cannot find -lrt
That shows it can be reproduced locally outside of CMake.
Please try
On 06/16/2015 01:21 AM, Ette, Anthony (CDS) wrote:
what control does the user have over the compilation of the test program?
Very little. The whole point is to test that the compiler works the way
CMake will invoke it in the generated build system.
I.e. can I tell cmake to add -L (where to
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=15618
==
Reported By:Sebastian Wouters
Assigned 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 8ec6b905a24f367e12486e39ef47ef5d2a3ba495 (commit)
via
On 06/15/2015 03:03 PM, Robert Goulet wrote:
Updated with improved tests and added docs.
Thanks. Here are more comments.
Please split the patch to do the OUTPUT_NAME/dir changes first.
Update the Tests/PerConfig test to cover these. Since the
RUNTIME_OUTPUT_DIRECTORY properties are learning
Ahh, you are correct. Success! What does this mean?
I found this in the cf77 release notes, not sure if it means anything to us at
this point.
Linking with gcc, g++ or g77:
This release ships with its own updated linker (ld) that can interpret DWARF 3.
If you link cf77generated code using
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 dcae581eee3c3ef75f0dd5d8241e8ae898e9db74 (commit)
via
On 06/16/2015 07:27 AM, Stuermer, Michael SP/HZA-ZSEP wrote:
putting some around tool-names
Applied, thanks:
Utilities/Doxygen: Support tools installed in paths with spaces
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=15c6a4c9
-Brad
--
Powered by www.kitware.com
Please keep
On 06/16/2015 10:00 AM, Ette, Anthony (CDS) wrote:
That shows it can be reproduced locally outside of CMake.
Please try dropping -rdynamic from that command line.
Ahh, you are correct. Success! What does this mean?
This means CMake needs to be able to define and detect an
id for this
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 ee223dfa9138cfe960d5d7a6dc14b044b7e032bf (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 e5ed8b22cb540425f7806257a96b834dcb3fb2c7 (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 abf480d40e0f5b628ba7c91efcfd839eb1f6a5a8 (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 76e4fea2e61b35f16982973c8b25d954907c086a (commit)
via
Running OS X 10.8.5 with Xcode 5.1.1 and Cmake 3.2.x and 3.3.RC and neither
generate a Xcode project file that can be opened by Xcode. We get valid Ninja
and Makefile projects for our project. I was wondering if anyone else has seen
this issue. Not sure if there is something in our project that
Hi,
I'm trying to build the latest CMake release, with the Qt4 gui and including
the docs in Qt help format. I'm using the same recipe as for the 3.2.2
release, but now I see this:
[ 95%] sphinx-build qthelp: see Utilities/Sphinx/build-qthelp.log
cd /build//cmake-3.2.3/Utilities/Sphinx
http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/CMakeDetermineFortranCompiler.cmake;hb=v3.3.0-rc2#l114
Ok. I'm still struggling getting anything unique from the cf77 command line.
They have plenty of custom functions that can be invoked outside of cf77 but
that wouldn't be suitable
What is the output of cf77 --version?
Garbage (see below):
rts1-4:/home/bzpl46 cf77 --version
cf77 Fatal Error: invalid flag -io
I've scoured the cf77 docs and found nothing native so I've responded to
concurrent and again asked how I can find unique identifying information for
cmake to latch
On 06/16/2015 01:44 PM, Ette, Anthony (CDS) wrote:
I'm still struggling getting anything unique from the cf77 command line.
What is the output of cf77 --version?
Okay, the -rdynamic option to cf77 instructs it to build
a shared object (shared library), not an executable program.
That may be
Hello,
I applied some fixes to what becomes CMake 3.3. could you please test
the release candidate?
On 16/06/15 16:27, Michael Jackson wrote:
Running OS X 10.8.5 with Xcode 5.1.1 and Cmake 3.2.x and 3.3.RC and neither
generate a Xcode project file that can be opened by Xcode. We get valid
On 16/06/15 21:27, Gregor Jasny wrote:
Hello,
I applied some fixes to what becomes CMake 3.3. could you please test
the release candidate?
Sorry, somehow overlooked the statement about RC in your mail.
On 16/06/15 16:27, Michael Jackson wrote:
Running OS X 10.8.5 with Xcode 5.1.1 and
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=15619
==
Reported By:Clinton Stimpson
Assigned To:
20150616)
+set(CMake_VERSION_PATCH 20150617)
#set(CMake_VERSION_RC 1)
---
Summary of changes:
Source/CMakeVersion.cmake |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
hooks/post-receive
--
CMake
Okay, The first 3 points are easy and done. But for the unit test, I'm
a little lost.
I found the files you're talking about. I'm not quite sure what those
undocumented macros are doing. I would say though, that I'm not trying
to parse the 'GlobalSection' part of the .sln file, I just need
-Original Message-
From: Brad King [mailto:brad.k...@kitware.com]
Sent: Monday, June 15, 2015 4:11 PM
To: Stuermer, Michael SP/HZA-ZSEP
Cc: cmake-developers@cmake.org
Subject: Re: [cmake-developers] [PATCH] fixed msvc 64 bit build
On 06/15/2015 07:58 AM, Stuermer, Michael
On 06/15/2015 09:46 PM, Richard Ulrich wrote:
So here is the patch with tests and passing the git hooks.
Thank you for the update and sorry again for the inconvenience.
- Your commit's subject line looks a bit too long; I'd move the issue
number into the bulk of the message (It should nicely
2. Is there a way to generate a RPM with standard name:
I mean, something like: cmake-3.2.3-1.el6.x86_64.rpm
Instead of: cmake-3.2.3-Linux-x86_64.rpm
You can add
-D CPACK_OUTPUT_FILE_NAME=cmake-${RPM_RELEASE}.el6.x86_64.rpm
to your packaging command. This will force package
On Monday June 15 2015 23:05:07 Alexander Neundorf wrote:
if you have multiple candidate headers, try them all, and use separate result
variables for every one.
Is that the problem you have ?
Yes. That's probably the thing I missed and why it didn't work; I used a single
variable.
Still, it
Hi Domen,
Thanks, I'll try the CPACK_OUTPUT_FILE_NAME option.
This morning I found an alternative for the permission issue.
As the default attribute in the SPEC file is (-, root, root, -) I tried to
fix generated files.
So I added umask at the beginning of my script and it works!
$ umask 0022
On Monday 15 June 2015 22:43:41 you wrote:
Just a last question: I assume that most find module scripts distributed
with cmake are
not using this feature at the moment, right?
Sadly, no.
After reading your explaination I looked at documentation for FindBoost and
FindGTest
which are both
I have doxygen, gnuplot, html help and the UnxUtils in C:\Program Files
(x86)\ This leads to errors when using one of these tools. I hope putting
some around tool-names does not break anything on linux.
Best Regards
Michael Stürmer
32 matches
Mail list logo
