[CMake] Determine Verbosity in Custom Language Scripts

I've defined a custom language for my project which is simply a wrapper around GCC. The "compiler" for this language is a CMake script which invokes g++ followed by objcopy. I would like to use CMake's standard verbosity system - either VERBOSE=1 for Unix Makefiles or -v or Ninja (maybe there are

Re: [cmake-developers] [CMake] Why does INTERFACE type targets only support whitelisted properties?

On Fri, Jan 8, 2016 at 9:12 AM, Nils Gladitz wrote: > > > On 01/08/2016 02:50 PM, Yves Frederix wrote: > >> You are explicitly mentioning 'setting' of a property. IMHO there is a >> big difference between setting and getting a property. If >> white/blacklisting is enforced

Re: [CMake] Why does INTERFACE type targets only support whitelisted properties?

Taylor Braun-Jones wrote: > Consider library project Foo that uses a header-only project Bar. In > FooConfig.cmake, it is a important to ensure any projects using Foo also > use the exact same version of Bar that Foo was originally built with COMPATIBLE_INTERFACE_STRING and similar properties

Re: [CMake] Why does INTERFACE type targets only support whitelisted properties?

On Fri, Jan 8, 2016 at 9:12 AM, Nils Gladitz wrote: > > > On 01/08/2016 02:50 PM, Yves Frederix wrote: > >> You are explicitly mentioning 'setting' of a property. IMHO there is a >> big difference between setting and getting a property. If >> white/blacklisting is enforced

Re: [cmake-developers] CMake daemon for user tools

On Monday, January 11, 2016 15:59:35 Aleix Pol wrote: ... > > Hi Stephen, everyone, > I've already discussed this in private with you. I think it's a good > idea and I'd like to make sure we can benefit from this. > > I'm unsure of the feasibility of the project though. you maybe remember that

Re: [cmake-developers] CMake alternative language (was: Using CMake as a library from Python)

Hi all. I'd like to voice my opinion as a somewhat advanced CMake user here. For me, one of the strongest points of CMake is the fact that its project specification is procedural rather than declarative. In my current job, for example, we have a significant framework built in CMake which handles

[Cmake-commits] CMake branch, master, updated. v3.4.1-801-gcd9a59b

_VERSION_MINOR 4) -set(CMake_VERSION_PATCH 20160111) +set(CMake_VERSION_PATCH 20160112) #set(CMake_VERSION_RC 1) --- Summary of changes: Source/CMakeVersion.cmake |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) hooks/

Re: [CMake] CMake incorrectly passes linker flags to ar

On 11/01/2016 17:48, Brad King wrote: That is not representative of CMake in general. If there is a better way for FindJNI to get the information it needs then it would be great to have needed changes contributed. The Hadoop CMake infrastructure contains pretty much a complete rewrite of

[Cmake-commits] CMake branch, next, updated. v3.4.1-1907-g77b3007

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 77b30076c63f1e8f3155148a0c9815745b58d24c (commit) via

Re: [cmake-developers] FindwxWidgets.cmake

On 01/11/2016 01:18 PM, Simon Wells wrote: > The following code is line 191-201, I have tested without this being set > on OSX 10.11 using system clang and both self-built and brew installed > wxwidgets with no problems, Whether its still an issue using gcc on osx > or some other configuration i

Re: [cmake-developers] CMake alternative language

Hi Folks, I'm replying directly to my previous post in this thread in order to consolidate responses to related discussion raised in others' responses to it: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15339/focus=15383

[cmake-developers] [CMake 0015909]: FindDCMTK.cmake outdated

The following issue has been SUBMITTED. == https://public.kitware.com/Bug/view.php?id=15909 == Reported By:dkuegler Assigned To:

[cmake-developers] Visual Studio 2015 FastLink

Dear Cmake developers, as a follow up of this bug https://cmake.org/Bug/view.php?id=15894 I'm writing to request support for the /Debug:FastLink flag which was introduced in visual studio 2015 (update 1), and the option to generate full PDB informations.

Re: [CMake] CMake based package manager

On 11-Jan-16 18:42, Cristian Adam wrote: Ruslan Baratov via CMake writes: Hi, I'm developing a project that is a kind of wrapper of ExternalProject_Add and allow it to be more reusable. User interface is quite simple. For anybody interested, here is a github project: *

[Cmake-commits] CMake branch, master, updated. v3.4.1-800-gcedbb79

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 cedbb7994dddce2c3fdf846bf4563c846adf4632 (commit) via

[Cmake-commits] CMake branch, master, updated. v3.4.1-798-gd9f9c4f

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 d9f9c4fbc0a02f048793f4b91aeb5c65d9571e84 (commit) via

Re: [CMake] CMake based package manager

Doesn't biicode already fill this role? Biicode seems to work well enough for me, anyway. On Mon, Jan 11, 2016 at 5:42 AM, Cristian Adam wrote: > Ruslan Baratov via CMake writes: > >> >> Hi, >> >> I'm developing a project that is a kind of wrapper of >>

