Hello,
I have noticed after upgrading to Cmake 3.7 (3.8.2 problem still
exists): when using object libraries, generated object files now persist
in project tree (just after configuration).
You can see Qt Creator screenshot at
https://bugreports.qt.io/browse/QTCREATORBUG-18308
Actually, whe
Hi, I am trying to let the user pick their own compiler/linker flags through
the cache, whilst providing sane defaults.
The problem is, I rely on the CMAKE_CXX_COMPILER_ID variable to set these
defaults which is only available after the project() command is used. This
also causes the CMAKE_CXX
upgrading from cmake 3.7.1 to cmake version 3.8.2 resolved the issue.
On 06/02/2017 11:53 AM, Burlen Loring wrote:
After upgrading to latest XCode and command line tools on OSX Sierra
our project that uses CMake to mix C++ and Fortran fails to configure.
Full output below. Any ideas?
here are
Hi Frank,
It's really a matter of personal style. There's a multitude of different
ways that people format multi-line function calls so no one way is right or
wrong. For instance:
foo(
bar1
bar2)
foo(
bar1
bar2
)
foo(
bar1
bar2
)
foo(bar1
bar2)
foo(bar1
bar2
)
foo(bar1
After upgrading to latest XCode and command line tools on OSX Sierra our
project that uses CMake to mix C++ and Fortran fails to configure. Full
output below. Any ideas?
here are version
cmake version 3.7.1
GNU Fortran (Homebrew GCC 7.1.0) 7.1.0
Apple LLVM version 8.1.0 (clang-802.0.4
Well it's interesting but clearly you are providing help in only one kind
of organisation.
For example:
- if you are doing a library that have public and private headers, it
helps A LOT to have the public headers
in an "include" directory - you don;t support this option;
- you do not support