Re: [CMake] VERBOSE environment variable
On 5 February 2014 08:25, hjuvi wrote: > Hello, > > I can't find the description of VERBOSE environment variable effect on > compilation. > Experiment has shown me that: > - exporting VERBOSE (without setting the value), implies that "Dependee ... > is newer than depender ..." messages are shown > - exporting VERBOSE=1 (or whatever the value, even 0 in fact!) implies that > all compilation commands are shown > > Can you confirm this behaviour? Is it the expected behaviour? > Shouldn't it be documented here? > http://www.cmake.org/cmake/help/v2.8.12/cmake.html > > I find it disturbing that exporting the variable (without setting the value) > turns on some verbose messages. > And even more disturbing that VERBOSE=0 turns on verbose mode as well as > VERBOSE=1. http://www.cmake.org/Bug/view.php?id=3378 Best regards, -- Mateusz Łoskot, http://mateusz.loskot.net -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Announcing CMake BASIS, a set of CMake based project interoperability and automation tools
On 21 January 2014 19:49, Andrew Hundt wrote: > CMake BASIS is a set of utilities and standards created with the goal of > making CMake projects and libraries very easy to create, share, and reuse. > It also integrates a lot of useful new CMake functionality such as > documentation tools and automated packaging that a CMake user would > otherwise have to implement themselves. > > Website: http://opensource.andreasschuh.com/cmake-basis/index.html > GitHub: https://github.com/schuhschuh/cmake-basis/ > [...] Andrew, this looks very interesting. I have been very slowly growing something with similar, though much more limited, capabilities for one of projects I use (I'm tired of writing the same boilerplate :-)) If I have moment, I'd like to check BASIS out in practice. I quickly skimmed through the docs and I have question about the Source Code Filesystem Heirarchy. It is fairly common to have /include folder, so the structure looks like - / + src/ + include/ + config/ ... where all public headers live. Is such layout supported by BASIS? I see the minimum version of CMake is 2.8.4. Does it mean BASIS does not support/use the Object Libraries feature? Best regards, -- Mateusz Łoskot, http://mateusz.loskot.net -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Adding CMAKE_BUILD_TYPE support to ProjectConfig.cmake
On 19 December 2013 12:41, Fabian Saccilotto wrote: > Hi Mateusz, > > we are developing with Visual Studio and therefore have such a > multi-configuration setup. I would like to describe how the process works on > our system, maybe that helps... > [...] Hi Fabian, Thanks very much for sharing your experience on this topic. I'll experiment with your solution. Thanks, -- Mateusz Łoskot, http://mateusz.loskot.net -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Compile project as C++ if MSVC
On 23 December 2011 15:07, Bill Hoffman wrote: > Back to the original question, just to be clear. > > The right way to do this is with the set_source_files_properties command: > > set_source_files_properties( PROPERTIES LANGUAGE CXX) Thanks Bill. It is always good to learn new things about favourite build toolset :) Best regards, -- Mateusz Loskot, http://mateusz.loskot.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] Compile project as C++ if MSVC
2011/12/23 Pau Garcia i Quiles : > 2011/12/23 Mateusz Łoskot : >>>>> For now, the usual work-around is to build the project as C++. >>>> >>>> If a certain feature from C99 is not supported by Visual C++, >>>> how it is supposed to be workaround? >>> >>> Many C99 features were already supported by standard C++ and/or Visual >>> C++-specific features: mixing declarations and code, snprintf, inline >>> functions, more data types, etc >> >> No. >> >> All the features you listed above are C++ standard features, including >> snprintf which is C++11 feature introduced as part of C99 compatibility. > > That's exactly why the workaround is to compile the C project as C++ > to get the C99 features that are both in C99 and in C++. Gotcha. Visual C++ compiles as C++ by default, unless you specify /TC option. Best regards, -- Mateusz Loskot, http://mateusz.loskot.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] Compile project as C++ if MSVC
2011/12/23 Mateusz Łoskot : > Thus, _snprintf (not snprintf, in pre-Visual Studio 11) is > Microsoft-specific feature I missed to add link related to this: http://msdn.microsoft.com/en-us/library/45aft37a.aspx Best regards, -- Mateusz Loskot, http://mateusz.loskot.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] Compile project as C++ if MSVC
2011/12/23 Pau Garcia i Quiles : > 2011/12/23 Mateusz Łoskot : > >>> For now, the usual work-around is to build the project as C++. >> >> If a certain feature from C99 is not supported by Visual C++, >> how it is supposed to be workaround? > > Many C99 features were already supported by standard C++ and/or Visual > C++-specific features: mixing declarations and code, snprintf, inline > functions, more data types, etc No. All the features you listed above are C++ standard features, including snprintf which is C++11 feature introduced as part of C99 compatibility. There are *no* C99 features available in Visual C++, other than those defined by C++11. However, there are Microsoft-specific features in Visual C++ which only look & feel like C99 but they are not claimed or documented as they supposed to be considered as C99. Thus, _snprintf (not snprintf, in pre-Visual Studio 11) is Microsoft-specific feature, *not* C99. In Visual Studio 11 it is snprintf, which is C++11 feature. Regarding C language, there is *no* support of plain/core C99, other than that from C++11 and future revisions. It has been clearly stated by Microsoft many times. It is just people seem to be confused or just don't want to understand it (and then complain). [1] http://connect.microsoft.com/VisualStudio/feedback/details/531634/support-iso-c99-standard Best regards, -- Mateusz Loskot, http://mateusz.loskot.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] Compile project as C++ if MSVC
On 23 December 2011 01:28, Pau Garcia i Quiles wrote: > > Visual C++ 2010 does not support C99 yet and it seems it will be a > long time before MSVC supports it. AFAIK, Microsoft does not plan to support C99. Visual C++ will support as much C99 as imported in to most recent C++11 as Microsoft aims to fully support C++11 and future revisions. > For now, the usual work-around is to build the project as C++. If a certain feature from C99 is not supported by Visual C++, how it is supposed to be workaround? Best regards, -- Mateusz Loskot, http://mateusz.loskot.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] Documentation request
On 21 December 2011 18:10, Renato Utsch wrote: > Yes, exactly, the way it is now is not obvious, but it should be. > > I indeed thought that CMake 2.8 documentation was for 2.8.*, but I > discovered this week that it wasn't. And I'm sure that this happens > with A LOT of people. As a matter of fact, it happened to me several times until I've learned the lesson. "Manual version vs CMake version" http://www.cmake.org/pipermail/cmake/2010-February/035006.html IMHO, the choice is binary: either docs are versioned (see Python) or only docs for most recent release are displayed but titled with full version number X.Y.Z. Best regards -- Mateusz Loskot, http://mateusz.loskot.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] Problem linking boost program_options with Visual Studio 2008
2011/12/13 Mario Pezzoni : > I read this one before but, it is related with dynamic linking, i need > static linking. > This solution do not works with static linking. You don't mention in your post how you link. Also, your CMakeLists.txt suggests you link default means dynamically on Windows. Try adding Boost_USE_STATIC_LIBS (learn about it from FindBoost.cmake file in your CMake installed modules). Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org -- 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] Problem linking boost program_options with Visual Studio 2008
On 13 December 2011 12:57, Mario Pezzoni wrote: > Hi all, > > i have a project in c++ that needs program_options library from boost, i use > FindBoost to set include dirs and linking stuff. > Compiling and linking works flawlessly under linux. With the visual studio > project compiling go well but linking fails with this error message: > > 1>pro_cli.obj : error LNK2001: unresolved external symbol "public: static > unsigned int const > boost::program_options::options_description::m_default_line_length" > (?m_default_line_length@options_description@program_options@boost@@2IB) If you feed big G with this part of error message...first link in the results http://lists.boost.org/boost-users/2009/11/54015.php Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org -- 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] How to preserve directory structure within Visual Studio
2011/12/9 David Cole :
> 2011/12/8 Mateusz Łoskot :
>> 2011/12/8 David Cole :
>>> 2011/12/8 Mateusz Łoskot :
>>>> On 8 December 2011 21:45, David Cole wrote:
>>>>> No, the FOLDER property is only a mechanism for grouping and
>>>>> organizing *targets*, it is not a source file property...
>>>>
>>>> Is it the source_group still the recommended way of grouping?
>>>
>>> Yes, the source_group command should be able to handle this. Try it
>>> with "\\" and "/" separators, I can't remember which character is used
>>> to split on for sub-folders within the project file. (Maybe either
>>> works...?)
>>
>>
>> The issue I have always suffered is that search_group (or related parties)
>> ignores source files (any specified) if they are not used in the targets.
>>
>> Here is illustration from one of my C++ headers-only pet projects:
>>
>> 1) I need to collect and structure all headers I want to have listed in
>> Solution Explorer in Visual Studio:
>> https://github.com/mloskot/boost-gil-workshop/blob/master/CMakeLists.txt
>>
>> file(GLOB GIL_HPP "${GIL_DIR}/*.hpp")
>> file(GLOB GIL_EXT_IO_HPP "${GIL_EXT_IO_DIR}/*.hpp")
>> file(GLOB GIL_EXT_IO_DETAIL_HPP "${GIL_EXT_IO_DIR}/detail/*.hpp")
>>
>> # Make single list with all headers for convenience in 2)
>> if(MSVC)
>> list(APPEND GIL_ALL_HPP ${GIL_HPP})
>> list(APPEND GIL_ALL_HPP ${GIL_EXT_IO_HPP})
>> list(APPEND GIL_ALL_HPP ${GIL_EXT_IO_DETAIL_HPP})
>> endif()
>>
>> 2) Indicate the headers are used source files:
>>
>> add_executable(gil_pnm_test gil_pnm_test.cpp ${GIL_ALL_HPP})
>>
>> 3) Assign headers to groups:
>>
>> https://github.com/mloskot/boost-gil-workshop/blob/master/test/CMakeLists.txt
>>
>> source_group("Header Files\\gil" FILES ${GIL_HPP})
>> source_group("Header Files\\gil\\extension\\io_new" FILES ${GIL_EXT_IO_HPP})
>> source_group("Header Files\\gil\\extension\\io_new\\detail" FILES
>> ${GIL_EXT_IO_DETAIL_HPP})
>>
>> Has anything changed to make the procedure easier?
>
>
> Not that I'm aware of -- this looks quite reasonable to me.
I'm glad to have it confirmed. Thanks.
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
Member of ACCU, http://accu.org
--
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] How to preserve directory structure within Visual Studio
2011/12/8 David Cole :
> 2011/12/8 Mateusz Łoskot :
>> On 8 December 2011 21:45, David Cole wrote:
>>> No, the FOLDER property is only a mechanism for grouping and
>>> organizing *targets*, it is not a source file property...
>>
>> Is it the source_group still the recommended way of grouping?
>
> Yes, the source_group command should be able to handle this. Try it
> with "\\" and "/" separators, I can't remember which character is used
> to split on for sub-folders within the project file. (Maybe either
> works...?)
The issue I have always suffered is that search_group (or related parties)
ignores source files (any specified) if they are not used in the targets.
Here is illustration from one of my C++ headers-only pet projects:
1) I need to collect and structure all headers I want to have listed in
Solution Explorer in Visual Studio:
https://github.com/mloskot/boost-gil-workshop/blob/master/CMakeLists.txt
file(GLOB GIL_HPP "${GIL_DIR}/*.hpp")
file(GLOB GIL_EXT_IO_HPP "${GIL_EXT_IO_DIR}/*.hpp")
file(GLOB GIL_EXT_IO_DETAIL_HPP "${GIL_EXT_IO_DIR}/detail/*.hpp")
# Make single list with all headers for convenience in 2)
if(MSVC)
list(APPEND GIL_ALL_HPP ${GIL_HPP})
list(APPEND GIL_ALL_HPP ${GIL_EXT_IO_HPP})
list(APPEND GIL_ALL_HPP ${GIL_EXT_IO_DETAIL_HPP})
endif()
2) Indicate the headers are used source files:
add_executable(gil_pnm_test gil_pnm_test.cpp ${GIL_ALL_HPP})
3) Assign headers to groups:
https://github.com/mloskot/boost-gil-workshop/blob/master/test/CMakeLists.txt
source_group("Header Files\\gil" FILES ${GIL_HPP})
source_group("Header Files\\gil\\extension\\io_new" FILES ${GIL_EXT_IO_HPP})
source_group("Header Files\\gil\\extension\\io_new\\detail" FILES
${GIL_EXT_IO_DETAIL_HPP})
Has anything changed to make the procedure easier?
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.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] How to preserve directory structure within Visual Studio
On 8 December 2011 21:45, David Cole wrote: > No, the FOLDER property is only a mechanism for grouping and > organizing *targets*, it is not a source file property... Is it the source_group still the recommended way of grouping? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org -- 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] hear hear
On 6 December 2011 17:19, Alexander Neundorf wrote: > On Tuesday 06 December 2011, Mateusz Łoskot wrote: >> On 6 December 2011 16:27, Daniel Dekkers wrote: >> > On Dec 4, 2011, at 11:59 AM, Michael Jackson wrote: >> >> I think if the CMake community took a vote we could probably come up >> >> with an "Exemplar" Find*.cmake file that is good for someone trying to >> >> develop a new one. >> > >> > Yes please. >> > And I think in general that is true. Of course it is more interesting and >> > often more urgent to spend time on "exotic" problems. But there are >> > these basics that are missing in the documentation. >> >> It's a great idea and I've been suggesting and looking for best >> practices for long time: >> >> http://www.cmake.org/pipermail/cmake/2010-March/035596.html >> >> I'd add also: >> >> Find*.cmake modules should be documented separately (separate >> chapters/pages) from the main documentation. The current documentation is >> already very long and navigating it has become difficult. > > Do you mean the book or the man/html pages ? I meant the Web version: http://cmake.org/cmake/help/cmake-2-8-docs.html But, it turns I'm wrong, as the HTML version installed with CMake is well organised. For example, on Windows users get: %ProgramFiles%/CMake 2.8/doc/cmake-2.8/cmake-modules.html False complain, apologies. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org -- 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] hear hear
On 6 December 2011 16:27, Daniel Dekkers wrote: > On Dec 4, 2011, at 11:59 AM, Michael Jackson wrote: >> I think if the CMake community took a vote we could probably come up with an >> "Exemplar" >> Find*.cmake file that is good for someone trying to develop a new one. > > Yes please. > And I think in general that is true. Of course it is more interesting and > often more > urgent to spend time on "exotic" problems. But there are these basics that > are missing in the documentation. It's a great idea and I've been suggesting and looking for best practices for long time: http://www.cmake.org/pipermail/cmake/2010-March/035596.html I'd add also: Find*.cmake modules should be documented separately (separate chapters/pages) from the main documentation. The current documentation is already very long and navigating it has become difficult. Adding guidelines for Find*.cmake modules will make it close to impossible to use. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org -- 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] Friday
Folks, I sincerely apologies. It wasn't supposed to go to *C*Make list but to a friend whose name starts with *C* :) Please, ignore. Regards, Mat 2011/12/1 Mateusz Łoskot : > Hi Chiara, > > Let's do climbing on Friday. You still up for that? > > Ciao, > Mateo -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org -- 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] Friday
Hi Chiara, Let's do climbing on Friday. You still up for that? Ciao, Mateo -- 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] Visual Studio 2010 generator: Linking static libraries to one dll problem (Use Library Dependency Inputs)
On 17 November 2011 16:30, Matthias Wieding-Drewes wrote: > > I'am currently in the process of converting a Visual Studio 2010 project > to CMake. There are three (sub) projects each of which results in a > staticaly linked library. This libraries are then combined into a > single .dll file. > > Well actually that's how it should be (and is set up in CMake). > > The .dll does not contain any symbols since VS 2010 does not realy read > the static libraries. You may want to learn it is a bad idea to link N static libraries into single shared, especially on Windows: http://www.cmake.org/pipermail/cmake/2010-November/040869.html Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org -- 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] Problem with LINK_DIRECTORIES
On 14 November 2011 17:17, Robert Dailey wrote: > So basically all third party libraries we use are not installed > individually, instead we have a server on our intranet that contains > precompiled versions of all libraries in a specific and consistent > hierarchy. For this reason, it doesn't make sense to use find_library(), > which would normally always give you absolute paths to your library files > and thus link_directories() would not be needed. A typical Linux user can say the same: I have all my libraries in /usr/lib so it does not make sense to use find_library. No point arguing if it would make sense or not. Simply, find_library is a unified convention used by CMake, it works regardless user-specific filesystem structure. Simply, it would not hurt to use find_library(). Then, you can follow the CMake convention, without a need of custom scripts, etc. > I pass each one of these to target_link_libraries() and I leave it up to the > compiler to search for where to find the file in the provided link > directories. IMO, you don't buy anything with this customisation. Either CMake finds library and tells compiler "look, it's here" or CMake + custom script approximates library location and lets linker to find it. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org -- 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_RUNTIME_OUTPUT_DIRECTORY best practice for Windows and Visual Studio
On 13 November 2011 19:51, Niels Dekker - address until 2014
wrote:
> Mateusz Loskot wrote:
>> On Windows, I use Visual Studio for development, so I have
>> CMake-generated .sln with projects. loaded into the IDE. I build.
>> Then, I'd like to run one of executables (e.g. test.exe) which links against
>> the DLLs also
>> built by the project. Obviously, it is necessary to deal with the run-time
>> search path.
>>
>> At the moment, I simplify things by outputting all .exe and .dll
>> binaries to common directory, so programs can find required DLLs:
>>
>> set(MYPRJOUTDIR ${PROJECT_BINARY_DIR}/bin/${CMAKE_BUILD_TYPE})
>> set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${MYPRJOUTDIR})
>
> On Windows, it looks fine to me to have all the DLL's built by the project
> together with the executable that links against them, in one and the same
> CMAKE_RUNTIME_OUTPUT_DIRECTORY.
Good, I'm glad it's nothing weird neither wrong in this approach.
> The alternative of setting the PATH looks
> less reliable to me, because the PATH may easily be overruled by other
> locations (current directory, system directory or Windows directory),
> depending on that rather complicated "Dynamic-Link Library Search Order"
> thing, http://msdn.microsoft.com/en-us/site/ms682586 And eventually I guess
> you don't want your application to depend on the PATH at the end user machine.
Yes, you are right.
I have some projects configured in such way they try to generate
.vcproj.user file
which defines PATH with pointers to location of run-time dependencies.
For example: https://github.com/libLAS/libLAS/tree/master/cmake
> However, I haven't yet tried to build an "isolated application"
> according to your reference [3]
> (http://msdn.microsoft.com/en-us/library/aa375190%28VS.85%29.aspx).
> Would you recommend doing so?
Niels, I haven't tried it myself neither. I don't have experience with
this technique,
so I can't say if it is recommended.
Actually, I hoped to receive a related piece of advice here, from CMake users.
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
Member of ACCU, http://accu.org
--
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] Workflow of a collaborative project in Visual Studio+CMake
On 12 November 2011 12:39, David Cole wrote: > For reference, the bug Mike refers to is this one: > > http://public.kitware.com/Bug/view.php?id=11258 > > I always use the manual technique of shutting down VS, running CMake, > and then re-opening VS. It's really not that bad, once you get used to it. Actually, there is no need to completely shut down VS. File -> Close Solution or quick keyboard shortcut/accelerators use: Alt + F -> t then run cmake then File -> Recent Projects -> reopen yours or quick shortcut Alt + F -> j -> 1 Using keyboard makes this operation unnoticeable effort. Best regards, -- Mateusz Loskot, http://mateusz.loskot.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
[CMake] CMAKE_RUNTIME_OUTPUT_DIRECTORY best practice for Windows and Visual Studio
Hi,
I have a CMake-based project which builds several shared libraries and
executables.
There are various run-time dependencies between those shared libraries
and executables.
On Windows, I use Visual Studio for development, so I have CMake-generated .sln
with projects. loaded into the IDE. I build. Then, I'd like to run one
of executables
(e.g. test.exe) which links against the DLLs also built by the project.
Obviously, it is necessary to deal with the run-time search path.
At the moment, I simplify things by outputting all .exe and .dll
binaries to common directory, so programs can find required DLLs:
set(MYPRJOUTDIR ${PROJECT_BINARY_DIR}/bin/${CMAKE_BUILD_TYPE})
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${MYPRJOUTDIR})
This is also required to launch such executables under debugger.
However, I have heard opinions it is some kind of a hack unnatural to CMake.
On Linux, I do the same, but I imagine I could make use of rpath [1]
as CMake provides some degree of support in this area [2].
On Windows, there is no such concept as rpath. Isolated Applications [3]
seems to be the closest idea available there.
Is it a good idea to have all-in-one CMAKE_RUNTIME_OUTPUT_DIRECTORY?
Is there any CMake best practice for dealing with run-time search path
on Windows?
For example, automatically setting PATH in project
-> Configuration Properties -> Debugging -> Environment.
[1] http://en.wikipedia.org/wiki/Rpath
[2] http://www.vtk.org/Wiki/CMake_RPATH_handling
[3] http://msdn.microsoft.com/en-us/library/aa375190%28VS.85%29.aspx
--
Mateusz Loskot, http://mateusz.loskot.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] VS2010 Express generator?
On 11 November 2011 16:36, David Doria wrote: > I am using CMake 2.8.6 and am hoping to generate a project for VS2010 > Express. Which generator should I use? I tried Visual Studio 10, but > when I "configure" I get all kinds of errors about the compiler not > working. I can try to transcribe these if necessary, but I thought > there might be an easier answer first. Are you sure these errors are related to CMake issues? Your report would be clearer if you added the actual errors. VS2010 EE support should be sound in 2.8.6 It has been in upstream way before 2.8.6 release. http://www.cmake.org/pipermail/cmake/2010-May/036900.html Best regards, -- Mateusz Loskot, http://mateusz.loskot.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] Visual Studio 10 property pages for single source file gone with CMake 2.8.5 and 2.8.6
On 11 November 2011 13:54, Niels Dekker - address until 2014 wrote: >>> Update: I think users can work around this issue (#12570, empty >>> property pages in VS10), by having the directory where to build the >>> binaries on a separate drive (different from the drive that has the >>> source files). > > Mateusz Loskot wrote: >> >> Separate drive may not be an option for some/many. >> I, for instance, don't use partitions, but I use >> CMakeas as main builder for my projects. > > In order to work around http://public.kitware.com/Bug/view.php?id=12570 I > think it should be sufficient to have a different drive *letter* when > specifying where to build the binaries than the drive letter(s) of the path > names of the source files. So I guess one might work around this issue by > mapping a new drive letter to the build/bin directory, even while this > directory might be located at the same physical drive as the source files. > Right? I guess it's feasible. I'll try this approach when I have a free moment. Thanks. Best regards, -- Mateusz Loskot, http://mateusz.loskot.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] Visual Studio 10 property pages for single source file gone with CMake 2.8.5 and 2.8.6
Separate drive may not be an option for some/many. I, for instance, don't use partitions, but I use CMakeas as main builder for my projects. So, I feel the pain of reloading, thus It's easier/quicker for me to close solution, rerun CMake, reopen solution. -- Mateusz Łoskot Sent from my mobile (excuse me for not quoting or top-posting possible) -- 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 download page seems missing
Hi, It seems CMake download is broken or missing. I want to get latest CMake for Windows, so I do: 1) Load http://cmake.org/ 2) Navigate to Resources -> Download which leads to: http://cmake.org/cmake/resources/software.html 3) Click linked cmake-2.8.6-win32-x86.exe 4) I get HTML page with Kitware projects listed and URL bar shows: http://www.cmake.org/files/v2.8/cmake-2.8.6-win32-x86.exe I checked different browsers, so it doesn't seem as mime/file type issues in browsers. Is there indeed a problem with downloads? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org -- 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