Re: [CMake] CMake based package manager

On Mon, Jan 11, 2016 at 2:33 PM, Nicholas Braden wrote: > Doesn't biicode already fill this role? Biicode seems to work well > enough for me, anyway. > > Biicode is dead. There is a comparison with biicode here: https://github.com/ruslo/hunter/issues/54 Having only

[Cmake-commits] CMake branch, next, updated. v3.4.1-1891-g816fe03

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 816fe03a024f0d2b315c9797e48a4e58a7ae0490 (commit) via

Re: [CMake] CMake based package manager

Ruslan Baratov via CMake writes: > > Hi, > > I'm developing a project that is a kind of wrapper of > ExternalProject_Add and > allow it to be more reusable. User interface is quite simple. > > For anybody interested, here is a github project: > > * https://github.com/ruslo/hunter

[Cmake-commits] CMake branch, next, updated. v3.4.1-1895-gebf86b8

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 ebf86b8bf65ec96e48f814d3f454106201df3538 (commit) via

Re: [CMake] CMake incorrectly passes linker flags to ar

On 01/11/2016 10:49 AM, Alan Burlison wrote: > So is the answer here to add -m64 just to CMAKE_EXE_LINKER_FLAGS and > CMAKE_SHARED_LINKER_FLAGS and not to CMAKE_STATIC_LINKER_FLAGS? Are > CMAKE_STATIC_LINKER_FLAGS only ever used with ar? Yes and yes. Actually adding -m64 to CMAKE_{C,CXX}_FLAGS

Re: [cmake-developers] CMake alternative language (was: Using CMake as a library from Python)

Hi, > * The cmState infrastructure builds on a "snapshot" design with a goal of being able to "fork" configuration/generation temporarily and then revert back, and to be able to re-start configuration from the middle. These goals may be incompatible with any language whose implementation

Re: [CMake] CMake incorrectly passes linker flags to ar

On 11/01/2016 16:13, Brad King wrote: On 01/11/2016 10:49 AM, Alan Burlison wrote: So is the answer here to add -m64 just to CMAKE_EXE_LINKER_FLAGS and CMAKE_SHARED_LINKER_FLAGS and not to CMAKE_STATIC_LINKER_FLAGS? Are CMAKE_STATIC_LINKER_FLAGS only ever used with ar? Yes and yes. Actually

Re: [cmake-developers] CMake daemon for user tools

On Sun, Jan 10, 2016 at 12:10 PM, Stephen Kelly wrote: > > Hello, > > I've been working on adding a daemon mode for cmake to provide > information to user tools - such as IDEs - about the buildsystem. > > Following the discussion about providing metadata for IDEs to consume >

Re: [CMake] CMake incorrectly passes linker flags to ar

On 11/01/2016 15:26, Brad King wrote: What is adding -m64 to CMAKE_STATIC_LINKER_FLAGS? That value is indeed meant to be used to pass flags to "ar" because CMake (for historical reasons) abuses the term "linker" to refer to the archiver used for a static library. That's been added by in a

[CMake] CMake incorrectly passes linker flags to ar

I've just moved from CMake 2.8.6 to 3.3.2 and creation of static libraries is now failing. I've localised the problem as far as the generated link.txt linker script. With 2.8 it begins with: /usr/bin/ar cr target/usr/local/lib/libhadoop.a with 3.3.2 it begins with: /usr/bin/ar cq

[Cmake-commits] CMake branch, next, updated. v3.4.1-1897-gf3ea5a5

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 f3ea5a599f958e20a28e10365bc07253271cde04 (commit) via

Re: [CMake] CMake incorrectly passes linker flags to ar

On 01/11/2016 09:42 AM, Alan Burlison wrote: > The "-m64" flag is used to tell the compiler/linker to create 64-bit > executables and is set via the following CMake variables: > > CMAKE_EXE_LINKER_FLAGS > CMAKE_SHARED_LINKER_FLAGS > CMAKE_STATIC_LINKER_FLAGS What is adding -m64 to

[CMake] FORTRAN name mangling

