Re: [CMake] can I use cmake in parallel with Eclipse IDE?
It's not about neither CMake or eclipse, but your target build system. CMake is the build system of build system, the actually work is related to the target building system. If you generated eclipse CDT project + Makefile, of course it might be parallel, there is the option when you create the project. At Linux platform, the eclipse and Codeblocks work as well, just work for basic requirement, such as stepping, launch the application from IDE with arguments. Just some experience, thanks. On Sun, Jan 27, 2019 at 9:29 AM hex wrote: > hello, > > I want to use CMake as my primary build system. At some point I would like > to take advantage of the tools provided by IDEs, such as stepping through > code. > > I know I can use CMake to generate an eclipse project, or use Eclipse to > generate a CMake project. My doubt is whether these options are merely > meant for import purposes or can these be used in parallel, i.e., switching > between my CMake project and Eclipse back and forth. > > I was reading about *launch.json* files and it seems that these can be > used to launch any application with it. > > please advice, > > > thank you > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake > -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] Get linker flags / include directories for a library target
All the flags/options in the CMake they could be considered as a list. So it's much more easier to handle it as this set(WIN_DEFINITIONS -DNOMINMAX) Remember the list is the object, so we could construct the new list for the specific target. Then to the specific target, just use the 3 commands. target_compile_options() target_include_directories() target_link_libraries() We use this method to organize the cross-platform with library and executable without any problem, and super easy to control and manage. Thanks. On Fri, Dec 21, 2018 at 7:19 AM Unknown wrote: > Dear community, > > I have been wondering on multiple occasions about how to get the > linker flags (i.e. all -llib -Ldir) and include flags (-Idir) > for a library (i.e. a target added to the project using > add_library) within a cmake. > > There are many cases in which the flags are required, noticeably > generating a suitable pkg-config file or creating a wrappers around > C/C++ libraries. > > I think that it should be possible to derive the flags from > some of the target properties of the library, but I don't > know exactly how. > > Could you give me a hand? > > ax487 > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake > -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] Odd Behavior in macOS Mojave
At MacOS, in 99% cases, the build task always needs to setup the variables - CMAKE_OSX_TARGET - CMAKE_OSX_DEPLOYMENT_TARGET This 2 variables are important. The CMAKE_OSX_TARGET would define the minimal set of API during compilation, and this affects the built binary. The second is the path to the OSX SDK, usually it stays in /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs . Since SDK changes file and directory structure according the language feature, this is important to the program which has to use C++11 or C++14 or new header files. Personally I only use 10.9 SDK, which is the first version migrated to C++11, and SDK changed a lot compared to 10.8, and the program is compatible with the later system. On Thu, Nov 15, 2018 at 3:42 AM Steven Stallion wrote: > On Wed, Nov 14, 2018 at 10:54 AM Sean McBride > wrote: > > > I see. Well, I just checked my macOS 10.14.1 / Xcode 10.1 bot > "RogueResearch12" and indeed it does not have a /usr/include folder. It is > however able to build CMake, VTK, and ITK nightly without any compiler > errors. > > > > Perhaps it's not so much a CMake bug as a bug in the project you're > trying to build? > > Interesting. I'll take another look - I wonder if it's a bad > interaction from calling clang from a custom command. > > Thanks for taking a look! > Steve > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake > -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] Link order (Ubuntu)
Oh, if that's shared libraries, maybe you have to setup the LD_LIBRARY_PATH
well for the shared libraries before linking, it just allows the linker to
be able to locate the all necessary dynamic libraries during the linking.
It happens sometimes on Linux, but not exists on OSX and Windows.
On Tue, Nov 6, 2018 at 11:19 PM Giorgio Scorzelli
wrote:
> Thanks for you help.
>
> They are really shared lib, not static. I know it sounds weird: it's a
> python extension which must not link the ${PYTHON_LIBRARY} (according to
> official docs; in fact If I do so I get a segmentation fault) but finally
> in my executable,a sort of custom/home made ${PYTHON_EXECUTABLE}, I have
> to link the ${PYTHON_LIBRARY}.
>
> About the "B;A;ImportedExtLib;B;A" order. I agree too: it SHOULD work.
> Let's say I do:
>
> target_link_libraries(MyExe B A ImpLib)
>
> in command line (make VERBOSE=1) I;m getting
>
> g++ -o MyExe B A ImpLib A
>
> The last "A" is coming from target_link_libraries(B PUBLIC A) and the
> linker is complaining that this last "A" has undefined symbols.
>
> Thanks.Giorgio.
>
>
>
>
>
>
>
>
> Il giorno mar 6 nov 2018 alle ore 06:59 Robert Maynard <
> robert.mayn...@kitware.com> ha scritto:
>
>> You have order dependent static libraries which can be solved by
>> constructing a cycle. As Bo stated by constructing the cycle
>> B;A;ImportedExtLib;B;A each library can see each other.
>>
>> Looking at your original code example it looks like you are importing
>> the libraries as SHARED, but I think these are actually static
>> libraries and should be imported as such so that CMake does the
>> automatic cycle creation. In general CMake doesn't do cycle creation
>> for shared libraries as they are not link order dependent.
>> On Tue, Nov 6, 2018 at 8:51 AM Giorgio Scorzelli
>> wrote:
>> >
>> > I read the docs about LINK_INTERFACE_MULTIPLICITYtoo.
>> > But I'm not in the situation of a "cyclic dependency" so I 'm not sure
>> if it solve my problem.
>> > In my case (with B A and ImpLib) what would be the syntax?
>> >
>> > Il giorno mar 6 nov 2018 alle ore 06:30 Robert Maynard <
>> robert.mayn...@kitware.com> ha scritto:
>> >>
>> >> The target_link_libraries has a property called
>> >> LINK_INTERFACE_MULTIPLICITY that should help you out.
>> >>
>> https://cmake.org/cmake/help/v3.13/command/target_link_libraries.html#cyclic-dependencies-of-static-libraries
>> >>
>> >>
>> >> On Tue, Nov 6, 2018 at 8:24 AM scrgiorgio
>> wrote:
>> >> >
>> >> > Thanks for the help,
>> >> >
>> >> > trying this (or any combination):
>> >> >
>> >> > target_link_libraries(MyExe B)
>> >> > target_link_libraries(MyExe A )
>> >> > target_link_libraries(MyExe ImpLib)
>> >> >
>> >> > I get this order:
>> >> >
>> >> > 'B;...whatever...;A;ImpLib"
>> >> >
>> >> > and the last past is causing the problem. Apparently there is no way
>> to
>> >> > change the right part (-Wl,--start-group -Wl,--end-groun sometimes
>> work,
>> >> > sometimes not).
>> >> > Any advice?
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Sent from: http://cmake.3232098.n2.nabble.com/
>> >> > --
>> >> >
>> >> > Powered by www.kitware.com
>> >> >
>> >> > Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>> >> >
>> >> > Kitware offers various services to support the CMake community. For
>> more information on each offering, please visit:
>> >> >
>> >> > CMake Support: http://cmake.org/cmake/help/support.html
>> >> > CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> >> > CMake Training Courses: http://cmake.org/cmake/help/training.html
>> >> >
>> >> > Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>> >> >
>> >> > Follow this link to subscribe/unsubscribe:
>> >> > https://cmake.org/mailman/listinfo/cmake
>>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow
Re: [CMake] Link order (Ubuntu)
Hi
This is the classical issue of GNU toolchain for many years, usually super
painful when the program has to be linked with several static libraries.
One easy way to solve this issue is that you could specify the same library
for multiple times if the manual order really doesn't work well, then the
generated binary might have the complete symbols.
Thanks very much.
On Tue, Nov 6, 2018 at 9:53 AM scrgiorgio wrote:
> i have the following CMakeList.txt:
>
>
> add_library(ImpLib SHARED IMPORTED GLOBAL)
> set_property(TARGET ImpLib APPEND PROPERTY INTERFACE_INCLUDE_DIRECTORIES
> ...)
> set_target_properties(ImpLib PROPERTIES IMPORTED_LOCATION ...)
>
> add_library(A SHARED)
> # COMMENTED! A uses ImpLib but cannot link it because some third-party
> executables requires 'run-time symbol resolution'
> # target_link_libraries(A PUBLIC ImpLib )
>
> add_library(B SHARED)
> target_link_libraries(B PUBLIC A)
> # COMMENTED! B uses ImpLib but cannot link it for the same previous reason
> # target_link_libraries(B PUBLIC ImpLib )
>
> # my executable requires ImpLib explicit/default cmake linking
> add_executable(MyExe)
> target_link_libraries(MyExe B)
> target_link_libraries(MyExe ImpLib )
>
> The CMake generated link order is (g++ -o ): "B;ImportedExtLib;A"
> But in this way A cannot find symbols from ImpLib (at least using g++).
>
> The right order is: "B;A;ImpLib"
>
> I tried with "target_link_libraries(A INTERFACE ImpLib)" but then B will
> link ImpLib
>
> I tried "set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS}
> -Wl,--start-group")" but sometimes it does not work.
>
> is it doable? Can I force the right order?
>
>
>
>
>
> --
> Sent from: http://cmake.3232098.n2.nabble.com/
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Re: [CMake] Conflicting MSVC manifests
>From my personal experience, I suggest never touch the manifest, because
it's not a useful configuration to solve the DLL hell issue since Windows
XP.
Instead, once we know the exact version of Visual Studio with Update, the
distributor just ship the MSVC runtime installer with software, the
installer would install the required MSVCRuntime locally, so everything
almost exactly matches without touching the crazy configuration.
On MSVC, you should always use Visual Studio MSBuild rather than the other
build system, just use
cmake --build --target INSTALL --config Release
That's it.
Thank you very much.
On Tue, Aug 21, 2018 at 6:02 PM Øystein Walle wrote:
> Hi,
>
> I am experiencing an error when trying to require administrator privileges
> on
> Windows. I have made a small test case[1] available to demonstrate the
> issue.
> CMake generates its own manifest and at link time MSVC is unable to merge
> CMake's and my own manifest, giving the following error:
>
> manifest authoring error c1010001: Values of attribute "level" not
> equal
> in different manifest snippets.
>
> The error occurs both when generating a VS project and generating Ninja
> build
> files with the MSVC toolchain with CMake 3.12.1.
>
> This problem can be worked around by adding the following to CMakeLists.txt
> instead using the manifest file (thanks to ngladitz at #cmake@freenode):
>
> set_property(TARGET ${PROJECT_NAME} PROPERTY
> LINK_FLAGS "/MANIFESTUAC:level='requireAdministrator'"
> )
>
> However, CMake has had support for adding manifest files to the list of
> sources
> since 3.4. Should this particular usage of a manifest file be an
> exception? If
> so, are there any other potential conflicts?
>
> If's desirable to rather fix the issue maybe the options I see are:
>
> - Use the user's manifest (if present) and discard CMake's own,
> - Configure MSVC to let one manifest file yield when conflicts are present
>(not sure if this is possible),
> - Do the merge in CMake itself (yuck, I guess...)
>
> I'm new to the MSVC toolchain so there may be some obvious solutions I
> am overlooking here...
>
> Regards,
> Øsse
>
> [1]: https://github.com/Osse/manifesttest
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Re: [CMake] Using Different Computers for cmake and ctest
Maybe you could improve the CTest system to allow execute remotely, by a shared file system to hold the all built binary files, and do a RPC-like test, and redirect the all output and terminate code from the target GPU machine, it should be able to work. On Wed, Jul 18, 2018 at 10:50 PM Brian S wrote: > I currently use cmake/ctest to build and test my software. The software is > C++/CUDA. During the build step I don't need a GPU but in the test step I > do. I would like to build the code with cmake on a cluster with many CPUs > and then run the tests using ctest on a target machine with a GPU. Is this > possible? > > I have thought about using nvidia-docker but that only works on one of my > target platforms. > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake > -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] find_library doesn't find .dll on windows
Hi,
This is a feature/problem on Windows, the library used for dynamic linking
is not the runtime module as Linux or OSX but the .lib, a collection of
symbols.
I suggest you could still use find_library() to locate the .lib file for
linking, then use find_file() to collect the runtime file then install it
to the distribution.
Thanks.
On Fri, Jun 1, 2018 at 11:53 PM Romain LEGUAY
wrote:
> Hi everyone,
>
> I try to find MYSQL dynamic library on windows.
> For this, I use the following command:
>
> set(_PF86 "ProgramFiles(x86)")
> find_library( MYSQL_LIBRARY
> NAME "libmysql.dll"
> PATHS "$ENV{PROGRAMFILES}/MySQL/*/lib"
> "$ENV{${_PF86}}/MySQL/*/lib"
> "$ENV{SYSTEMDRIVE}/MySQL/*/lib"
> NO_DEFAULT_PATH)
>
> This command doesn't work on my computer (Windows 10 Pro x64, CMake
> 3.11.3).
> If I remove the .dll extension, find_library find libmysql.lib which is in
> the same folder as libmysql.dll.
>
> How to say to CMake to use the name I chosen?
>
> Thank you!
> Romain
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Re: [CMake] static linking on Ubuntu
Hi, You can archive what youwant from the find_library() with NAMES parameter, for example, find_library(THELIB NAMES libthelib.a thelib-static thelib), it would try to pick the static library firstly. Boost. You have to set Boost_USE_STATIC_LIBS before find_package(Boost), so the CMake would try to pick up the static libraries, of course, you should already own the static libraries. Thank you very much and good luck. On Thu, Jun 7, 2018 at 8:07 AM, wrote: > Hi folks, > > > > The P4 programming language has a compiler called p4c with a variant in > p4c-xp. This compiler executable is built on Ubuntu 16.04. p4c-xp uses > cmake. As one can see, there are several shared libs used by p4c-xp. Each > shared lib may call other shared libs. I could use some help with cmake. > I have used some cmake help for creating a single static lib but the steps > did not help on Ubuntu. Further, I would like cmake to automatically > detect other shared lib dependencies and build a statically linked > executable. > > > > $ ldd p4c-xp > > linux-vdso.so.1 => (0x7ffd2cd06000) > > libboost_iostreams.so.1.58.0 => > /usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.58.0 > (0x7f0efa732000) > > libgmp.so.10 => /usr/local/lib/libgmp.so.10 (0x7f0efa4bb000) > > libgmpxx.so.4 => /usr/lib/x86_64-linux-gnu/libgmpxx.so.4 > (0x7f0efa2b5000) > > libgc.so.1 => /usr/local/lib/libgc.so.1 (0x7f0efa048000) > > librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f0ef9e4) > > libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 > (0x7f0ef9abe000) > > libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f0ef97b5000) > > libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 > (0x7f0ef959f000) > > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f0ef91d5000) > > libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 > (0x7f0ef8fc5000) > > libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f0ef8dab000) > > libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 > (0x7f0ef8b8e000) > > libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f0ef898a000) > > /lib64/ld-linux-x86-64.so.2 (0x7f0efa94b000) > > > > Regards, > > > > Hemant > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake > > -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] Can find_package(...) distinguish between debug and release installs?
Hi, Since you're using FetchContent/ExternalProject_Add, you could create a special stage installation folder for those external projects, organize them by different configurations, for example. 3rdParty/Debug/zlib/include+lib 3rdParty/Release/zlib/include+lib So with this way, the name from the external libraries is not that important, we just take care the specific name for specific platform. >From the project needs these libraries, you could set the XXX_ROOT to tell CMake built-in module where to locate the dependency, or locate the include folder and library manually for the different configurations, it would work for both VisualStudio-based project and GCC/Clang projects. Good luck. On Tue, Apr 10, 2018 at 9:59 PM, Saad Khattak wrote: > Thanks Bo. > > I have added the suffix to my libraries already, however with some 3rd > party libraries that I am getting with FetchContent, I have no control over > how they name their libraries. > > Now, their Config.cmake files have release targets that are > globbed by one of the CMake config files (which is part of the install > process). So CMake 'can' figure out which configuration has been installed > and I was hoping that there was a built-in way to distinguish that rather > than me writing some custom scripts for it (where the scripts will search > for the debug/release target files). > > On Mon, Apr 9, 2018 at 11:03 PM Bo Zhou wrote: > >> Hi, >> >> Generally speaking, no, you might have to use the suffix or special name >> to distinguish the different library, such as with the "_d" suffix. >> >> The Boost module of CMake is a considerable example, since it could >> generate different names for Debug and Release libraries on Windows. >> >> At POSIX(UNIX, OSX, Linux), sometimes user mixes the library, it still >> works well. On Windows, it's dangerous or even won't work with mixed >> libraries which were built by different Visual Studios with different >> runtime libraries. >> >> Cheers. >> >> On Tue, Apr 10, 2018 at 10:56 AM, Saad Khattak >> wrote: >> >>> Hi, >>> >>> When find_package(LibA) sets the LibA_FOUND variable, is it possible to >>> know if the package found is the Debug or Release build (or both)? I have a >>> fairly complex build setup where I need to be able to distinguish if >>> find_package(LibA) found a Debug or Release build. >>> >>> - Saad >>> >>> -- >>> >>> Powered by www.kitware.com >>> >>> Please keep messages on-topic and check the CMake FAQ at: >>> http://www.cmake.org/Wiki/CMake_FAQ >>> >>> Kitware offers various services to support the CMake community. For more >>> information on each offering, please visit: >>> >>> CMake Support: http://cmake.org/cmake/help/support.html >>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>> >>> Visit other Kitware open-source projects at http://www.kitware.com/ >>> opensource/opensource.html >>> >>> Follow this link to subscribe/unsubscribe: >>> https://cmake.org/mailman/listinfo/cmake >>> >>> >> -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] Can find_package(...) distinguish between debug and release installs?
Hi, Generally speaking, no, you might have to use the suffix or special name to distinguish the different library, such as with the "_d" suffix. The Boost module of CMake is a considerable example, since it could generate different names for Debug and Release libraries on Windows. At POSIX(UNIX, OSX, Linux), sometimes user mixes the library, it still works well. On Windows, it's dangerous or even won't work with mixed libraries which were built by different Visual Studios with different runtime libraries. Cheers. On Tue, Apr 10, 2018 at 10:56 AM, Saad Khattak wrote: > Hi, > > When find_package(LibA) sets the LibA_FOUND variable, is it possible to > know if the package found is the Debug or Release build (or both)? I have a > fairly complex build setup where I need to be able to distinguish if > find_package(LibA) found a Debug or Release build. > > - Saad > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake > > -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] How to build CMake so it works on an older Linux?
When use Devtoolset of CentOS, don't forget to install the *binutils* from that devtoolset, or else, the compilation might generate strange error. On Fri, Apr 6, 2018 at 6:13 AM, Alexander Neundorf wrote: > On 2018 M04 5, Thu 15:15:21 CEST Juan E. Sanchez wrote: > > The example I just sent was for building in centos 6, because 5 is gone. > > not really gone, it's still in vault.centos.org :-) > https://hub.docker.com/r/aneundorf/centos5-build-base/~/dockerfile/ > > Alex > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake > -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] [FYI] clang-3.4 vs cmake-3.11.0 (How to build CMake so it works on an older Linux?)
The emplace() is new API from C++11. Be aware that GCC suite actually is independent from the libstdc++, so if you have a newer compiler, the compiler might still pick the older libstdc++ without the new API. This issue doesn't exist at Windows, since Visual Studio is a complete sytem. This issue happens on OSX also, so user must give the compiler a proper MacOS SDK for the new header files etc. On Thu, Apr 5, 2018 at 1:33 PM, suzuki toshiya wrote: > $ clang++ --version > Ubuntu clang version 3.4-1ubuntu3~precise2 (tags/RELEASE_34/final) (based > on > LLVM 3.4) > Target: x86_64-pc-linux-gnu > Thread model: posix > > But I got following abort: > > cmake-3.11.0/Source/cmLocalGenerator.cxx:553:36: error: no member named > 'emplace' in > 'std::unordered_map, cmGeneratorTarget *, > std::hash, std::equal_to >, > std::allocator, > cmGeneratorTarget > *> > >' > this->GeneratorTargetSearchIndex.emplace(gt->GetName(), gt); > ~~~~~~~~ ^ > > G X-D > > Regards, > mpsuzuki > > suzuki toshiya wrote: > > Dear Bo Zhou, > > > > Thank you for the info! Now I'm checking Ubuntu 12.04 in LXC. > > So, gcc-4.8.5 or later would be needed for C++11, it seems that the last > version > > of gcc officially provided for Ubuntu-12 was 4.7. oh. > > According to https://clang.llvm.org/cxx_status.html , clang-3.3 > supports C++11, > > and the last version of clang officially provided for Ubuntu-12 was 3.4. > ooh. > > I will check if clang-3.4 for Ubuntu-12.04 can compile cmake (or any > other > > dependency problems would arise). > > > >> Usually the ABI is not the problem but the libstdc++, you can use a old > Ubuntu with old libstdc++ but build CMake with new compiler and make sure > it links with old libstdc++. This is the trick. > > > > Indeed. > > > > Regards, > > mpsuzuki > > > > Bo Zhou wrote: > >> The latest CMake requires C++11 compiler, so what you need is just a > newer GCC which supports C++11 at your platform, that's it. > >> > >> Usually the ABI is not the problem but the libstdc++, you can use a old > Ubuntu with old libstdc++ but build CMake with new compiler and make sure > it links with old libstdc++. This is the trick. > >> > >> I don't know how to do this on Ubuntu, but on CentOS, it's possible to > build CMake in that way, so the CMake would be portable at older CentOS > platform with old libstdc++ . > >> > >> Good luck. > >> > >> On Thu, Apr 5, 2018 at 12:23 PM, Eric Wing ewmail...@gmail.com>> wrote: > >> I just discovered that CMake no longer builds on my Ubuntu 12.04. I > >> need to build binaries that are compatible with that ABI. > >> > >> I see that your binary distribution of CMake 3.11 still works on > >> Ubuntu 12.04. Can you tell me what you do to achieve this? What are > >> you doing for your official builds? > >> > >> Are you just using -static-libstdc++ -static-libgcc for > >> CMAKE_CXX_FLAGS, or is there more? > >> > >> (I just noticed that ldd shows that you don't have dependencies on > >> libssl, libcrypto, and libz, whereas I do.) > >> > >> Thanks, > >> Eric > >> -- > >> > >> Powered by www.kitware.com<http://www.kitware.com> > >> > >> Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > >> > >> Kitware offers various services to support the CMake community. For > more information on each offering, please visit: > >> > >> CMake Support: http://cmake.org/cmake/help/support.html > >> CMake Consulting: http://cmake.org/cmake/help/consulting.html > >> CMake Training Courses: http://cmake.org/cmake/help/training.html > >> > >> Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > >> > >> Follow this link to subscribe/unsubscribe: > >> https://cmake.org/mailman/listinfo/cmake > >> > >> > >> > > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.
Re: [CMake] How to build CMake so it works on an older Linux?
The latest CMake requires C++11 compiler, so what you need is just a newer GCC which supports C++11 at your platform, that's it. Usually the ABI is not the problem but the libstdc++, you can use a old Ubuntu with old libstdc++ but build CMake with new compiler and make sure it links with old libstdc++. This is the trick. I don't know how to do this on Ubuntu, but on CentOS, it's possible to build CMake in that way, so the CMake would be portable at older CentOS platform with old libstdc++ . Good luck. On Thu, Apr 5, 2018 at 12:23 PM, Eric Wing wrote: > I just discovered that CMake no longer builds on my Ubuntu 12.04. I > need to build binaries that are compatible with that ABI. > > I see that your binary distribution of CMake 3.11 still works on > Ubuntu 12.04. Can you tell me what you do to achieve this? What are > you doing for your official builds? > > Are you just using -static-libstdc++ -static-libgcc for > CMAKE_CXX_FLAGS, or is there more? > > (I just noticed that ldd shows that you don't have dependencies on > libssl, libcrypto, and libz, whereas I do.) > > Thanks, > Eric > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake > -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] absolute library path, sorry for the question
https://cmake.org/cmake/help/v3.0/command/find_path.html Please try to pass the NO_CMAKE_SYSTEM_PATH to find_path() and find_library(), but use the HINT to pass the path to thirdparty paths. Of course use the CMAKE_VERBOSE_MAKEFILE to check the log. At the last check the CMakeCache.txt to verify everything is okay. On Sun, Dec 24, 2017 at 3:50 AM, Alan W. Irwin wrote: > On 2017-12-23 10:47+0100 Andreas Naumann wrote: > > your problem is hard to analyse. If you have a "minimal" example, which >> shows this behavior, we could test it. In your last mail, you wrote about >> building and installing libtiff using your own libjpeg. But than you write >> about a later build. So something must happen in the "later build". >> > > @Mario: > > I second everything said here by Andreas. So I think, for example, > that your next step should be to create a minimal example (e.g., a > "hello, world" minimal test C executable that is [over-]linked to one > of your libraries in a non-standard location). Then compare your > "make VERBOSE=1" results for that simple example on your multiple > platforms to see whether the linking is done with the library in the > correct non-standard location rather than the system library. > > Furthermore you stated in your original post that for some of your > platforms CMake use the -l linking option to link, and you thought > that was an issue. Actually, that is fine if CMake also generates an > -L option pointing to the correct non-standard location since linkers > use the combination of -L and -l options to locate the library if it > is not specified as an absolute path. > > So my guess from what you have said is you forgot about the -L option > also generated by CMake, and, in fact, CMake is working correctly to > link your code on all platforms. Anyway, if your "make VERBOSE=1" > results prove that is the case, then your next step should be to > configure your build system so that an -rpath option is used by the > linker so that the system loader for your executable can find the > library in its non-standard location at run time. > > My own linking experience (currently with CMake-3.6.2 and higher) is just > limited to my Debian platform at this time, but I do successfully > use some libraries that are installed in non-standard system > locations. And my experience is a properly configured CMake-based > build system links those libraries with the appropriate -rpath option > with good results (using the library version in the non-standard > location) both at link time and run time. > > Alan > __ > Alan W. Irwin > > Astronomical research affiliation with Department of Physics and Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the FreeEOS equation-of-state > implementation for stellar interiors (freeeos.sf.net); the Time > Ephemerides project (timeephem.sf.net); PLplot scientific plotting > software package (plplot.sf.net); the libLASi project > (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); > and the Linux Brochure Project (lbproject.sf.net). > __ > > Linux-powered Science > __ > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensou > rce/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake > -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] absolute library path, sorry for the question
Hi CMAKE_SKIP_RPATH usually is used for the shared module which might want to have the customized distributed path such as within the application. According personal experience on POSIX systems (Linux, UNIX, OSX), always enable CMAKE_SKIP_RPATH for the all local shared dependencies, and to the final distribution, (if needed) put shared libraries into the lib folder of distribution. According your description, I'm not sure how did you pick up your library into the application from CMake, usually we have to make sure the CMake always chooses the libraries from 3rd-party directory not system or another places. In our system, it has a variable THIRDPARTY_DIR for command FIND_PATH() to locate the folder which contains the all built libraries, then use HINTS and NAMES in the command FIND_PATH() and FIND_LIBRARY() to locate the correct paths for the pre-built libraries, so the linking should be okay. If everything has no error, but just the application always picks up the system's library not the 3rd-party libraries we prepared, one solution would add another loader script for the application, from the loader script it appends the local lib folder to LD_LIBRARY_PATH, then launch the actual application executable file. A lot of commercial application on Linux solve the similar issue by this way. Wish my reply is helpful. Thank you very much. On Wed, Dec 13, 2017 at 6:06 PM, Mario Emmenlauer wrote: > > Dear cmake users, > > I have found good documentation on the cmake wiki about RPATH and > its different variables, and also on the mailing lists. But somehow > it still does not add up for me. Can you please help? > > I use cmake 3.9.5 on different platforms, CentOS 6 and Ubuntu 14.04 > amongst others. I build many standard libraries (like tiff and jpeg) > into my own thirdparty directory, and set CMAKE_PREFIX_PATH to find > them there. On newer Linux and Windows, cmake uses always the absolute > path to those libraries, and everything works fine. But on older Linux > like Ubuntu 14.04 and CentOS 6 it does not. cmake will first find the > library in the correct absolute thirdparty directory, and I can confirm > this by printing the 'XXX_LIBRARIES' variable in the find script. But > later the Makefile will link with '-lxxx' instead of the full path. > This makes 'ld' use the system library instead! > > I completely fail to understand at what point cmake changes XXX_LIBRARIES > from an absolute path to '-lxxx', for example for libjpeg. > > I have experimented with CMAKE_SKIP_BUILD_RPATH, but it does not help. > The only workaround I could find is to add the thirdparty directory to > LDFLAGS. Then 'ld' will also find the correct library. > > > Is this a bug, or an expected behavior? What parameters should I add > when I invoke cmake so that it will always use libraries with their > full path? > > > Cheers, > > Mario Emmenlauer > > > > PS: since I build thirdparty libraries, I prefer not to change their > CMakeLists.txt but would rather prefer to set better cmake command line > parameters. > > > References: > https://cmake.org/Wiki/CMake_RPATH_handling > https://cmake.org/pipermail/cmake/2015-September/061462.html > > > > -- > BioDataAnalysis GmbH, Mario Emmenlauer Tel. Buero: +49-89-74677203 > Balanstr. 43 mailto: memmenlauer * biodataanalysis.de > D-81669 München http://www.biodataanalysis.de/ > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Not able to find boost with cmake
It's better not to use downloaded pre-built libraries, always build by yourself locally. Before using Boost with CMake, please check https://cmake.org/cmake/help/v3.0/module/FindBoost.html If you're trying to use static boost libraries build by MSVC with shared runtime, please make sure the following statements exist in the PCL. set(Boost_USE_STATIC_LIBS ON) set(Boost_USE_MULTITHREADED ON) set(Boost_USE_STATIC_RUNTIME OFF) Then if you properly set the Boost_INCLUDE_DIR, all the libraries should be ready then. On Fri, Aug 4, 2017 at 1:05 PM, 钟元鑫 wrote: > I'm trying to build PCL which has boost as dependency. However, when I > download boost and build it, cmake cannot find it through any way. > > I tried two version of boost, one is pre-build boost which was built by > other person online and version is 1.61, another is one I downloaded whose > version is 1.64. File structures of the two versions are the same: > [XXX]/include/boost-1_64/boost is the include dir and [XXX]/lib is the bin > dir > > I try to specify the Boost_INCLUDE_DIR to [XXX]/include/boost-1_64/boost, > the messages in output window is attached (I turned Boost_DEBUG on). > > I'm on Window 10 and VS2017 > > Thanks, > Jacob Zhong > > -- > 顺颂时祺 > > 钟元鑫 Yuanxin Zhong > 清华大学汽车工程系 Dept. of Automotive Engineering, Tsinghua Univ. > Ad:Haidian District, Beijing, P.R.China100084 > Tel:+86 1733119 <+86%20178%208883%203119> > E-mail：cmp...@foxmail.com / zhongyx > 1...@mails.tsinghua.edu.cn > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] What is the default build type?
It depends on the Generator.
To the Makefile, the actual type was controlled by the compiler options. If
you don't specific any type, usually it means non-debug and
non-optimization because the CMAKE_CXX_FLAGS is empty as default. This is
critical, so usually people should specific the actual type they want to
build.
To the generator of the IDE, such as Visual Studio and Xcode, the
CMAKE_BUILD_TYPE doesn't make sense but we have to use
CMAKE_CONFIGURATION_TYPES, then CMake will create the several configuration
sets for the IDE from the CMAKE_C|CXX_FLAGS_{CONFIG} .
On Wed, Aug 2, 2017 at 1:57 PM, Florian Lindner wrote:
> Hi,
>
> Am 01.08.2017 um 16:59 schrieb J Decker:
> > I like having something like this defines CMAKE_BUILD_TYPE to be a
> droplist of choices...
> >
> >
> >
> > if( NOT CMAKE_CONFIGURATION_TYPES )
> > set( CMAKE_CONFIGURATION_TYPES debug release )
> > endif( NOT CMAKE_CONFIGURATION_TYPES )
> >
> > set( CMAKE_BUILD_TYPE release CACHE STRING "Cached cmake build type" )
> > set_property(CACHE CMAKE_BUILD_TYPE PROPERTY STRINGS
> ${CMAKE_CONFIGURATION_TYPES} )
>
> The droplist is really cool! Can't understand why it's not the default
> this way.
>
> https://cmake.org/cmake/help/v3.0/variable/CMAKE_CONFIGURATION_TYPES.html
> says "This has reasonable defaults on most
> platforms...", but when I message(${CMAKE_CONFIGURATION_TYPES}) it is
> empty. Why that?
>
> That code also does not seem to set the default:
>
> if(NOT CMAKE_CONFIGURATION_TYPES)
> set(CMAKE_CONFIGURATION_TYPES Debug Release RelWithDebInfo)
> endif()
>
> set(CMAKE_BUILD_TYPE Debug CACHE STRING "Build Type")
> set_property(CACHE CMAKE_BUILD_TYPE PROPERTY STRINGS
> ${CMAKE_CONFIGURATION_TYPES} )
>
> So the first commands set the cached value of the string "Build type". The
> second commands sets the property STRINGS of
> the variable CMAKE_BUILD_TYPE. Is that correct?
>
>
> # if (NOT CMAKE_BUILD_TYPE)
> # set(CMAKE_BUILD_TYPE Debug)
>
> Uncommenting this sets the default non builds with cmake, but not on
> ccmake (at least not in the GUI).
>
> # endif()
> message(STATUS "Build configuration: " ${CMAKE_BUILD_TYPE})
>
>
> Best Thanks,
> Florian
>
> >
> >
> > -
> >
> > https://cmake.org/cmake/help/v3.0/variable/CMAKE_
> CONFIGURATION_TYPES.html
> >
> > On Mon, Jul 31, 2017 at 9:28 PM, Michael Ellery > wrote:
> >
> >
> >
> > > On Jul 31, 2017, at 8:48 PM, Florian Lindner > wrote:
> > >
> > > Hello
> > >
> > > ccmake shows CMAKE_BUILD_TYPE as unset. From the compile commands
> it looks like also nothing like Debug nor Release.
> > >
> > > Why is there no well-defined default set? How can I set a default?
> > >
> > > Thanks,
> > > Florian
> > > --
> > >
> > > Powered by www.kitware.com
> > >
> > > Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
> >
> > >
> > > Kitware offers various services to support the CMake community.
> For more information on each offering, please visit:
> > >
> > > CMake Support: http://cmake.org/cmake/help/support.html <
> http://cmake.org/cmake/help/support.html>
> > > CMake Consulting: http://cmake.org/cmake/help/consulting.html <
> http://cmake.org/cmake/help/consulting.html>
> > > CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> > >
> > > Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
> >
> > >
> > > Follow this link to subscribe/unsubscribe:
> > > http://public.kitware.com/mailman/listinfo/cmake <
> http://public.kitware.com/mailman/listinfo/cmake>
> >
> >
> > my recollection is that an unspecified build type results in a build
> that has no optimizations and no debug symbols
> > generated. I’m not sure what the motivation for those default flags
> is. If you want to default to DEBUG, something
> > like this should work:
> >
> > if (NOT CMAKE_BUILD_TYPE)
> > set(CMAKE_BUILD_TYPE Debug)
> > endif()
> >
> >
> > -MIke
> >
> > --
> >
> > Powered by www.kitware.com
> >
> > Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
> >
> >
> > Kitware offers various services to support the CMake community. For
> more information on each offering, please visit:
> >
> > CMake Support: http://cmake.org/cmake/help/support.html <
> http://cmake.org/cmake/help/support.html>
> > CMake Consulting: http://cmake.org/cmake/help/consulting.html <
> http://cmake.org/cmake/help/consulting.html>
> > CMake Training Courses: http://cmake.org/cmake/help/training.html <
> http://cmake.org/cmake/help/t
Re: [CMake] Boost is planning to switch from bjam to CMake!
Good news ! Hopefully the bcp would also work with CMake so only requires component would be installed. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] my first experiences
I always compile CMake on Linux but never meet any issues, please make sure you had installed a complete working Linux development environment, with g++, libstdc++-devel etc. The only special thing is just about enabling GUI with Qt, but that's so easy, just install the Qt development libraries though apt-get or yum, then input the parameter from configure, that's all. On Fri, Jun 9, 2017 at 5:43 PM, Eric Noulard wrote: > Hi xen, > > Sorry to hear you lost so much time. > Could you provide us with the version of your system and compiler? > Did you try any source of precompiled version of CMake either from > cmake.org or from your favorite system repo? If no why? > Average CMake user don't ever compile CMake itself. > > > > Le 9 juin 2017 09:46, "Xen" a écrit : > > I just want to tell you what terrible software CMake is. > > The newest version won't compile on my system. The bootstrapping just > won't complete. > > It hangs on 100% CPU while trying to link cmake. Maybe that is a deficit > of this system. > > I take an older version but it needs ncurses. I have ncurses on the system > but not the headers. > > The ncurses source package likes to install headers in a ncurses > subdirectory. Fine. > > But Cmake can't find it. > > I specify --prefix=/opt/local. > > The headers are in /opt/local/include/ncurses. > > At first I find a reference to CURSES_INCLUDE_PATH but setting it as an > environment variable doesn't do a thing. > > There is no help that I can find in the directory structure. > > The bootstrap command does not have any help builtin. > > I add CURSES_INCLUDE_PATH to Modules/FindCurse.cmake and it finds the > header but now offset from /ncurses. This causes the header file itself to > not find its other header files. > > The only directory it needs for that is /opt/local/include. > > I try to add CMAKE_INCLUDE_PATH on the command line. > I try to add CMAKE_C_FLAGS on the command line. > > But the build system does not tell me what it's doing. > > So I am just endlessly waiting several minutes before it errors out again > and I still don't know why or what would have helped, because it does not > show me any command lines or directories it has seen fit to use. > > This goes on for hours. > > This is the first time I have come into contact with Cmake and apparently > you need to be able to use CMake as a programmer for your own projects, > before you can get started with cmake. > > Then again it errs out: > > /store/dev/cmake/Source/CursesDialog/form/form.h:40:20: error: curses.h: > No such file or directory > > Oh, I added a colon as path separator and now it doesn't do anything > anymore. > > So my mistake was to add ncurses at the end of the path but it's not like > it should have failed using CMAKE_INCLUDE_PATH or CMAKE_C_FLAGS. > > Or even that it should not look in that location by default based on > --prefix. > > At first I couldn't compile ncurses; apparently a bug in the system. I > supplied the fix in CFLAGS but the Makefile of course did not pass it on to > the file for which it mattered, so I had to even repeat that manually. > > Luckily GNU make shows you the command line. > > It took me 3 hours to compile version 2.4.0. The latest release candidate > had been working all night and not proceeding. > > Then when I am finally done, it tells me it needs a newer version... > > Of course, it doesn't say so in the README.rst... > > I wish this endless waste of time would end. > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensou > rce/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering,
Re: [CMake] Forcing linking compatability to old libc / libstdc++ (Linux)
My personal experience is, always create the distribution on old Linux with older compiler to keep the maximal compatibility. Since usually the GCC will pick libstdc++ from system, so if user runs the distribution on even older Linux, 100% sure the error raises. On CentOS/Redhat we do have the devtool-set, but still, the older Linux + GCC are the safest solution. Or you can use the static link of libstdc++, but the size of binary will be larger, and sometimes the problem still exists, and causes more problems. On Fri, Jan 27, 2017 at 9:34 AM, Florent Castelli < florent.caste...@gmail.com> wrote: > I've had to deal with this in the past. > > For glibc, it's more tricky since when you compile on a newer > distribution, it will automatically use the newer version of some symbols. > Some functions have had breaking changes and to keep compatibility, they > kept all the different version in the binary. > But you can force the compiler to use a specific version of head but > putting that information in a header that contains the definition for all > those functions. > There is a script describe in this blog post ( > https://blogs.gnome.org/tvb/2013/12/14/application-bundles-revisited/ ) > you could use to generate a compatibility header for any target version of > glibc. > Then, you can use a force include (-include) in your favorite build system > (CMake) to have those used everywhere automatically. > If your application doesn't use any external libraries linked statically > and built against your current glibc, it should work. Otherwise, you will > probably have to rebuild them. > > For libstdc++, you could potentially statically link it, it's usually fine. > But after what I said about glibc, it means you may have to rebuild it > using the compatibility header described before. That may be tricky too... > > /Florent > > > On 26/01/2017 23:34, Michael Ellery wrote: > >> On Jan 26, 2017, at 1:45 PM, Gonzalo Garramuño >>> wrote: >>> >>> >>> >>> El 26/01/2017 a las 18:35, Michael Ellery escribió: >>> In what way is the stdlib incompatible? Does it have bugs, or is this more a matter of cpp standard support? >>> I should have been more clear. Sorry. The incompatabilities happen at >>> linker time, with complaints such as: >>> >>> exrstdattr: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found >>> (required by exrstdattr ) >>> exrstdattr: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found >>> (required by /usr/local/mrViewer/lib/libIlmImf-2_2.so.22 ) >>> >>> If I copy the latest libstdc++.so.6 I have on Ubuntu, I get: >>> >>> exrstdattr: /lib64/libc.so.6: version `GLIBC_2.18' not found (required >>> by /usr/local/mrViewer/lib/libstdc++.so.6 ) >>> >>> -- >>> Gonzalo Garramuño >>> >>> oh, yeah - I wasn’t paying close attention to the fact that you are >> distributing *binaries* — to a different distro no less. This is why >> projects often either tell users to build from source or they create >> packages (rpms, dpkgs, etc.) on the specific distros and versions. >> >> That said, if you want to distribute binaries to a different distro, I >> guess you can try static linking OR what you suggested, shipping the stdlib >> — see: >> >> http://stackoverflow.com/questions/13636513/linking-libstdc- >> statically-any-gotchas#14082540 >> >> I personally would not want to ship a stdlib myself, but using CMake’s >> RPATH support, you can probably make it work. >> >> -Mike >> >> > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensou > rce/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] (no subject)
Hi, I'm using ExternalProject_Add to handle this situation with multiple platforms/targets. https://cmake.org/cmake/help/v3.7/module/ExternalProject.html Hope this works for you. On Mon, Dec 19, 2016 at 1:41 AM, Harshal Singhal wrote: > Hello, > > I have a VS2013 project with (many sub-projects)many targets (say a b c > d) in different locations, which all are generated using CMake. I am > using one top-level CMakeLists with commadadd_subdirectoriesand a > CMakeLists file in each of those sub directories. So, Each sub-directory > has a single target. > > Now, Problem is - I want to change "Platform Toolset" only in one > (sub-directory) targets (say b) from v120 to v90. > > I have tried the following commands in my CMakeLists.txt for that > particular target (say b) but none of them seem to work: Please help > > set(CMAKE_VS_PLATFORM_TOOLSET "v90") > set(CMAKE_GENERATOR_TOOLSET "v90") > > or > > add_definitions (-DCMAKE_VS_PLATFORM_TOOLSET = "v90") > add_definitions (-DMAKE_GENERATOR_TOOLSET = "v90") > > or > > set_target_properties (b PROPERTIES PLATFORM_TOOLSET "v90") > > After trying these command - VS2013 shows the "platform toolset " as > "v120" for "b target". Maybe it is possible with command line with -T > option but I want to change the toolset for only one target not for the > whole project. Any ideas how to solve this problem? or please let me know > if it is not clear..but please help > > -- > Regards > Harshal Singhal > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Best Practise for Multiple Platforms of External Project
Hi Craig
I got a workaround for that, using FILE command to create an empty file
inside that folder, then it works. I also tried your script, because of too
many dependencies, so it takes such a long time in Configuration phase, I
will use that later in small project.
Thank you for your help.
On Wed, Dec 14, 2016 at 4:51 AM, Craig Scott
wrote:
> You could try using file(MAKE_DIRECTORY ...) between the two
> ExternalProject_Add() calls to actually ensure the directory exists, but
> I'm not 100% sure whether this would not interfere with the download step
> when it goes to do that at build time. I'm pretty sure it works, but you
> should confirm it.
>
> Another choice is to do the download at configure time rather than build
> time. This would mean the source would already be there by the time you
> reached the second ExternalProject_Add() call in your example. There are
> pros and cons to this, with the main objection being that ideally the
> configure step should be quick and making the download part of configure
> can increase the time that stage takes. For a general implementation
> supporting this functionality, have a look here:
>
> https://github.com/Crascit/DownloadProject
>
>
>
> On Wed, Dec 14, 2016 at 12:29 AM, Bo Zhou
> wrote:
>
>> Hi
>>
>> In my project I have to compile the same external projects by the
>> different generators, is that possible to handle this cases
>> by ExternalProject_Add ?
>>
>> I tried this way, firstly, just download the repository
>>
>> ExternalProject_Add(OPENEXR_DOWNLOAD
>> PREFIX ${OPENEXR_PREFIX}
>> GIT_REPOSITORY https://github.com/openexr/openexr.git
>> GIT_TAG v2.2.0
>> CONFIGURE_COMMAND ""
>> BUILD_COMMAND ""
>> INSTALL_COMMAND "")
>>
>>
>> ExternalProject_Get_Property(OPENEXR_DOWNLOAD SOURCE_DIR)
>> SET(OPENEXR_SOURCE_DIR ${SOURCE_DIR})
>>
>> Then I tried to create a specific new target to use specific generator
>>
>> ExternalProject_Add(OPENEXR_VC11
>> DEPENDS OPENEXR_DOWNLOAD
>> SOURCE_DIR ${OPENEXR_SOURCE_DIR}/IlmBase)
>>
>>
>> Seems can't work, it requires an non-empty SOURCE_DIR, but before
>> downloading, it's empty :(
>>
>> So is there any better way to do this ? Thanks very much !
>>
>>
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more
>> information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/cmake
>>
>
>
>
> --
> Craig Scott
> Melbourne, Australia
> https://crascit.com
>
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
[CMake] Best Practise for Multiple Platforms of External Project
Hi
In my project I have to compile the same external projects by the different
generators, is that possible to handle this cases by ExternalProject_Add ?
I tried this way, firstly, just download the repository
ExternalProject_Add(OPENEXR_DOWNLOAD
PREFIX ${OPENEXR_PREFIX}
GIT_REPOSITORY https://github.com/openexr/openexr.git
GIT_TAG v2.2.0
CONFIGURE_COMMAND ""
BUILD_COMMAND ""
INSTALL_COMMAND "")
ExternalProject_Get_Property(OPENEXR_DOWNLOAD SOURCE_DIR)
SET(OPENEXR_SOURCE_DIR ${SOURCE_DIR})
Then I tried to create a specific new target to use specific generator
ExternalProject_Add(OPENEXR_VC11
DEPENDS OPENEXR_DOWNLOAD
SOURCE_DIR ${OPENEXR_SOURCE_DIR}/IlmBase)
Seems can't work, it requires an non-empty SOURCE_DIR, but before
downloading, it's empty :(
So is there any better way to do this ? Thanks very much !
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
[CMake] Put bin|lib folders under Debug|Release folders
Hello all,
I am dealing with a problem about the output path. At present I just do
like this,
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY "${CMAKE_INSTALL_PREFIX}/bin")
set(CMAKE_LIBRARY_OUTPUT_DIRECTORY "${CMAKE_INSTALL_PREFIX}/lib")
And in fact the full path will be
"${CMAKE_INSTALL_PREFIX}/bin/{Debug|Release}/", the all .exe .dll .pdb
files will be generated there.
Now I have a DLL target which should be in bin/plugins, I try a way
which generates {Debug|Release} folders under the bin folder, that's
unnecessary.
I prefer a more clear output directory structure like
${CMAKE_INSTALL_PREFIX}/{Debug|Release}/bin/plugin, how should I do ?
Thanks !
--
BR,
BZ
<>___
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
