Hi Owen,
On Mon, Jul 6, 2015 at 3:48 PM, Owen Alanzo Hogarth gurenc...@gmail.com wrote:
I created this simple project but I am having linking errors. Everything
builds correctly but when I try to add my lib to my main.c cmake complains
about linking errors.
Here's what the project looks
I created this simple project but I am having linking errors. Everything
builds correctly but when I try to add my lib to my main.c cmake complains
about linking errors.
Here's what the project looks like: http://pastebin.com/22bCsuiE
if i #include time_utils.h in my main.c I get this error:
Hello,
I was trying to add some file extensions for the Fortran language (.ftn), but I
was not able to get past some errors even after trying a few different options
including appending to CMAKE_Fortran_SOURCE_FILE_EXTENSIONS in a toolchain file.
Ideas on how to get around the following
On 07/02/2015 06:25 PM, Radovan Bast wrote:
I can consistently reproduce it locally on 3 different machines (Ubuntu 14.04
and Arch derivative; gfortran 4.8.4 and 5.1.0).
I have Git bisected the history and this is the commit that broke this
example on my machines:
dear Brad,
SOMEDEF is defined at compile time. Attached is a tarball that contains
the CMakeLists.txt which defines SOMEDEF, a main.F90 and a mymodule.F90
which contains the module which is not built prior to building main.F90.
In principle the problem can be reproduced like this:
```
tar xvzf
Hi guys,
I have a question for you about general practices. I have a top level directory
with a bunch of modules inside:
Nick
|
|module1
|module2
|module3
Module1, module2, and module3 are subdirectories inside of the nick directory.
Each module directory contains src,inc and test (gtest unit
Hey,
there's several options.
- the easiest is probably to create inclusion files on the Nick level,
put the identical functionality in there and include them in the modules.
- a bit cleaner ist to create a e.g. Macros.cmake file on the Nick level,
put the identical functionality in there and
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 a62a39e3c03dd5a0731ade875dce5a7de9f9d892 (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 be855332d9b52fe2474d90fd08f7dea798b126f6 (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 7361966ee0221f706fa27de6422a35a71044ef88 (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 7e86f567aca6b913689dc2d8c17a17936284b811 (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 e5d37f23f1ad2a485b09c0975289ea73025dcb7f (commit)
via
On Mon, Jul 6, 2015 at 8:41 PM, Brad King brad.k...@kitware.com wrote:
On 07/04/2015 06:27 PM, Daniel Pfeifer wrote:
Attached is a patch that adds a subcommand string(APPEND).
This allows to write
string(APPEND string_variable some string)
instead of
set(string_variable
list(APPEND) requires at least one element argument, right?
Can you require the same thing for string(APPEND)? That would make it
symmetric and remove your edge case.
On Mon, Jul 6, 2015 at 2:47 PM, Daniel Pfeifer dan...@pfeifer-mail.de
wrote:
On Mon, Jul 6, 2015 at 8:41 PM, Brad King
dear Brad,
thanks a lot! This is very much appreciated.
Best wishes,
radovan
On Mon, Jul 6, 2015 at 4:41 PM Brad King brad.k...@kitware.com wrote:
On 07/06/2015 09:13 AM, Radovan Bast wrote:
SOMEDEF is defined at compile time. Attached is a tarball that contains
the CMakeLists.txt which
On 07/03/2015 09:09 AM, Konstantin Podsvirov wrote:
About 6 months ago I started a topic cmake-install-components.
Today I am ready to share the results.
Great, thanks! The changes look good except for comments below.
So as not to disturb those who do not need it I have added the
option
On Mon, Jul 6, 2015 at 10:55 PM, James Bigler jamesbig...@gmail.com wrote:
list(APPEND) requires at least one element argument, right?
No, see
https://github.com/Kitware/CMake/blob/master/Source/cmListCommand.cxx#L236
--
Powered by www.kitware.com
Please keep messages on-topic and check the
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 4734ecf7984884887bbaff0592b63d7b0057eb1c (commit)
via
On 07/04/2015 06:27 PM, Daniel Pfeifer wrote:
Attached is a patch that adds a subcommand string(APPEND).
This allows to write
string(APPEND string_variable some string)
instead of
set(string_variable ${string_variable}some string)
Thanks. Please extend the first patch to also add
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 0c1569ccd5cf7fc7b05c255f85616db08b880a85 (commit)
via
On 07/03/2015 05:02 PM, Daniel Pfeifer wrote:
The attached patch hides the progress ticks when the output is shown (-VV).
Good idea. Applied:
CTest: hide progress ticks in verbose output
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=140b1864
Thanks,
-Brad
--
Powered by
On 07/02/2015 10:22 PM, Jason Felds wrote:
it places the -std=gnu++11 (or equivalent) calls in the OTHER_CPLUSPLUSFLAGS
attribute instead of the CLANG_CXX_LANGUAGE_STANDARD attribute.
Yes. This is just because the generator hasn't been taught to do so.
If this is added it also needs to be made
On 07/06/2015 01:52 AM, James Johnston wrote:
I worked on a patch to allow you to pass USES_TERMINAL through
ExternalProject to the underlying add_custom_command().
Very nice. I applied the commit:
ExternalProject: Added new USES_TERMINAL options
On 07/03/2015 10:48 PM, umir...@gmail.com wrote:
However, the Xcode Generator does not handle the -Ofast flag properly,
and then it is necessary to the set Optimization Level manually
when -Ofast flag is utilized in the project.
This is because the Xcode Generator uses just one letter
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 32b7617fd3128dc9f3c4e9198c80ad8ee9b1cc45 (commit)
via
On 07/06/2015 10:54 AM, Roman Donchenko wrote:
Sparse files in tars are a GNU extension that libarchive will use if it
detects holes in the input file, even when using the standard pax/paxr
formats. Not all tar implementations can handle sparse files; in particular,
the internal implementation
On 07/02/2015 04:45 PM, Michael Scott wrote:
On 06/30/2015 05:42 PM, Stephen Kelly wrote:
What is the difference between the intended uses of those existing options
and the intended uses of the new options, given that -Wno-dev is mostly
useful for third parties to silence policy warnings?
20150706)
+set(CMake_VERSION_PATCH 20150707)
#set(CMake_VERSION_RC 1)
---
Summary of changes:
Source/CMakeVersion.cmake |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
hooks/post-receive
--
CMake
Hi,
I worked on a patch to allow you to pass USES_TERMINAL through
ExternalProject to the underlying add_custom_command(). Here is the commit
message:
ExternalProject: Added new USES_TERMINAL options
Added new USES_TERMINAL option to the ExternalProject_Add_Step
function. This option passes
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 22c6064708add4d69d70a0232a27561e89f64c89 (commit)
via
On 07/06/2015 09:13 AM, Radovan Bast wrote:
SOMEDEF is defined at compile time. Attached is a tarball that contains
the CMakeLists.txt which defines SOMEDEF, a main.F90 and a mymodule.F90
which contains the module which is not built prior to building main.F90.
Thanks. I've drafted a fix and a
On 07/02/2015 05:06 PM, Clifford Yapp wrote:
When running the BRL-CAD configure process with the latest CMake
release candidate, the first configure pass completes successfully.
The second pass fails almost immediately with the error:
CMake Error at CMakeLists.txt:120 (configure_file):
Sparse files in tars are a GNU extension that libarchive will use if it
detects holes in the input file, even when using the standard pax/paxr
formats. Not all tar implementations can handle sparse files; in particular,
the internal implementation dpkg uses to extract packages can't. To
maximize
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 5b6816a64e60b34252afeea13ffe122044a60f13 (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 e519d849de1be8c6d80d9406c6b828a4acf37395 (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 eefacae6aff8b518c5b644b8148c3de0cdf84a01 (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 eafb3eee02e59d4ff8987f57d9cab4f72fd12f06 (commit)
via
37 matches
Mail list logo