I am trying to integrate a FORTRAN library into our C++ project. I have used the following in our CMakeLists.txt file: include(CMakeAddFortranSubdirectory) cmake_add_fortran_subdirectory(src NO_EXTERNAL_INSTALL PROJECT EMSoftLib # project name in toplevel CMakeLists.txt in lapack

[Cmake-commits] CMake branch, next, updated. v3.4.1-1902-g5c88b04

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 5c88b0413cba78652e3f238302de04b10221c4a1 (commit) via

Re: [cmake-developers] VS_GLOBAL_ properties in VS 2010+ (was: patch building and testing)

On 01/08/2016 05:56 PM, Mike Fitzgerald wrote: > I've got the attached, which gives me the results I'd expect Great, thanks. I've applied this and merged to 'next' for testing: VS: Implement VS_GLOBAL_* target properties in VS 2010+ (#13666)

Re: [cmake-developers] CMake alternative language (was: Using CMake as a library from Python)

On Fri, Jan 8, 2016 at 5:30 PM, Brad King wrote: > See above. Lua has come up several times in the past in particular because > its implementation is meant to be small and embeddable. I've thought a few > times about how to make Lua scripting available from within the

Re: [CMake] FORTRAN name mangling

On 11/01/2016 17:58, Michael Jackson wrote: and we call the function from our C code like the following: SingleEBSDPattern_(ipar, fpar, ebsdPattern, quats, accum_e, mLPNH, mLPSH); You need to use the macros here too. Regards Bill Somerville. -- Powered by www.kitware.com Please keep

Re: [CMake] FORTRAN name mangling

On 11/01/2016 18:48, Michael Jackson wrote: Do other FORTRAN compilers support this “bind(C)” thing I can only vouch for gfortran but yes that is the idea. Regards Bill Somerville. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at:

[cmake-developers] Fwd: FindwxWidgets.cmake

The following code is line 191-201, I have tested without this being set on OSX 10.11 using system clang and both self-built and brew installed wxwidgets with no problems, Whether its still an issue using gcc on osx or some other configuration i am unsure, but is it worth being more specific than

Re: [CMake] CMake incorrectly passes linker flags to ar

On 01/11/2016 11:53 AM, Alan Burlison wrote: > ISTR part of the issue at least was in the bowels of the CMake FindJNI > module, that makes extensive use of CMAKE_SYSTEM_PROCESSOR. That is not representative of CMake in general. If there is a better way for FindJNI to get the information it

Re: [CMake] FORTRAN name mangling

Actually, If we just use the following: SingleEBSDPattern(ipar, fpar, ebsdPattern, quats, accum_e, mLPNH, mLPSH); and the same declaration in a .h file then we can link and execute just fine. My question now would be: Do other FORTRAN compilers support this “bind(C)” thing, such as Intel

Re: [CMake] FORTRAN name mangling

On 11/01/2016 17:58, Michael Jackson wrote: subroutine SingleEBSDPattern(ipar, fpar, EBSDpattern, quats, accum_e, mLPNH, mLPSH) bind(c, name='SingleEBSDPattern') Surely if you use bind(C) you need do no more than extern "C" the declaration when compiling C++. I thought bind(C) meant mangle

[Cmake-commits] CMake branch, next, updated. v3.4.1-1905-g8673afc

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 8673afc72a2ba9ba8d7184411b4b1247ea45d774 (commit) via

Re: [CMake] FORTRAN name mangling

"bind(c)" is a part of the Fortran 2003 standard. Any compiler that claims to support this standard should work for you. I use Intel Fortran on Linux (v13-16) with bind(c) w/o issue. FWIW - I also use the Portland Group (12+) and IBM Fortran (v14) compilers this way. -kt -Original

Re: [CMake] FORTRAN name mangling

> On Jan 11, 2016, at 11:31 AM, Zaak Beekman wrote: > > > So if I require Fortran 2003 for our fortran codes then this whole ?fortran > name-mangling? thing becomes a moot point, i.e. I do not have to actually > worry about it at all for our project. Just have to keep the

Re: [CMake] FORTRAN name mangling

Michael, You should always test your toolchain first. Compilers are often buggy or may not fully support a language feature. But yes, requiring F2003 should address your concern. -kt -Original Message- From: Michael Jackson [mailto:mike.jack...@bluequartz.net] Sent: Monday, January

Re: [CMake] FORTRAN name mangling

> So if I require Fortran 2003 for our fortran codes then this whole > ?fortran name-mangling? thing becomes a moot point, i.e. I do not have to > actually worry about it at all for our project. Just have to keep the C > header consistent with the FORTRAN functions, but that part is on our devs. >

Re: [CMake] FORTRAN name mangling

So if I require Fortran 2003 for our fortran codes then this whole “fortran name-mangling” thing becomes a moot point, i.e. I do not have to actually worry about it at all for our project. Just have to keep the C header consistent with the FORTRAN functions, but that part is on our devs. --

Re: [CMake] CMake based package manager

Hh, sorry, I should have found that myself! This definitely looks interesting, and I agree that not requiring an external program like Biicode is a good idea. Thanks for sharing this, I will try it out when I have time :) On Mon, Jan 11, 2016 at 7:40 AM, Cristian Adam

Re: [CMake] FORTRAN name mangling

On 1/11/2016 2:31 PM, Zaak Beekman wrote: Happy hacking! FYI: There is a longer version of that blog found here: http://www.netlib.org/lapack/lawnspdf/lawn270.pdf bind(c) sounds like a good idea if your compilers support it. -Bill -- Powered by www.kitware.com Please keep messages on-topic