Re: [CMake] CMake 2.7.8 cannot find boost installation While building PCL files.
Hi Andreas. This totally fixed my problem. Cmake was using the wrong version of Mingw and the boost version document was also wrong. So it was looking for the wrong files in both version and compiler.Aka:libboost_thread-mgw44-mt-1_47.dll Instead of:libboost_thread-mgw46-mt-1_49.dll SET (Boost_COMPILER "-mgw46") and changing the version document to the correct version fixed it. Thanks alot! Joeri. Date: Thu, 12 Apr 2012 11:43:55 +0200 From: andreas-naum...@gmx.net To: cmake@cmake.org Subject: Re: [CMake] CMake 2.7.8 cannot find boost installation While building PCL files. Hi, you could set Boost_DEBUG and Boost_DETAILED_FAILURE_MSG to true and have a look at the messages. I hope, this helps you. Andreas Am 12.04.2012 11:06, schrieb Joeri Friederich: Hi Im trying to build PCL (Point cloud library) files using Cmake. It needs a bunch if dependencies one of which is boost. It finds all other dependencies without a hitch but it gives this error for boost: The following Boost libraries could not be found: boost_system boost_filesystem boost_thread boost_date_time boost_iostreams I have been trying to fix this for 2 days now. What I did: I build my own libraries with boost.build using the following commands: >b2 >toolset=gcc >--build-dir=C:\boost >--build-type=complete This build the library successfully. Adding the files (libboost_thread-mgw46-mt-1_49.dll) etc to the lib folder in my boost installation doesn't allow cmake to find them though. It does however find the include directory without a hitch. Even manually linking Cmake to the (correct) libraries doesn't allow it to find them. How do I get cmake to find these lib's? Also: boost_thread doesnt exist on my computer but "libboost_thread-mgw46-mt-1_49.dll" and 20 different versions of it with different letters at mt do. is there a way that I can see what file Cmake is looking for exactly? Version etc: Cmake:2.8.7 Cmake generator: Mingw makefiles Compiler: GCC. Boost v:1.49.0 Windows 7 Thanks for any help, Joeri. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Adding support for Absoft Fortran compilers in CMake
Dredging this up from last year because it has become relevant again (for me). Has this effort gone anywhere? I don't use Absoft myself by my colleagues do and they want to add some Fortran code to one of my existing CMake based projects. Thanks for any info. -- Mike Jackson On Jan 19, 2011, at 11:19 AM, Brad King wrote: > On 01/19/2011 10:32 AM, Tony Goelz wrote: >> My apologies in advance if this is not the correct place to start my >> inquiry. > > This is a good place to start. This was discussed briefly: > > http://www.cmake.org/pipermail/cmake/2009-August/031688.html > > but left off here: > > http://www.cmake.org/pipermail/cmake/2009-September/031728.html > > Bill Hoffman and I are two of the core CMake developers at Kitware and are > interested. > >> I am looking for information on getting support for Absoft's Fortran >> compilers >> on Linux, Windows and OS X added to a future release of CMake. Ideally, the >> Absoft compilers would be supported in the same manner that other vendor's >> Fortran compilers. > > This is certainly possible, especially with your help. > >> Can someone provide me with the appropriate channel to get this process >> started? >> Absoft is willing to a provide no cost copy of the compilers as well as >> making >> modifications to our compiler drivers if required. > > That will help tremendously. Bill and I will get in touch with you off-list. > > Thanks for your interest! > -Brad > ___ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Follow this link to subscribe/unsubscribe: > http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Trying to use the latest release of Intel Fortran 2011 (update 9) with cmake...
Did you try wiping out the existing build and starting it from scratch? It sounds like there are still some module files floating around from the previous build with the previous Fortran version. Tim - Original Message - From: "Dick Munroe" To: cmake@cmake.org Sent: Thursday, April 12, 2012 2:48:00 PM Subject: [CMake] Trying to use the latest release of Intel Fortran 2011 (update 9) with cmake... on windoze. I installed the compiler, uninstalled the previous update (2), and fired up CMake at which point I can no longer build solutions with CMake. Every time I try, I get a "this solution was built with an earlier version of fortran" or words to that effect. Any clues what the problem might be? Best, Dick Munroe -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Trying to use the latest release of Intel Fortran 2011 (update 9) with cmake...
on windoze. I installed the compiler, uninstalled the previous update (2), and fired up CMake at which point I can no longer build solutions with CMake. Every time I try, I get a "this solution was built with an earlier version of fortran" or words to that effect. Any clues what the problem might be? Best, Dick Munroe -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] CMake 2.8.8-RC2 with Mac OS X 10.7.3 Xcode 4.3.2
I've been porting a disk diagnostic tool we develop and use internally to the
Mac platform specified in the Subject. I have it to the point where using CMake
2.8.7 it would create the plethora of sub-project builds, build and link all of
the dylibs that are used by Wish to run the diagnostics on the drives that we
manufacture. Recently however, I realized I needed a better IDE than "vim", so
I tried to run CMake to use Xcode 4.3.2. The first thing that happened was a
CMake error which should be solved in CMake 2.8.8 RC1. It was, and CMake
created the plethora of projects as well as the single xcodeproj file that ties
them all together.
The project loads in Xcode, and does the builds, with quite a few warnings. The
warnings are nothing new, and like many shops we tend to ignore them … not my
choice since I'm a bit anal about fixing warnings, but I have to live with
these. However, I am not generating any dylibs, and when I go to a terminal and
run "xcodebuild -project MyP.xcodeproj" I find that the build is actually
failing with an error -- a Boost header file is not found.
The path for the Boost headers are defined in the first CMakeLists.txt for non
Windows platforms as: include_directories("/usr/include"). An additional
include_directores adds the remaining paths and those are defined.
I've listed the files in that path and show boost defined under include
followed by all the header files that Xcode cannot find. My next thought was to
go look at HEADER_SEARCH_PATHS, and sure enough "/usr/include" is not listed in
that search path. I tried setting include_directores the CMakeLists.txt file
governs the actual project that is being built but that does not work either.
So, how do I set the search paths to find the Boost header files?
Also … How do I change build types in 2.8.8 RC2? The -DCMAKE_BUILD_TYPE=Release
that I used to use is no longer accepted. it fails with a label not used
message.
Do I need to file a bug report, or am I doing or not doing something?
Gary Little
H (952) 223-1349
C (952) 454-4629
gglit...@comcast.net
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Cross-compilation on Linux targeting Windows
On Thu, Apr 12, 2012 at 8:47 AM, hendrik wrote: > Linux can automatically call wine for windows executables if you make them > executable (+x). > In Debian, it is enabled using this package: > http://packages.debian.org/sid/binfmt-support Interesting - I'll have to see if Gentoo offers something similar. > OTOH, your tests may not show the desired result as you test the program > behaviour in wine, not Windows. True... but perhaps, with luck, wine + the mingw packages + a good toolchain file would be "close enough" to get a compile that would work on Windows. A lot of what we need to do when we run programs is generate source code, run tcl shell, and other things that (in principle) shouldn't need to care what OS they are on. The only other fully "open source" option I can think of would be to try using ReactOS - has anyone ever successfully built binaries on ReactOS and then deployed them on Windows? Cheers, CY -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Superbuild and Incredibuild
Hi, We (MITK) have a CMake build system using a "superbuild" process by calling ExternalProject_Add() which works great. Recently, we started evaluating Incredibuild to reduce compile times for Windows developers (using VS 2008) but run into troubles with our superbuild. The projects which are configured at superbuild build time are not distributed across multiple machines. Has anybody else tried something similar already? Here are some more details: The Incredibuild support team made the following sugestions, of which only number one seemed feasible for us: In your build environment, cmake is executing DevEnv, so when built remotely, it tries to execute DevEnv on a remote. This is something that we do not support at the moment. Here are several alternative options: 1. Call MSBuild instead of Devenv. 2. Run a CMake script to compile the projects (inside CMake) instead of executing a full DevEnv command. 3. Run the entire solution using CMake and instead of VisualStudio and use the XGE Interception interface in order to accelerate it. 4. Separate CMake custom steps and Visual Studio builds into two seperate builds one which is Visual Studio 2008 and the other a CMake build that will be accelerated using the XGE interceptions interface 5. Integrate the solution built by CMake into the VS2008 solution However, using "BUILD_COMMAND msbuild " in the ExternalProject_Add macros leads to a couple of other problems related to Visual Studio using the "wrong" msbuild executable or not finding the right DLLs to load. Thanks a lot, Sascha and Ingmar -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Announcement: LuaDist a CMake based Lua Distribution
Hello CMake, It has been quite a while since anyone discussed CMake based distributions on the list. There have been efforts to start such a project before, see CMakePorts[1] project (now dormant). I would like to divert your attention to the LuaDist[2] project, more specifically to its Repository[3] of not only Lua specific modules. The LuaDist project is aimed at automated distribution of the Lua Programming language, however there are other use cases . For example the Repository aggregates fair share of open source libraries and projects converted to CMake which build (mostly) on Windows, Linux and OSX[4]. These can be beneficial to many developers in context of their projects as they can be included using externalproject_add[5]. Other use case relies on a Lua based CLI tool (luadist) that can deploy dependency chains automatically in a cross-platform manner, making it a rare cross-platform package manager. Currently, efforts are on the way to make the distribution completely independent from its initial aim to be a Lua distribution. We would like it to become a general purpose CMake based distribution of open-source software and libraries, that would of course require more maintainers and users. This is where you come in, would you (cmake users) be willing to help create and standardize a CMake based distribution ? Any opinions are welcome. Peter Drahos PS: LuaDist as a project is in late pre release candidate stage. An older download is available here[6] [1] http://code.google.com/p/cmakeports/ [2] http://luadist.org/ [3] https://github.com/LuaDist/Repository [4] http://travis-ci.org/ , search for LuaDist [5] http://www.kitware.com/products/html/BuildingExternalProjectsWithCMake2.8.html [6] https://github.com/LuaDist/Repository/downloads -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] add_custom and files generated into subdirectories
Hi Micha - On Apr 12, 2012, at 2:42 AM, Micha Renner wrote: > I guess, this is one of the rare cases where one need: > > SET_SOURCE_FILES_PROPERTIES(Foo.cpp PROPERTIES GENERATED TRUE) > Thanks! There's no way to do this automatically? I'd be fine with not having cmake try to find source files for any project automatically when I'm generating the makefiles from cmake. thanks, /-Will -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Cross-compilation on Linux targeting Windows
On 12 April 2012 21:12, Clifford Yapp wrote: > Having done a little investigation into cross-compilation (after > blowing away my Windows partition more or less unintentionally) it > looks like our build is Not a Good Candidate - we do a truckload of > introspection, as well as using custom commands and targets based off > of binaries we build during compilation. > > While this problem (executables generated for a different platform > during build testing) is of course not solvable in the general case, > on Linux there is actually a glimmer of hope that binaries built for > Windows *could* be run as part of the build process - i.e. using Wine > when running each binary that is an output of the current build > process. > > Has anyone ever looked into this? Would it be possible to have > TRY_RUN, execute_process and add_custom_command (plus any others I > missed) use wine "under the hood" to execute WIN32 compiled build > targets? > > That actually caused me about 2-3 hours of bewilderment when I first switched from gentoo to an ubuntu machine with wine installed. All my windows cross compiles went awol and it took that long to work out that the build system was actually successfully executing some tests. I never took advantage of it though - so I can't tell you if there are many traps lurking under the hood due to niggling inconsistencies. It should be quite feasible though. Daniel. Cheers, > CY > -- > > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Follow this link to subscribe/unsubscribe: > http://www.cmake.org/mailman/listinfo/cmake > -- Phone : +82-10-5400-3296 (010-5400-3296) Home: http://snorriheim.dnsdojo.com/ Yujin Robot: http://www.yujinrobot.com/ Embedded Ros : http://www.ros.org/wiki/eros Embedded Control Libraries: http://snorriheim.dnsdojo.com/redmine/wiki/ecl -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Cross-compilation on Linux targeting Windows
Having done a little investigation into cross-compilation (after blowing away my Windows partition more or less unintentionally) it looks like our build is Not a Good Candidate - we do a truckload of introspection, as well as using custom commands and targets based off of binaries we build during compilation. While this problem (executables generated for a different platform during build testing) is of course not solvable in the general case, on Linux there is actually a glimmer of hope that binaries built for Windows *could* be run as part of the build process - i.e. using Wine when running each binary that is an output of the current build process. Has anyone ever looked into this? Would it be possible to have TRY_RUN, execute_process and add_custom_command (plus any others I missed) use wine "under the hood" to execute WIN32 compiled build targets? Cheers, CY -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] binary contains an unresolvable reference to symbol sym
Dear all,
I am trying to solve one remaining issue with one of my package in
debian [1]. The report says basically "binary contains an
unresolvable reference to symbol sym". According to the documentation
[2]:
The indicated symbol has not been found in the libraries linked
with the binary. The binary is most likely a plugin and the sym-
bol is probably provided by the program that loads this plugin.
In theory a plugin doesn't have any SONAME but this binary does
have one and as such it could not be clearly identified as such.
However the fact that the binary is stored in a non-public
directory is a strong indication that's it's not a normal shared
library. If the binary is really a plugin, then disregard this
warning. But there's always the possibility that it's a real
library and that programs linking to it are using an RPATH so
that the dynamic loader finds it. In that case, the library is
broken and needs to be fixed.
The solution seems pretty straightforward: remove the -soname command
line switch when generating the python module. Looking at:
Modules/CMakeCInformation.cmake I can see:
...
IF(NOT CMAKE_C_CREATE_SHARED_MODULE)
SET(CMAKE_C_CREATE_SHARED_MODULE ${CMAKE_C_CREATE_SHARED_LIBRARY})
ENDIF(NOT CMAKE_C_CREATE_SHARED_MODULE)
...
So basically /module/ and /shared/ behave exactly the same on *nix
platform, correct ? If so how is someone supposed to remove the
explicit setting of CMAKE_SHARED_LIBRARY_SONAME_C_FLAG in such case ?
For example on my system I can see:
$ readelf -d /usr/lib/pyshared/python2.7/_gdcmswig.so | grep SONAME
0x000e (SONAME) Library soname: [_gdcmswig.so]
While in another package (using python distutils/setup.py):
$ readelf -d /usr/lib/python2.7/dist-packages/libtiff/tif_lzw.so | grep SONAME
-> no output
Thanks much in advance,
[1] https://buildd.debian.org/~brlink/packages/g/gdcm.html
[2] http://man.he.net/man1/dpkg-shlibdeps
--
Mathieu
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.7.8 cannot find boost installation While building PCL files.
Hi, you could set Boost_DEBUG and Boost_DETAILED_FAILURE_MSG to true and have a look at the messages. I hope, this helps you. Andreas Am 12.04.2012 11:06, schrieb Joeri Friederich: Hi Im trying to build PCL (Point cloud library) files using Cmake. It needs a bunch if dependencies one of which is boost. It finds all other dependencies without a hitch but it gives this error for boost: The following Boost libraries could not be found: boost_system boost_filesystem boost_thread boost_date_time boost_iostreams I have been trying to fix this for 2 days now. What I did: I build my own libraries with boost.build using the following commands: >b2 >toolset=gcc >--build-dir=C:\boost >--build-type=complete This build the library successfully. Adding the files (libboost_thread-mgw46-mt-1_49.dll) etc to the lib folder in my boost installation doesn't allow cmake to find them though. It does however find the include directory without a hitch. Even manually linking Cmake to the (correct) libraries doesn't allow it to find them. How do I get cmake to find these lib's? Also: boost_thread doesnt exist on my computer but "libboost_thread-mgw46-mt-1_49.dll" and 20 different versions of it with different letters at mt do. is there a way that I can see what file Cmake is looking for exactly? Version etc: Cmake:2.8.7 Cmake generator: Mingw makefiles Compiler: GCC. Boost v:1.49.0 Windows 7 Thanks for any help, Joeri. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] CMake 2.7.8 cannot find boost installation While building PCL files.
Hi Im trying to build PCL (Point cloud library) files using Cmake.It needs a bunch if dependencies one of which is boost.It finds all other dependencies without a hitch but it gives this error for boost: The following Boost libraries could not be found:boost_systemboost_filesystemboost_threadboost_date_timeboost_iostreamsI have been trying to fix this for 2 days now. What I did:I build my own libraries with boost.build using the following commands:>b2>toolset=gcc>--build-dir=C:\boost>--build-type=completeThis build the library successfully. Adding the files (libboost_thread-mgw46-mt-1_49.dll) etc to the lib folder in my boost installation doesn't allow cmake to find them though.It does however find the include directory without a hitch.Even manually linking Cmake to the (correct) libraries doesn't allow it to find them. How do I get cmake to find these lib's? Also:boost_thread doesnt exist on my computer but "libboost_thread-mgw46-mt-1_49.dll" and 20 different versions of it with different letters at mt do.is there a way that I can see what file Cmake is looking for exactly? Version etc:Cmake:2.8.7Cmake generator: Mingw makefilesCompiler: GCC.Boost v:1.49.0Windows 7 Thanks for any help, Joeri.-- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] add_custom and files generated into subdirectories
I guess, this is one of the rare cases where one need: SET_SOURCE_FILES_PROPERTIES(Foo.cpp PROPERTIES GENERATED TRUE) Greetings Micha Am Mittwoch, den 11.04.2012, 11:18 -0500 schrieb William R. Otte: > Hi - > > I have a question about resolving dependencies when add_custom is used to > generate files into subdirectories. Consider the following example > (substantially simplified from my use case, but it captures the essence of > what I am trying to do: > > In the root of the project, I have the following: > > /Foo.cmake: > add_custom_command (OUTPUT Bar/Foo.cpp > COMMAND touch Bar/Foo.cpp >) > > #end /Foo.cmake > > /CMakeLists.txt: > cmake_minimum_required(VERSION 2.8) > > include (Foo.cmake) > add_subdirectory (Bar) > > #end /CMakeLists.txt > > In a subdirectory Bar, I have the following: > > /Bar/Bar.cmake: > add_library ( Bar SHARED > Foo.cpp ) > #end /Bar/Bar.cmake > > /Bar/CMakeLists.txt: > include (Bar.cmake) > #end /Bar/CMakeLists.txt > > > When I attempt to compile this into makefiles, I get the following diagnostic > from cmake: > > CMake Error at Bar/Bar.cmake:1 (add_library): > Cannot find source file: > > Foo.cpp > > Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp > .hxx .in .txx > Call Stack (most recent call first): > Bar/CMakeLists.txt:1 (include) > > > I understand why that diagnostic is appearing (cmake knows about a > Bar/Foo.cpp, but not about a Foo.cpp). Is there some way to get Cmake to > automagically realize that within the context of Bar.cmake, Foo.cpp and > Bar/Foo.cpp are the same thing? > > thanks, > /-Will > > -- > > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Follow this link to subscribe/unsubscribe: > http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Adding QML files to project in CMakeLists.txt
On 12.04.12 03:25:35, Arjun Basu wrote: > Hello, > > I am Arjun. I have used cmake in the process of building many packages in > Linux but I am new to writing CMakeLIsts.txt file for my projects. I have a > Qt Quick project for which I wish to use cmake. I was wondering if adding > QML files to projects is supported in cmake. I googled for it but didn't > get any helpful results. Since QML files are not compiled this doesn't make much sense. If you want to copy them from the source to the builddir so you can run your qml-app from the builddir simply use a custom-command or configure_file. Andreas -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
