On 08/29/2017 10:55 AM, Brad King wrote:
> On 08/29/2017 10:48 AM, Robert Dailey wrote:
>> CMAKE_PREFIX_PATH: E:/code/frontend/msvc_2015/third_party/installed
>> CMAKE_FIND_ROOT_PATH: E:/code/frontend/msvc_2015/third_party/installed
>
> I'm not sure how CMAKE_FIND_R
On 08/29/2017 11:33 AM, David Cole wrote:
> That's correct:
>
> find modules do what they want, and most do not pay attention to
> CMAKE_PREFIX_PATH.
CMAKE_PREFIX_PATH *is* used by find modules.
The find modules use find_* commands, and those use CMAKE_PREFIX_PATH.
See the documentation of find_
On 08/29/2017 11:50 AM, Robert Dailey wrote:
> Wow even if I set ZLIB_ROOT, FindZLIB.cmake *still* won't find my zlib
> over the one provided by the Android NDK...
>
> Although I was able to get this working fine on Windows, it does not
> work with the NDK's toolchain file.
That's because the CMA
On 08/29/2017 12:21 PM, Robert Dailey wrote:
> 3. Second find_package() happens, but "AlreadyInCache" is true (line
> 28 in cmFindPathCommand.cxx) this time, so it doesn't search for it
> again.
>
> Hard to tell where the bug is here. I'd argue that AlreadyInCache
> shouldn't be set to true since
On 09/02/2017 03:14 AM, Gerhard Gappmeier wrote:
> This is quite annoying, inconsistent with Makefiles and was already
> reported once here: https://cmake.org/Bug/print_bug_page.php?bug_id=13894
> AFAIK this was never fixed.
Discussion of that issue is now here:
https://gitlab.kitware.com/cmake
On 09/05/2017 07:42 AM, Gerhard Gappmeier wrote:
> Could you already verify if this problem is also the cause for the
> coverage issue?
I tried your example in a fully out-of-source build (where the
build tree is not inside the source tree), and coverage works.
-Brad
--
Powered by www.kitware.c
On 08/24/2017 04:13 AM, Arne Kjetil Andersen wrote:
> result in -lgcc_eh being added...
The cause has been identified and reported here:
https://gitlab.kitware.com/cmake/cmake/issues/17436
-Brad
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://w
On 12/05/2017 12:05 PM, ramya.gopalkris...@accoliteindia.com wrote:
> Please validate our current understanding when a toolchain file or
> command-line option sets CMAKE_SYSTEM_NAME to "Android"
You may find this note helpful:
https://gitlab.kitware.com/cmake/cmake/issues/16708#note_300971
> I
On 12/06/2017 11:39 AM, ramya.gopalkris...@accoliteindia.com wrote:
> Can you please give us some guidance to achieve the same with
> CMAKE_SYSTEM_NAME as "Android"
You'd need to teach
Modules/Compiler/Embarcadero-DetermineCompiler.cmake
to recognize the compiler as Embarcadero if it doesn't a
On 12/11/2017 04:34 PM, John Cary wrote:
> Bill Hoffman wrote:
>> LINK: command "xilink ... /out:FortranCInterface.exe ..." failed (exit code
>> 1169)
>> LIBCMT.lib(winapisupp.obj) : error LNK2005:
>> __crtSetUnhandledExceptionFilter already defined in MSVCRT.lib(MSVCR120.dll)
>>
>> Did you change
On 2/9/2018 2:36 AM, Arjen Markus wrote:
> From: Alan W. Irwin
>> I suggest you try the names CYGWIN-NAG-Fortran.cmake and
>> Windows-NAG-Fortran.cmake for the two separate Platform
>> files you are trying to create for the Cygwin and
>> MinGW-w64/MSYS2 platforms.
I think those names are correct.
On 2/13/2018 2:50 PM, Alan W. Irwin wrote:
> While waiting for Arjen to respond from his European time zone to that
> question, which cmake package for MinGW-w64/MSYS2 do you usually
> recommend? The cmake package from the mingw64 repository or the cmake
> package from the msys2 repository?
I'm n
On 2/14/2018 3:16 AM, Arjen Markus wrote:
> The MinGW version of Cmake reports Windows for both variables
Great, that's expected. Then Windows-NAG-Fortran would be the proper
module for flags for a compiler targeting a Windows environment.
> and the MSYS2 version reports MSYS.
If CMAKE_SYSTEM_N
On 02/27/2018 11:30 AM, Jakob Reschke wrote:
> I followed this up to the file(STRING ...) command ... seems
> unable to grep any strings out of any file:
Strange. That will need to be solved before anything can be
expected to work. Where did you get the CMake binary?
FYI we've had nightly testi
On 02/28/2018 12:59 PM, Jakob Reschke wrote:
> Yes, I have seen the builds mentioned somewhere, which gives me hope
> that it could be fixed on our machines.
You could also try bootstrapping CMake from source. Doing so with
GNU on AIX is supported.
-Brad
--
Powered by www.kitware.com
Please k
On 03/09/2018 07:58 PM, Ondřej Čertík wrote:
> How do I make CMake pass the "Check for working Fortran compiler" phase?
The problem reported in issue 17810 is caused by trying to
enable C with MSVC and Fortran with GNU together at the same
time, e.g. `project(MyProj C Fortran)`. These tools canno
On 03/12/2018 12:13 AM, Eric Wing wrote:
> There are 10 small commits I made in a separate branch for my original
> change, which can be seen at the top of the page at GitHub:
> https://github.com/ewmailing/CMake/commits/SwiftMakefile
As of commit 6c296b3e208dbb4319f396fdfb751206cff1abe0 on that b
On 03/12/2018 10:36 AM, Cameron Palmer wrote:
> So after a bit of hacking it seems that Cmake should provide something like:
>
> CMAKE_OSX_BITCODE_ENABLE
For reference, this refers to a previous post:
Bitcode and CMake
https://cmake.org/pipermail/cmake/2018-March/067191.html
with the go
On 03/22/2018 10:17 AM, Mateusz Loskot wrote:
> It seems folks generally agree there is need for porcelain API.
> It's a pity it's been 5+ years and it is still waiting for implementation.
For reference, there were several discussions. Some of them were here:
* "Setting include directories via t
On 03/26/2018 04:24 AM, Cameron Palmer wrote:
> However, setting the property BUILD_WITH_INSTALL_RPATH on or off doesn't
> change anything as far as I can tell. The target is still linked with
> -headerpad_max_install_names and the linker still complains.
Oops, I mixed up functionality with other
On 03/20/2018 08:52 PM, Rick Mann wrote:
> Xcode (Version 9.2 (9C40b))
That works with CMake 3.11.0-rc4 AFAIK.
> CMake Error at cmake/AddCeresCXX11RequirementsToTarget.cmake:70
> (target_compile_features):
> target_compile_features no known features for CXX compiler
>
> "Clang"
>
> versi
On 04/11/2018 09:24 AM, Ales Borovicka wrote:
> We have a custom platform that does require to set properties in vcxproj like:
> $(PLATFORM_SDK_ROOT)
>
> For regular projects we set this through user files, so it works for the
> generated projects. (it worked with cmake 3.7.0)
We don't currently
On 04/11/2018 01:44 PM, Zaak Beekman wrote:
> I thought that CMake had Fortran submodule support as of 3.8 or 3.10.
CMake 3.7 added support to the Fortran dependency scanner to tolerate
the *syntax* of submodules. Only the main modules are handled for
dependencies though.
Unfortunately we still
On 04/12/2018 08:22 AM, Ephi Sinowitz (BLOOMBERG/ 919 3RD A) wrote:
> CMake expects the PREPROCESSED_SOURCE output to be in the form
> -pp.f and XL does not allow you to control that. The output> is
> always of the form F.f
>
> Is there anything I can do here like putting redirection or two
> com
On 02/08/2017 04:05 PM, Ephi Sinowitz (BLOOMBERG/ 731 LEX) wrote:
> cmake creates these files for gcc compiler using the -MMD -MMF
> compiler flags but does not do so for AIX xlc and Sun CC
> Is this a known issue? Is there a workaround?
This simply means no one has added support for these compile
On 04/10/2018 01:50 PM, Ephi Sinowitz (BLOOMBERG/ 919 3RD A) wrote:
> I would like to ensure that all include directories propagated from
> IMPORTED targets come after the include directories propagated from
> non-imported targets. On gcc the includes from IMPORTED targets are
> marked with -isyste
On 05/22/2018 06:27 AM, Johannes Zarl-Zierl wrote:
> There's more that we (as CMake community) could do to make it easier for non-
> cmake projects to add a config file...
[snip]
> not be much more work for the maintainer as pkg-config files.
There is a proposal here:
https://mwoehlke.github.io
On 05/22/2018 11:21 AM, Sergei Nikulov wrote:
>>https://mwoehlke.github.io/cps/
>
> When will CMake with cps support be available?
The work is still in the design phase of the CPS format itself.
I've added its author in Cc.
-Brad
--
Powered by www.kitware.com
Please keep messages on-topic
On 05/22/2018 10:06 PM, Paul Fultz II wrote:
> Or pkg-config could be extended to fix the issues.
The `.pc` file format is too flat to lend itself well to representing
all the information we need. A goal of `.cps` files is to teach
pkg-config to parse them and respond to its standard queries with
On 05/24/2018 07:39 PM, Paul Fultz II wrote:
>> On May 24, 2018, at 8:07 AM, Brad King wrote:
>> The `.pc` file format is too flat to lend itself well to representing
>> all the information we need.
>
> What do you mean? What information can't be represented?
Try
On 05/25/2018 07:52 PM, Paul Fultz II wrote:
> What else is missing?
The `.pc` format focuses on flat command-line strings that drop much
of the information used to generate them. For example, if library
A depends on library B then the `.pc` file will record the link flags
-L/path/to/A/lib -
On 05/31/2018 01:41 PM, paul wrote:
> This is because cmake lacks native support for pkg-config. It only uses the
> pkg-config CLI, which works fine for makefiles.
>
> Instead cmake needs to make a target for each `.pc` found. This could be
> possible if it used libpkgconf instead.
That sounds li
On 06/13/2018 04:22 AM, Gerhard Olsson wrote:
> The build works on my PC, but not on the Jenkins server running Windows
> Server 2012R2: cmake.exe: error while loading shared libraries: ?: cannot
> open shared object file: No such file or directory
>
> Any steps required to get a binary that runs o
On 06/14/2018 04:43 PM, Steve wrote:
> When I run '/cmake -G "MinGW Makefiles" -DCMAKE_BUILD_TYPE=Release ..'
> Windows Defender triggers and reports: Trojan:Win32/Fuerboos.C!cl on file:
> D:\DDS-master\AMM_Modules\build\CMakeFiles\3.11.3\CompilerIdC\a.exe
Strange. That `a.exe` is an executable c
On 06/25/2018 03:09 PM, Juan E. Sanchez wrote:
> ADD_LIBRARY(symdiff_objects OBJECT ${CXX_SRCS} ${MC_SRCS})
> set_property(TARGET symdiff_objects PROPERTY POSITION_INDEPENDENT_CODE ON)
> TARGET_LINK_LIBRARIES (symdiff_tcl $
> ${TCL_ARCHIVE})
>
> How do I tell cmake to wait?
Strange, our test sui
On 06/20/2018 10:42 AM, Gebhard, Joseph wrote:
> traced it down to dos line ending in the objects1.rsp file. It was looking
> for a ctrl+M character on the end of the file name.
> After a little playing around with this we determined that 3.7.2 works fine,
> but 3.9, 3.10 and 3.11.3 all have this
On 06/26/2018 01:32 PM, Juan E. Sanchez wrote:
> The likely problem is that the symdiff_objects and the symdiff_tcl are
> in side-by-side directories. They are both added using ADD_SUBDIRECTORY
> one level up. If I put symdiff_python before symdiff_tcl, then that
> target will fail. Please fi
On 07/02/2018 08:43 AM, Robert Maynard wrote:
> On Sun, Jul 1, 2018 at 6:18 PM Miklos Espak wrote:
>> the 'ccmake' command seems to be missing from the linux tarballs
>> from 3.12.0 RC1 and RC2. Not sure if you are aware of that.
>
> Thanks for reporting this. I am looking into it.
Thanks for the
On 07/20/2018 11:48 AM, Buster, James wrote:
> Using cmake 3.12: the second “cmake .” issues the following warning:
> CMake Warning (dev) in CMakeLists.txt:
> Policy CMP0048 is not set: project() command manages VERSION variables.
Thanks. I opened an issue for it:
https://gitlab.kitware.com/
On 07/24/2018 10:28 AM, Brad King wrote:
> If no project() command appears anywhere in the top-level CMakeLists.txt
> file then one is injected on line zero.
FWIW, see this note in the project command docs:
https://cmake.org/cmake/help/v3.12/command/project.html
"The top-level CMa
On 08/07/2018 06:54 AM, Daniel Eiband wrote:
> set_property(TARGET MyTarget APPEND PROPERTY LINK_FLAGS "/ignore:4221")
>
> This however doesn't affect the creation of static libraries.
Static libraries are created by the librarian tool, not the linker.
There is a separate STATIC_LIBRARY_FLAGS pro
Ashwin Chandra wrote:
Notice the pdb file changed in case. I think what is happening is that
the compiler is generating the pdb file in all lower case on the first
build run and when doing a second build run, it somehow knows the file
is in lowercase now and it updates the build.make files (whi
Frank Mertens wrote:
> I started using cmake (2.6.3) under OpenBSD (4.5) and found it unwillingly to
> link my software correctly.
> The issue had been described some time ago:
> http://www.cmake.org/pipermail/cmake/2006-November/011851.html.
> I figured out that cmake-2.6.3/Modules/Platform/NetB
Brad King wrote:
> Frank Mertens wrote:
>> The solution was simple: cp NetBSD.cmake OpenBSD.cmake.
>> I think those two files can be kept safely identical.
>
> Currently OpenBSD.cmake has this line:
>
> SET_PROPERTY(GLOBAL PROPERTY FIND_LIBRARY_USE_OPENBSD_VERS
John R. Cary wrote:
> I am trying to build cmake on a Blue Gene P.
> Configuration starts with
>
>
> login1.surveyor$ ./bootstrap
> -
> CMake 2.6-4, Copyright (c) 2007 Kitware, Inc., Insight Consortium
[snip]
> http://www.cmake.org/pipermail/cmake/2006-
Bill Hoffman wrote:
> So, it must be that the library is built with no soname. Brad will be
> back in a few days, and should have a better idea of how to fix it.
This is probably the problem. You can confirm this by running
readelf -d /home/kchang/sandbox/thost/thostmduserapi.so |grep SONAME
John R. Cary wrote:
> env CC=xlc_r CXX=xlC_r
[snip]
> -- The C compiler identification is GNU
Be sure to create a fresh build tree when changing compilers.
CMake cached the 'cc' (gnu) compiler it found the first time
and did not pay attention to the environment later.
> /gpfs/software/linux-sles1
Arjen Markus wrote:
> I do not think this is going to work: object files created with g77
> and gfortran are not compatible as far as I know.
>
> What constructs are they? F90/95 has one or two deleted features
> but most compilers will simply accept them, perhaps grudgingly.
[snip]
>> How can thi
Will Dicharry wrote:
> Sorry for the month of delay, but I've addressed Mike Jackson's concerns
> below and I think I'm close to having the HDF5 find module ready for
> submission.
Excellent. I have a few comments from quickly glancing at them, but
I don't have time for thorough testing. Overall
Will Dicharry wrote:
> What is the convention for keeping a macro out of the public interface?
Leave it out of the documentation and name it with a '_hdf5_' prefix
(starting in '_').
-Brad
___
Powered by www.kitware.com
Visit other Kitware open-source
Will Dicharry wrote:
John R. Cary wrote:
I am a real newbie here (exploring cmake) so my words should be taken
with a grain of salt. But we find (in our current autotools
setup), that it is good to have a flag that tells one whether the hdf5
was
compiled with --enable-parallel.
I agree that
John R. Cary wrote:
> Brad King wrote:
>> John, how do autotools detect this?
>
> hdf5par=`grep "HAVE_PARALLEL 1" $HDF5_INCDIR/H5config.h`
>
> I suppose there are other ways, but we have been doing this through
> several versions of hdf5.
Great, thanks John.
W
Dominik Szczerba wrote:
> I want to compile one file with fortran compiler (intel) and link with
> the rest of my project. Will the latest cmake allow to fully cmakify
> such scenario?
FYI, CMake HEAD from CVS has a whole bunch of new features for mixed
Fortran/C++ support. The main feature is th
Michael Wild wrote:
>
> On 24. Aug, 2009, at 14:30, Brad King wrote:
>> FYI, CMake HEAD from CVS has a whole bunch of new features for mixed
>> Fortran/C++ support. The main feature is that CMake now automatically
>> detects the implicit language runtime libraries used b
Will Dicharry wrote:
> All,
>
> I've committed the FindHDF5 and SelectLibraryConfigurations modules to
> the CMake CVS repository.
>
> Thanks for your input and feel free to contact me with questions
> regarding the modules.
Great. Thanks for your contribution!
venugopal gudimetla wrote:
> I am using CMake 2.6.4 on Linux 64 bit platform. We are using absoft f95
> compiler. I am trying to build cgns3.0 which uses CMake for building the
> package.
FYI, to my knowledge no one has ever used CMake with that compiler.
We need to teach CMake about the compiler'
venugopal gudimetla wrote:
> Thank you very much for your quick response.
BTW, Fortran support is greatly improved in CMake's development version.
If you can try the latest version from CVS HEAD, please do so.
> Yeah I noticed too that for
> some reason Cmakes is assuming f95 to be a GNU compiler
Mathieu Malaterre wrote:
> [ 4%] Built target cmsys
> Linking C shared module libcmsysTestDynload.so
> /usr/lib/gcc/powerpc64-suse-linux/4.1.2/../../../../lib/crt1.o:(.rodata+0x4):
> undefined reference to `main'
What does "make VERBOSE=1" say? Clearly this linker
line is missing the flag to mak
John R. Cary wrote:
> BTW - should a 'CXX.cmake' file include *_C_FLAGS?
In principle no, but it works around some historical cruft
that hasn't been cleaned up yet.
> Curious about how these work. I assume that cmake does
> a mapping from the OS and compiler to a Platform file, but
> then there
venugopal gudimetla wrote:
>
>
> Hi Brad,
>
>>This brings us back to
>> my question: does the compiler identify itself with any documented
>> preprocessor symbol?
>
> I checked Absoft documentation and also asked Absoft support guys, there
> doesn't seem to be a pre-processor macro which identi
Alan W. Irwin wrote:
> The fact remains some projects would like to drop the
> interpretation altogether (for the reasons I
> mentioned) and other projects will want to preserve it (for the reasons you
> mentioned).
The path-to-existing-build interpretation is not the cause of the problems
with t
Eric Noulard wrote:
> Fair enough,
> my tortuous mind was tracking the build tree yours
> is tracking the source tree, this is obviously a
> better choice.
>
> My E3) case still remains, you really don't want to mess-up
> an existing build tree with a unrelated source tree.
>
> I know however th
Roman Shtylman wrote:
> Well...I didn't foresee such a discussion on the topic but have actually
> heard some interesting new things brought up...so I guess I can chime in too.
>
> 1. Being able to call cmake with
>$> cmake
> Although it is better than what we have now, I like the ex
Robert Dailey wrote:
Hello,
I'm using the latest (as of now) CMake build from CVS head. I noticed
that when I specify a source file like so:
/Users/imac/work/redsword/projects/foobar/mysource.mm
XCode actually thinks it is here:
/Users/imac/work/redsword/projects/foobar/projects/foobar/myso
Robert Dailey wrote:
The goal here is to try to build Xcode projects for building iPhone
apps. My CMake logic for producing projects is rather complex, which is
why I am hesitant to post it here. But basically I'm taking the exact
path above and passing it into add_executable like so:
add_exe
Brad King wrote:
Robert Dailey wrote:
The goal here is to try to build Xcode projects for building iPhone
apps. My CMake logic for producing projects is rather complex, which
is why I am hesitant to post it here. But basically I'm taking the
exact path above and passing it into add_execu
Robert Dailey wrote:
Where is the CMakeLists.txt file containing this line?
Perhaps "/Users/imac/work/redsword/CMakeLists.txt"?
That's where the root one is, and this root script has all of the meat
that the subdirectories call. This script is the one that has the
functions that call
David Cole wrote:
Sounds like maybe you are using "${CMAKE_CURRENT_SOURCE_DIR}" in a
function or macro. (defined at the top level, but called from a
lower level)...
That works just fine...evaluation of the variable is the location
of the current CMakeLists.txt file, not the file containing
Robert Dailey wrote:
My paths are correct. I'm passing in the correct absolute paths into
add_executable. I think that cmake is using the current cmake file
instead of using the one that the function call originated from. For
example, I have two CMake scripts:
/Users/imac/work/redsword/CMakeL
Robert Dailey wrote:
> I've attached a test project that reproduces this issue. At the root
> "test" directory, create a new directory called 'build'. So you will
> have "test/build".
>
> cd into test/build and run:
>
> cmake -G "Xcode" ..
>
> This will generate an xcode project for you. Open
Robert Dailey wrote:
> Great! Glad I could help. Let me know when this is fixed so I can
> download a new nightly build. I'll try to keep up with that bug status
> as well.
If you get an account in the bug tracker you can go to the issue and
choose "monitor issue". Then you will get updates auto
Baron Roberts wrote:
> Folks, I am generating Xcode 3.1 a project using cmake 2.6.2. I have noticed
> that I am not able to connect the generated project to my Perforce SCM
> system such that the files in the project are recognized as being in the
> repository. While Xcode is able to access the rep
Hi Martin,
Thanks for trying the release candidate. It is helpful to get feedback
early in the release process.
Martin Apel wrote:
> However I found a few quirks in the first rc:
> 1. I have quite a lot of Fortran files in one of our projects. We use
> the Intel Fortran 11 compiler to compile th
Andreas Pakulat wrote:
> On 25.09.09 16:07:21, Bill Hoffman wrote:
>> I am happy to announce that CMake 2.8.0 has entered the beta stage! You
>> can find the source and binaries here: http://www.cmake.org/files/v2.8/.
>>
>> I am sure I am leaving something out, but here is the list of changes
>> th
Mathieu Malaterre wrote:
> On Fri, Sep 25, 2009 at 10:07 PM, Bill Hoffman
> wrote:
>> I am happy to announce that CMake 2.8.0 has entered the beta stage! You
>> can find the source and binaries here: http://www.cmake.org/files/v2.8/.
>>
>
> There is still one compilation issue with xlC on Linux:
Mathieu Malaterre wrote:
>> /opt/ibmcmp/vacpp/9.0/bin/cc -DHAVE_GETHOSTBYNAME_R_5 -o
>> CMakeFiles/cmTryCompileExec.dir/CurlTests.c.o -c
>> "/home/mmalater/Dashboards/My
>> Tests/CMakeXLC/Utilities/cmcurl/CMake/CurlTests.c"
> "/home/mmalater/Dashboards/My
> Tests/CMakeXLC/Utilities/cmcurl/
Mathieu Malaterre wrote:
> The 32bits xlC is now perfectly clean, congrats !
Great!
> A couple of warnings that's all:
> http://www.cdash.org/CDash/viewBuildError.php?type=1&buildid=439244
Warnings in system headers are always a pain. Can you please
investigate options to turn them off?
> Howe
Mathieu Malaterre wrote:
Are they linking to the right
one in the first place?
I do not understand the question... :(
My bad. For some reason I was thinking it was linking but failing
to locate the library it linked at runtime. In fact it is just
picking the wrong library and cannot link to
Mathieu Malaterre wrote:
> But since no other tests fails I would think discovery of 64bits libs
> is working (I am guessing at least a test would fails). This looks
> like just an issue in the findqt module.
>
> However I do not understand what I need to do to fix
> Modules/FindQt3.cmake, simply
Sean McBride wrote:
> Hi all,
>
> I've just tried building VTK with 2.8rc1 and it gives an error:
>
> -- Check size of long
> CMake Error at /Applications/CMake 2.8-0.app/Contents/share/cmake-2.8/
> Modules/CheckTypeSize.cmake:102 (MESSAGE):
> CHECK_TYPE_SIZE found different results, consider s
Jason Slemons wrote:
> actually he only gets the second error. I am using cmake/2.8.0-rc2. I’ve
> attached the CMakeError.log. How can I get Cmake to suppress these two
> flags? Strange enough this works under cmake 2.6.4(meaning these two
> flags are not used).
The key error message is this:
"
Hi Jason,
I'm keeping this dicussion on-list so it goes in the archives.
> I see two flag errors in the CMakeError.log file, one is for fpp and
> the other is(buried, just near the end) for rdynamic. I also can add
> this about my fortran compiler; it's called ftn and its actually a
> wrapper sc
Jason Slemons wrote:
> Hello Brad,
>
>> Is this a cross-compiling environment?
>
> Yes it is, both are linux systems though. I'm mainly curious to see if it
> will build for now though. Ill deal with testing the build later. Oh and I
> noticed in CMakeSystem.cmake that it says:
> SET(CMAKE_CR
Jason Slemons wrote:
> Here are the a.out files.
The compiler is including 0x14 characters at the end of string literals.
This was preventing the strings extraction in the file(STRINGS) command
that CMake uses to parse the binaries. I've committed a fix, and now
CMake can extract the id strings o
Sebas wrote:
> I use Intel Fortran y Microsoft C/C++ compilers.
Currently this is not a supported compiler combination.
Support for mixed C/C++/Fortran is new in CMake 2.8.
We've done very little work on mixed-vendor cases.
Please submit a feature request here:
http://www.cmake.org/Bug
-Brad
Mathieu Malaterre wrote:
Hi there,
I am trying some new functionalities in CMake, in particular:
http://www.cmake.org/Wiki/CMake_2.6_Notes#Packaging_and_Exporting
However using cmake 2.8, I get an error:
CMake Error at cmake_install.cmake:64 (FILE):
file INSTALL cannot find
"/home/mat
Steven Wilson wrote:
Consider the following simple C++ file foo.cpp:
#include
int main()
{
std::cout << "bar" << std::endl;
return 0;
}
Now consider the following CMakeLists.txt file for foo.cpp:
cmake_minimum_required(VERSION 2.6)
project(Bug)
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY
Andrew Maclean wrote:
> I guess the subject says it all. What is the status of using CMake,
> Ctest and CDash with git?
CMake 2.8 comes with a CTest that can drive dashboards using git-based
work trees (plus hg and bzr). The ctest_update() command runs "git pull"
to update the work tree, and repo
Alan W. Irwin wrote:
> The following CMake logic fragment illustrates the issue:
>
> add_executable(plhershey-unicode-gen ${plhershey-unicode-gen_SRCS})
>
> add_custom_command(
> OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/plhershey-unicode.h
> COMMAND plhershey-unicode-gen
> ${CMAKE_SOURCE_DIR}/fon
Alan W. Irwin wrote:
> cmake version 2.6-patch 4;
>
> Unix Makefiles;
>
> Linux (Debian stable with bootstrap build of CMake-2.6.4);
>
> What's the easiest way to try the "generator" test here (for Unix
> Makefiles)
> so we are doing exactly the same test?
Get a CMake 2.6 source tree. Then run
James Bigler wrote:
> I noticed in some commit message to CMake a while ago that -fPIC was
> removed from executable compilation.
>
> Would anyone care to comment on why this is? I must admit I thought it
> wouldn't hurt it to have it compiled with that flag.
It's unnecessary, and is actually a
Orion Poplawski wrote:
> Trying to configure CGAL 3.5 with cmake 2.8.0 rc4 on Fedora and cmake is
> segfaulting. Quick analysis shows that it's faulting here:
>
> #1 cmMakefile::RaiseScope (this=)
> at /usr/src/debug/cmake-2.8.0-rc4/Source/cmMakefile.cxx:3392
> 3392 this->LocalG
Bill Hoffman wrote:
Kelly (KT) Thompson wrote:
Hi,
I am trying to use Intel ifort on Linux to compile source code that
uses the extension .F95. By default, ifort will not compile files
with this extension. To allow the compilation, the name of the source
file must be preceded by -Tf (treat
Steven Wilson wrote:
CMake is ignoring the LINK_FLAGS_ settings for
set_target_properties() when using the Xcode generator in the 2.8 branch
and the head branch.
It looks like the implementation is just plain missing from that
generator. Please submit a bug report here:
http://www.cmake.or
Mathieu Malaterre wrote:
> Just wanted to say : great job on the find_package interface !
Thanks!
> This is extremely convenient to use for package using cmake as build package.
> All I had to do is configure a *Config.cmake and a
> *ConfigVersion.cmake file. And then from the outside I can simpl
James C. Sutherland wrote:
However, I just discovered that this is a deprecated feature, and that
install(EXPORT...)
should be used instead.
Good, it is much more modern and more powerful.
However, it is not clear to me how to incorporate dependencies when
using the install(EXPORT) approa
James C. Sutherland wrote:
The library I am building pulls in several other libraries (MPI, BLAS,
Boost, etc). I would like any down-stream apps that use my library to
automatically be able to include any appropriate header files and link
to appropriate third-party libraries that were included
Kevin Burge wrote:
> I have many built targets. When I do "nmake install"
FYI, you can skip the up-to-date check before install by using
nmake install\fast
> it takes a long
> time between each "Built target..." check (extremely long, compared to
> using make on a Unix box). Is there any way
Will Dicharry wrote:
> Hi All,
>
> This was asked a while ago at
> http://www.cmake.org/pipermail/cmake/2009-January/026318.html, but it
> doesn't look like there was a response to that question.
>
> I have the same problem:
>
> on 64 bit AIX, ar must be invoked with a "-X 64" flag. Is there a
James C. Sutherland wrote:
> Thanks. To be clear, it only works if I use
>
> set( ExprLib_LIBRARIES @TPL_LIBRARIES@ )
>
> because otherwise I have no way of propagating the dependents of
> ExprLib downstream. It is true that CMake will add the ExprLib
> library as a "target" that can be u
201 - 300 of 1635 matches
Mail list logo
