[cmake-developers] Improving OpenSSL version support
Hi, I just pushed the topic openssl-version to stage and would like someone to review it. There are 2 patches in it. The first one is an obvious bugfix and makes the version number detection work at all with OpenSSL 1.0.0! Currently the version number shown is 1.., which is fixed by the first patch. The second one adds an additional variable, OPENSSL_VERSION_STRING, like other modules also have. This variable holds the complete version number, e.g. 1.0.0f. As an additional bonus it does not parse this version from the header file if we used pkg-config to get the library location, but falls back to that if pkg-config was not used. I've tested this locally for all combinations and it works for me. I would like to hear some thought, especially about introducing the new variable. I've not touched the old one so the module does not change behavior. If noone objects I'll merge this into next at the weekend. Eike signature.asc Description: This is a digitally signed message part. -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Improving OpenSSL version support
Am Donnerstag 12 Januar 2012, 16:58:05 schrieben Sie: On 1/12/2012 3:42 PM, Rolf Eike Beer wrote: I just pushed the topic openssl-version to stage and would like someone to review it. There are 2 patches in it. The first one is an obvious bugfix and makes the version number detection work at all with OpenSSL 1.0.0! Currently the version number shown is 1.., which is fixed by the first patch. The second one adds an additional variable, OPENSSL_VERSION_STRING, like other modules also have. This variable holds the complete version number, e.g. 1.0.0f. The opensslv.h in 1.0.0 documents the version number encoding, and it looks like it changed a bit through some versions. Please add comments near the parsing code that explain how it handles this. No problem. But I'm not going to add support for things older than 0.9.6, this stuff is ancient. Also, the examples given in the header are confusing because they leave out the patch level from the string. I think the patch level can be included as a fourth component in our OPENSSL_VERSION var. Hm? * 0.9.3a 0x0090301f * 0.9.4 0x0090400f * 1.2.3z 0x102031af Eike signature.asc Description: This is a digitally signed message part. -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Improving OpenSSL version support
Am Donnerstag 12 Januar 2012, 16:58:05 schrieben Sie: On 1/12/2012 3:42 PM, Rolf Eike Beer wrote: I just pushed the topic openssl-version to stage and would like someone to review it. There are 2 patches in it. The first one is an obvious bugfix and makes the version number detection work at all with OpenSSL 1.0.0! Currently the version number shown is 1.., which is fixed by the first patch. The second one adds an additional variable, OPENSSL_VERSION_STRING, like other modules also have. This variable holds the complete version number, e.g. 1.0.0f. The opensslv.h in 1.0.0 documents the version number encoding, and it looks like it changed a bit through some versions. Please add comments near the parsing code that explain how it handles this. Done. Also, the examples given in the header are confusing because they leave out the patch level from the string. I think the patch level can be included as a fourth component in our OPENSSL_VERSION var. Or just put the normal OpenSSL version string in there? It works for VERSION_LESS and friends. And since FIND_PACKAGE() handles version selection anyway I don't see what a user should have to do with it anyway. I've pushed 2 more changes to that branch. The first one add documentation, the second one parses the version number only once and puts the result in a list and uses that elements later on. And it get's rid of some really long lines. Eike signature.asc Description: This is a digitally signed message part. -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0012873]: AUTOMOC produces same output moc file if target has two source files resides in different sub-directory
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=12873
==
Reported By:joseph2002
Assigned To:
==
Project:CMake
Issue ID: 12873
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2012-01-12 23:09 EST
Last Modified: 2012-01-12 23:09 EST
==
Summary:AUTOMOC produces same output moc file if target has
two source files resides in different sub-directory
Description:
consider following directory structure:
src
src/CMakeLists.txt
src/sub1
src/sub1/test.h
src/sub1/test.cpp
src/sub2
src/sub2/test.h
src/sub2/test.cpp
src/CMakeLists.txt:
ADD_LIBRARY( testsrc sub1/test.cpp sub2/test.cpp )
Then AUTOMOC will produce the same moc_test.cpp in the binary folder of src:
${BINARY_DIR}/src/moc_test.cpp
${BINARY_DIR}/src/testsrc_automoc.cpp Which contains two lines of #include
moc_test.cpp
This is not desired. CMake should keep directory structure when automocing, and
produces:
${BINARY_DIR}/src/sub1/moc_test.cpp
${BINARY_DIR}/src/sub2/moc_test.cpp
==
Issue History
Date ModifiedUsername FieldChange
==
2012-01-12 23:09 joseph2002 New Issue
==
--
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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] C/CXX/Fortran Compiler not found.
Hi Kedar, strange, I use both the gcc/gfortran combination and the MSVC/Ifort combination with CMake and I have no problems such as you describe. Well, at least it is working for you now. Regards, Arjen On 2012-01-11 17:06, Kedar Moharana wrote: Dear Arjen, Just by googling I found a solution on internet which suggested to install VB and Intel Fortran. I tried and now cmake is detecting the C, CXX and Fortran compiler. Thanks for the suggestion anyway. regards, Kedar On Wed, Jan 11, 2012 at 1:24 PM, Arjen Markus arjen.mar...@deltares.nl mailto:arjen.mar...@deltares.nl wrote: Hi Kedar, if CMake can find the Fortran compiler and the command gcc works from that same environment/DOS-box, then I see no particular reason why CMake should not be able to find it. Are the messages still the same (except for the Fortran part)? Note that you should start in a completely clean directory, as CMake keeps track of previous builds and build attempts via all kinds of files in that directory. They may interfere with the proper operation. Regards, Arjen On Wed, 11 Jan 2012 12:28:25 +0100 Kedar Moharana kedar.mohar...@ugent.be mailto:kedar.mohar...@ugent.be wrote: Dear Arjen, Thank you very much for the reply. Indeed, gcc command is not working on windows command prompt. As you mentioned, I tried to set the path with path=c:\MinGW\bin;%PATH% command. Now gcc is working. when I tried to build with CMAKE, it can detect the Fortran compiler; but C and CXX is not detected yet. DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. -- ** Kedar Moharana Research Scholar Laboratory for Protein Biochemistry Biomolecular Engineering (LProBE) Ghent University, 9000 Ghent, Belgium ** DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. -- 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 not to copy a link
On 01/11/2012 04:52 PM, David Cole wrote:
On Wed, Jan 11, 2012 at 10:10 AM, Michael Hertling mhertl...@online.de
wrote:
On 01/07/2012 03:52 PM, David Cole wrote:
On Sat, Jan 7, 2012 at 9:47 AM, David Cole david.c...@kitware.com wrote:
On Fri, Jan 6, 2012 at 10:54 PM, Michael Hertling mhertl...@online.de
wrote:
On 01/06/2012 07:51 PM, Kevin Burge wrote:
Thanks David. These are external libraries built outside of CMake,
without CMake, not imported via any of the import capabilities of cmake,
and that need to be installed alongside my CMake built files. I think
I'm just going to do the install with the rename. Requires me to be
more explicit, but, it's not like it changes all that frequently.
Isn't it sufficient to copy such SONAME symlinks as they are, along with
the actual library files, of course? Having a symlink from the SONAME to
the library file is a basic mean of the ABI management on platforms with
advanced - ;-) - support of shared libraries. Besides, these symlinks
are automatically created by ldconfig when the latter processes the
directory.
Anyway, w.r.t. your initial question, I'd usually suggest to use the
GET_FILENAME_COMPONENT(... REALPATH) command on the symlink prior
to the INSTALL() command, but it seems to not work as expected:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(P NONE)
SET(CMAKE_VERBOSE_MAKEFILE ON)
EXECUTE_PROCESS(COMMAND ${CMAKE_COMMAND} -E
touch xyz.dat.0)
EXECUTE_PROCESS(COMMAND ${CMAKE_COMMAND} -E
create_symlink xyz.dat.0 xyz.dat)
GET_FILENAME_COMPONENT(XYZ xyz.dat REALPATH)
MESSAGE(XYZ: ${XYZ})
Due to the documentation of GET_FILENAME_COMPONENT(... REALPATH),
... the full path with *all* symlinks resolved (REALPATH).
I'd expect to see
XYZ: .../xyz.dat.0
instead of
XYZ: .../xyz.dat
Do I misunderstand GET_FILENAME_COMPONENT() in respect thereof?
Regards,
Michael
On 01/06/12 12:45, David Cole wrote:
Have you considered setting the VERSION and SOVERSION target
properties on your libraries instead of doing the symlinks yourself?
CMake will build and install the symlinks automatically for you on
platforms where they are supported if you set these target properties.
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_tgt:SOVERSION
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_tgt:VERSION
(Or was that just an example, and you need to do this with other
symlink files that are not simply the version symlinks for a
library...?)
HTH,
David
--
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
It works if you use:
GET_FILENAME_COMPONENT(XYZ ${CMAKE_CURRENT_BINARY_DIR}/xyz.dat REALPATH)
I'm not 100% sure if the behavior is expected to be defined for
non-full paths. Hopefully Brad sees this and chimes in. If not, I'll
try to remember to ask him about it on Monday.
HTH,
David
It appears to be resolved w.r.t. the current *source* directory when
you do not give the full path, and since xyz.dat does not actually
exist in the source dir, there's no way we can know that it is
supposed to be a symlink.
But get_filename_component has to work with non-existing files since
some people need that simply to compute where files should go, or what
other file's base names should be based on CMake variables alone...
Hope that explains it better.
Yes, it does; thanks for straightening this out. Actually, it's rather
obvious that the ABSOLUTE/REALPATH clauses of GET_FILENAME_COMPONENT()
do need a reference point, but perhaps, one should document explicitly
that it's CMAKE_CURRENT_SOURCE_DIR, whereas CMAKE_CURRENT_BINARY_DIR
won't be taken into account. Elsewhere, CMake behaves differently.
Is it CMAKE_CURRENT_SOURCE_DIR? Or is it the current working directory
of the cmake process, which happens to be CMAKE_CURRENT_SOURCE_DIR
when you make the call ...?
Because of questions like these, I asked for refined documentation. ;)
AFAICS from the source code, a relative path is evaluated w.r.t. CMAKE_
CURRENT_SOURCE_DIR only. Anyway, the ABSOLUTE clause has made me think
that it is mainly meant to be used on relative paths, and if it is to
work on non-existing files, too, it needs a single reference point to
evaluate against. Actually, such facts should be mentioned in the docs
since they are essential if ABSOLUTE/REALPATH are to be used correctly.
I know it's *possible* to use non-full paths in many contexts within
CMake and still get the results you expect, but because of little
nuggets like this, ...
... I always, always, always use full paths anyway, unconditionally. [...]
With ADD_EXECUTABLE() and ADD_LIBRARY(), too? ;-) But seriously...
Yes, even with them. Exception: when I'm editing a
Re: [CMake] subject changed: question about which bugs you're talking about
Am 11.01.2012 21:25, schrieb David Cole: On Wed, Jan 11, 2012 at 3:08 PM, Alexander Neundorf a.neundorf-w...@gmx.net wrote: On Wednesday 11 January 2012, Patrick Spendrin wrote: Am 02.01.2012 18:11, schrieb David Cole: Hi all, Replies requested. Short replies only. Read on. Just a short reply with bug numbers or links to the bugs is all we need here. Please move specific discussions into the bugs themselves or start a new thread to talk about it... Replies on this thread should just be a collector for bug numbers. Example one-line reply: http://public.kitware.com/Bug/view.php?id=12647 We are aiming for quarterly releases from now on, scheduling them every 3 months. That would make the next release of CMake version 2.8.8, scheduled to have an rc1 release candidate on Wed. March 7, 2012 -- just 9 weeks from this Wednesday. If you have a particular issue that you think should be fixed for inclusion in 2.8.8, please bring it up within the next two weeks. Ideally, each issue will be discussed as needed on the mailing list to come to any consensus about what should be done to fix it, and then an entry in the bug tracker may be used to keep it on the radar screen, and to track activity related to it. You can see what's on the roadmap for this release here: http://public.kitware.com/Bug/roadmap_page.php?version_id=90 Patches are always welcome. Patches that include testing of any new features, or tests that prove a bug is really fixed on the dashboards, basically any patch with testing is preferred over a patch with no testing. Also, if you are *adding* code, then you also probably need to add *tests* of that code, so that the coverage percentage stays as is or rises. Please discuss issues here as needed, and add notes to existing issues in the bug tracker that you are interested in seeing fixed -- we will be looking at the mailing list and activity in the bug tracker to help prioritize the bug fixes that will occur in the near future. My personal issues are: http://www.cmake.org/Bug/view.php?id=10994 and connected to it: http://www.cmake.org/Bug/view.php?id=11153 The handling of the windows drive root is not consistent/wrong, which leads to both errors. I checked yesterday but the patches I added in 10994 do lead to an endless loop in 11153. I will try to come up with a better patch in the coming days. IMO these are quite important issue, since they issue causes every FooConfig.cmake file installed by any of the KDE libraries to contain extra code to work around this issue, which makes them less readable and harder to write (and easier to get wrong). Alex -- 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 Are you talking about http://www.cmake.org/Bug/view.php?id=10994 and http://www.cmake.org/Bug/view.php?id=11153 ?? How do these require extra code in your config files? I would think putting the CMakeLists file at the root of a drive would be quite uncommon. Why is the workaround mentioned in the bug insufficient? See the explanation Alex gave - the issue is not only that files are at the root of the drive, but also that if you have the root of the drive in your variable, get_filename_component behaves differently (see bug 10994 which is exactly about that). The point why subst is used is rather easy: building with mingw+mingw32-make will lead to the restriction of ~6000 chars in commandline (a restriction of the windows cmd.exe). Some packages we build (kdelibs, digikam) currently are able to hit this number of characters which makes *every* character our paths are shorter really valuable. regards, Patrick -- 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] directshow change dll name to .ax
Hi, I want to create a directshow filter (windows) and so change output name of my dll from myfilter.dll to myfilter.ax How to do this ? Thank you very much for your help regards Gilles. -- 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] directshow change dll name to .ax
On 01/12/2012 04:26 PM, gilles B wrote: Hi, I want to create a directshow filter (windows) and so change output name of my dll from myfilter.dll to myfilter.ax How to do this ? Thank you very much for your help regards Gilles. set_target_properties(myfilter PROPERTIES SUFFIX .ax) HTH Michael -- 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] User configuration files for Visual Studio
Or you could just change the properties as normal in the VS options dialog, until you find settings that work and you want to keep. Then update the cache variables or whatnot in CMake, so next time you generate you will have them. There is nothing preventing you from using the normal method of changing debug parameters. - Robert Dailey On Wed, Jan 11, 2012 at 5:53 PM, James Bigler jamesbig...@gmail.com wrote: On Wed, Jan 11, 2012 at 8:41 AM, David Cole david.c...@kitware.comwrote: I'm sure there are a handful of interested parties on this topic. One concern I would have is that if we start to generate this, we might clobber stuff that users go in and edit by hand in the Visual Studio UI. It's a minor concern, but if I do go in and add a PATH=1;2;3;4 to the environment, then I wouldn't want CMake to clobber it. I could get used to editing a CMake file or a configuration .in file for such settings though... It's a reasonable idea. I would be vehemently against any idea that would *require* me to edit any file to change debug parameters. This is an integral part of how VS should be used. The time for an iteration cycle and annoyance of this would be too high for most developers. 1. Edit paramfile 2. Configure with CMake 3. Wait for VS to recognize the file has changed or the slow slow CMake VS plugin to figure out what is going on and ask me to reload the file. 4. Run my code 5. Decide I need to change another debug parameter 6. Rinse and repeat until I decide to pull my hair out I would not be opposed for a default version of the file or the option to overwrite the existing ones, but once it has been created please leave it alone and let me configure it through the GUI. James -- 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] User configuration files for Visual Studio
I would be fine with that if the generation of these files would only happen if either they weren't present or you manually forced them to be created. Folks are just used to modifying them in the VS IDE, and it would be too easy for users to make a change in the IDE and then have CMake overwrite them on a configure. Plus the project reloading in VS is really slow. James On Thu, Jan 12, 2012 at 10:17 AM, Robert Dailey rcdai...@gmail.com wrote: Or you could just change the properties as normal in the VS options dialog, until you find settings that work and you want to keep. Then update the cache variables or whatnot in CMake, so next time you generate you will have them. There is nothing preventing you from using the normal method of changing debug parameters. - Robert Dailey On Wed, Jan 11, 2012 at 5:53 PM, James Bigler jamesbig...@gmail.comwrote: On Wed, Jan 11, 2012 at 8:41 AM, David Cole david.c...@kitware.comwrote: I'm sure there are a handful of interested parties on this topic. One concern I would have is that if we start to generate this, we might clobber stuff that users go in and edit by hand in the Visual Studio UI. It's a minor concern, but if I do go in and add a PATH=1;2;3;4 to the environment, then I wouldn't want CMake to clobber it. I could get used to editing a CMake file or a configuration .in file for such settings though... It's a reasonable idea. I would be vehemently against any idea that would *require* me to edit any file to change debug parameters. This is an integral part of how VS should be used. The time for an iteration cycle and annoyance of this would be too high for most developers. 1. Edit paramfile 2. Configure with CMake 3. Wait for VS to recognize the file has changed or the slow slow CMake VS plugin to figure out what is going on and ask me to reload the file. 4. Run my code 5. Decide I need to change another debug parameter 6. Rinse and repeat until I decide to pull my hair out I would not be opposed for a default version of the file or the option to overwrite the existing ones, but once it has been created please leave it alone and let me configure it through the GUI. James -- 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] linker doesnt find shared library
Hello, i have a library libpnt.so under /usr/local/lib/pnt. I've added a pnt.conf with this path under /etc/ld.so.conf.d/ and execute ldconfig ldconfig -v | grep libpnt.so finds the library: libpnt.so.0 - libpnt.so.0.8.1 In the CMakeList.txt i try to link against the target: TARGET_LINK_LIBRARIES(profil pnt ...) But the linker returns: cannot find -lpnt. When the library is saved under /usr/local/lib, everything works fine... Any suggestions? Kind Regards Thorsten Wagner -- 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] linker doesnt find shared library
Thorsten Wagner wrote: Hello, i have a library libpnt.so under /usr/local/lib/pnt. I've added a pnt.conf with this path under /etc/ld.so.conf.d/ and execute ldconfig ldconfig -v | grep libpnt.so finds the library: libpnt.so.0 - libpnt.so.0.8.1 In the CMakeList.txt i try to link against the target: TARGET_LINK_LIBRARIES(profil pnt ...) But the linker returns: cannot find -lpnt. When the library is saved under /usr/local/lib, everything works fine... Any suggestions? TARGET_LINK_LIBRARIES(profil /usr/local/lib/pnt/libpnt.so) What's in ld.so.conf is for the dynamic linker on program execution, it has nothing to do with the paths used by the linker that creates the program. Just use the absolute paths to the libraries you want to link. Or use FIND_LIBRARY() to get this path, which will return an absolute path and looks in some default places for you. Eike -- 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] Custom configuration types in Visual Studio
I see there is documentation for this but it doesn't have an implementation for VS generators: http://www.cmake.org/Bug/view.php?id=5811 Any status updates on this bug? I'd like to be able to create my own debug configuration called DebugStatic that uses the /MTd flag in all projects to link statically against the Microsoft libraries such as CRT. Any help? - Robert Dailey -- 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] FindPythonLibs : Version selection on OS X
Hi, Using the FindPythonLibs macros on OS X Lion always returns the standard Python 2.7 (shipped with Lion) There are other versions of Python which is also available in OS X Lion. Is it possible to inform FindPythonLibs to look for a different version of Python e.g. 2.6, if so, how does one go about doing that ? Regards -- Nicholas Yue Graphics - RenderMan, Houdini, Visualization, OpenGL, HDF5 Custom Dev - C++ porting, OSX, Linux, Windows http://au.linkedin.com/in/nicholasyue -- 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] FindPythonLibs : Version selection on OS X
On 13.01.12 15:33:23, Nicholas Yue wrote: Hi, Using the FindPythonLibs macros on OS X Lion always returns the standard Python 2.7 (shipped with Lion) There are other versions of Python which is also available in OS X Lion. Is it possible to inform FindPythonLibs to look for a different version of Python e.g. 2.6, if so, how does one go about doing that ? In the same way as you influence any other Find-Module that uses find_library/find_executable and find_file: Set CMAKE_PREFIX_PATH to a prefix where the wanted software version is installed. Andreas -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[Cmake-commits] CMake branch, next, updated. v2.8.7-2078-g317fc87
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 317fc87718745b28c78df1852b2b04c7b0800544 (commit)
via 9cc19b2de2e8077424b89d8f7e8520fe074deffb (commit)
via 7a933f8c5c7a7f92be3d7a6881b107a4246bfed6 (commit)
via bbed901178852e1fb1a77e4e6fbfe397fb67a20c (commit)
from c805ff8fc46679487055949ebef98d525b6725bc (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=317fc87718745b28c78df1852b2b04c7b0800544
commit 317fc87718745b28c78df1852b2b04c7b0800544
Merge: c805ff8 9cc19b2
Author: Brad King brad.k...@kitware.com
AuthorDate: Thu Jan 12 10:32:45 2012 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Thu Jan 12 10:32:45 2012 -0500
Merge topic 'link-shared-depend-cycle-issue-12647' into next
9cc19b2 Tolerate cycles in shared library link interfaces (#12647)
7a933f8 Add infrastructure for CMake-only tests
bbed901 KWSys Nightly Date Stamp
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9cc19b2de2e8077424b89d8f7e8520fe074deffb
commit 9cc19b2de2e8077424b89d8f7e8520fe074deffb
Author: Brad King brad.k...@kitware.com
AuthorDate: Thu Jan 12 10:22:00 2012 -0500
Commit: Brad King brad.k...@kitware.com
CommitDate: Thu Jan 12 10:22:00 2012 -0500
Tolerate cycles in shared library link interfaces (#12647)
Since commit 183b9509 (Follow all dependencies of shared library private
dependencies, 2011-12-14) we honor LINK_INTERFACE_LIBRARIES when
following dependent shared libraries. The link interface properties may
form a cycle if set incorrectly by a project. Furthermore, the property
LINK_DEPENDENT_LIBRARIES may form a cycle if set incorrectly by hand
(though CMake should never generate one). In either case, do not follow
the cycle forever when following the dependent shared library closure.
We only need to add dependency edges to the constraint graph once.
Add LinkInterfaceLoop test to cover this case.
diff --git a/Source/cmComputeLinkDepends.cxx b/Source/cmComputeLinkDepends.cxx
index 802cfcf..9a075bd 100644
--- a/Source/cmComputeLinkDepends.cxx
+++ b/Source/cmComputeLinkDepends.cxx
@@ -358,7 +358,7 @@ void cmComputeLinkDepends::FollowLinkEntry(BFSEntry const
qe)
this-AddLinkEntries(depender_index, iface-Libraries);
// Handle dependent shared libraries.
- this-QueueSharedDependencies(depender_index, iface-SharedDeps);
+ this-FollowSharedDeps(depender_index, iface);
// Support for CMP0003.
for(std::vectorstd::string::const_iterator
@@ -379,6 +379,23 @@ void cmComputeLinkDepends::FollowLinkEntry(BFSEntry const
qe)
//
void
cmComputeLinkDepends
+::FollowSharedDeps(int depender_index, cmTarget::LinkInterface const* iface,
+ bool follow_interface)
+{
+ // Follow dependencies if we have not followed them already.
+ if(this-SharedDepFollowed.insert(depender_index).second)
+{
+if(follow_interface)
+ {
+ this-QueueSharedDependencies(depender_index, iface-Libraries);
+ }
+this-QueueSharedDependencies(depender_index, iface-SharedDeps);
+}
+}
+
+//
+void
+cmComputeLinkDepends
::QueueSharedDependencies(int depender_index,
std::vectorstd::string const deps)
{
@@ -430,8 +447,7 @@ void
cmComputeLinkDepends::HandleSharedDependency(SharedDepEntry const dep)
entry.Target-GetLinkInterface(this-Config))
{
// Follow public and private dependencies transitively.
- this-QueueSharedDependencies(index, iface-Libraries);
- this-QueueSharedDependencies(index, iface-SharedDeps);
+ this-FollowSharedDeps(index, iface, true);
}
}
}
diff --git a/Source/cmComputeLinkDepends.h b/Source/cmComputeLinkDepends.h
index e196e00..80a0454 100644
--- a/Source/cmComputeLinkDepends.h
+++ b/Source/cmComputeLinkDepends.h
@@ -105,6 +105,10 @@ private:
int DependerIndex;
};
std::queueSharedDepEntry SharedDepQueue;
+ std::setint SharedDepFollowed;
+ void FollowSharedDeps(int depender_index,
+cmTarget::LinkInterface const* iface,
+bool follow_interface = false);
void QueueSharedDependencies(int depender_index,
std::vectorstd::string const deps);
void HandleSharedDependency(SharedDepEntry const dep);
diff --git a/Tests/CMakeOnly/CMakeLists.txt b/Tests/CMakeOnly/CMakeLists.txt
index f8babbf..b3bdab8 100644
---
[Cmake-commits] CMake branch, master, updated. v2.8.7-94-g50edbf0
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via 50edbf0f224e81cb85a0588d2495676efc3101f2 (commit) from c89ee4a10f4de32bdffaa1f08f5455f0fc454731 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=50edbf0f224e81cb85a0588d2495676efc3101f2 commit 50edbf0f224e81cb85a0588d2495676efc3101f2 Author: KWSys Robot kwro...@kitware.com AuthorDate: Fri Jan 13 00:05:04 2012 -0500 Commit: KWSys Robot kwro...@kitware.com CommitDate: Fri Jan 13 00:05:04 2012 -0500 KWSys Nightly Date Stamp diff --git a/Source/kwsys/kwsysDateStamp.cmake b/Source/kwsys/kwsysDateStamp.cmake index 1106367..39d8a79 100644 --- a/Source/kwsys/kwsysDateStamp.cmake +++ b/Source/kwsys/kwsysDateStamp.cmake @@ -18,4 +18,4 @@ SET(KWSYS_DATE_STAMP_YEAR 2012) SET(KWSYS_DATE_STAMP_MONTH 01) # KWSys version date day component. Format is DD. -SET(KWSYS_DATE_STAMP_DAY 12) +SET(KWSYS_DATE_STAMP_DAY 13) --- Summary of changes: Source/kwsys/kwsysDateStamp.cmake |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
