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 o
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 are
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 during setting only, wo
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 the
> 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 C header
> consiste
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 a
> 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.
>
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 wrote:
> On Mon, Jan 11, 201
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
"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 Messag
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.
--
Mic
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:
http://www.cmake.org/Wi
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 For
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 messag
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 the
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
LIBRARIES
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 needs
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
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
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 CMa
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_STATIC_L
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 target/usr/l
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:
* https://github.com/ru
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 as a dependency is awes
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
>> ExternalProject_Add and
>> allow it to be
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
Recently p
26 matches
Mail list logo
