[cmake-developers] [CMake 0013446]: find_package(Boost) does not map library paths correctly
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13446 == Reported By:kdawgud Assigned To: == Project:CMake Issue ID: 13446 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2012-07-31 11:25 EDT Last Modified: 2012-07-31 11:25 EDT == Summary:find_package(Boost) does not map library paths correctly Description: The boost library find places libraries in /usr/lib64/lib64 instead of just /usr/lib64. Reverting to 2.8.3 fixes the problem. I have not tried verions 2.8.4 through 2.8.7. Steps to Reproduce: Link against boost libraries using find_package(Boost) in a CMake project using CentOS 64-bit. Additional Information: See here for more information: http://stackoverflow.com/questions/9948375/cmake-find-package-succeeds-but-returns-wrong-path == Issue History Date ModifiedUsername FieldChange == 2012-07-31 11:25 kdawgudNew 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-developers] find_package without REQUIRED can cause fatal error now
On 7/30/2012 3:38 PM, Alexander Neundorf wrote: The idea was that this is a sign of a broken install. Can you uninstall the vtk-devel package (does this exist ?), because it is broken, i.e. does not contain everything is claims to ? I understand that this is maybe not expected behaviour for an optional package, but maybe Brad is right ? Alex Yes, VTK is broken on the machine, and we could fix the machine. However, this would be the first time we did a work around for the modules test by fixing the machine. I wonder if we could just disable fatal error at the start of find_package optional. Then turn it back on at the end. My concern is optional packages, maybe that is a rare case not sure. -- Bill Hoffman Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 bill.hoff...@kitware.com http://www.kitware.com 518 881-4905 (Direct) 518 371-3971 x105 Fax (518) 371-4573 -- 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] SelectLibraryConfigurations
Hi, I just did a git grep optimized Modules/Find* to search for any modules that add the optimized and debug keywords by hand. We have a module for that: SelectLibraryConfigurations.cmake. This has the advantage of e.g. taking care for the case that only one of the debug and release library types were found, the generator does not support different configurations or simply both libraries being identical. Also the library variables are automatically marked as advanced. When my latest patch gets merged it will also take care of the case when it's not just a library, but a list of libraries to link to. Anyway, these are the modules that currently do the handling themselves. I would welcome if they would either switch to SelectLibraryConfigurations or tell me what stops them from doing so. One thing is that currently the macro automatically sets a _FOUND variable which may collide with FPHSA. Maybe we want to introduce a variant of the macro that does not do that. I remember that at least in one module I explicitely unset the _FOUND variable later to avoid that collision. -Boost -Bullet -Coin3D -GTK2 -GTest -HDF5 -OpenSSL -OpenThreads -Protobuf -Qt4 -osg_functions -wxWidgets -wxWindows Greetings, 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 0013447]: Symlinks unsupported by some filesystems (e.g: CIFS)
The following issue has been SUBMITTED.
==
http://cmake.org/Bug/view.php?id=13447
==
Reported By:Declan White
Assigned To:
==
Project:CMake
Issue ID: 13447
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2012-07-31 13:47 EDT
Last Modified: 2012-07-31 13:47 EDT
==
Summary:Symlinks unsupported by some filesystems (e.g: CIFS)
Description:
Not exactly a bug, more as an inconvenient inflexibility.
The following lines cause CMake to produce a symbolic link to libphysfs.so:
SET_TARGET_PROPERTIES(physfs PROPERTIES VERSION ${PHYSFS_VERSION})
SET_TARGET_PROPERTIES(physfs PROPERTIES SOVERSION ${PHYSFS_SOVERSION})
Unfortunately, the drive the directory is on does not support symbolic link, so
it fails with the error:
CMake Error: cmake_symlink_library: System Error: Operation not supported
Nothing can be done to make them work; however, it would be convenient if there
were the option to perform a copy instead.
Steps to Reproduce:
1) Mount a CIFS
2) Attempt a CMake that performs a symlink (within the CIFS)
3) Failure
4) ?!?!?
5) Loss
Additional Information:
The CIFS is to a Windows share, which is probably why symlinks aren't supported.
Dakon on #sa...@freenode.org suggested this be reported.
==
Issue History
Date ModifiedUsername FieldChange
==
2012-07-31 13:47 Declan White 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-developers] find_package without REQUIRED can cause fatal error now
On Tuesday 31 July 2012, Bill Hoffman wrote: On 7/30/2012 3:38 PM, Alexander Neundorf wrote: The idea was that this is a sign of a broken install. Can you uninstall the vtk-devel package (does this exist ?), because it is broken, i.e. does not contain everything is claims to ? I understand that this is maybe not expected behaviour for an optional package, but maybe Brad is right ? Alex Yes, VTK is broken on the machine, and we could fix the machine. However, this would be the first time we did a work around for the modules test by fixing the machine. I wonder if we could just disable fatal error at the start of find_package optional. Then turn it back on at the end. My concern is optional packages, maybe that is a rare case not sure. One reason why I wanted it to be an error was to force people to fix their install, make it is obvious that it is not the fault of the buildsystem of the project being built, but of the package being used. I'm not sure it is better to fail relatively silently in this case instead of complaining loudly that the package is broken. Users might wonder why it doesn't work, the devel package is installed, in the right place, and still CMake doesn't pick it up. I can have a look how to make it not an error if the find_package() is optional, if we really want that. 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] find_package without REQUIRED can cause fatal error now
On Tue, Jul 31, 2012 at 2:30 PM, Alexander Neundorf neund...@kde.org wrote:
On Tuesday 31 July 2012, Bill Hoffman wrote:
On 7/30/2012 3:38 PM, Alexander Neundorf wrote:
The idea was that this is a sign of a broken install.
Can you uninstall the vtk-devel package (does this exist ?), because it
is broken, i.e. does not contain everything is claims to ?
I understand that this is maybe not expected behaviour for an optional
package, but maybe Brad is right ?
Alex
Yes, VTK is broken on the machine, and we could fix the machine.
However, this would be the first time we did a work around for the
modules test by fixing the machine. I wonder if we could just disable
fatal error at the start of find_package optional. Then turn it back on
at the end. My concern is optional packages, maybe that is a rare case
not sure.
One reason why I wanted it to be an error was to force people to fix their
install, make it is obvious that it is not the fault of the buildsystem of
the project being built, but of the package being used.
I'm not sure it is better to fail relatively silently in this case instead
of complaining loudly that the package is broken.
Users might wonder why it doesn't work, the devel package is installed, in
the right place, and still CMake doesn't pick it up.
I can have a look how to make it not an error if the find_package() is
optional, if we really want that.
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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
One thing Brad and I discussed briefly was simply changing our
generated code to something like this pseudo-code:
if(file is missing)
if(optional)
message(WARNING package is broken -- file ${file} is missing)
set(FOUND FALSE)
# allow find_package to fall through to trying to find the next
installation of this package if there are more possibilities...
else()
message(FATAL_ERROR as we have now and have had since 2.8.7)
endif()
endif()
And then you still have to possibly deal with non-generated
misbehaving project config files, but at least for the scripts we
generate that get included at find_package time, we will not trigger
an error in the optional case.
How does that sound as a compromise position?
Either way, I vote to put this into 'master' immediately AFTER 2.8.9,
and not hold up the release for trying to rush in a last minute change
of this magnitude. I think it's too risky, and the behavior exists in
2.8.7 and 2.8.8 already.
David C.
--
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] find_package without REQUIRED can cause fatal error now
On 07/31/2012 02:30 PM, Alexander Neundorf wrote: On Tuesday 31 July 2012, Bill Hoffman wrote: I wonder if we could just disable fatal error at the start of find_package optional. Then turn it back on at the end. As I pointed out elsewhere in this thread fatal errors are just one way a failure can occur inside find_package when a package is broken. Total sandboxing is not realistic. Partial sandboxing just pushes the underlying problem on a given machine over the horizon. One reason why I wanted it to be an error was to force people to fix their install, make it is obvious that it is not the fault of the buildsystem of the project being built, but of the package being used. Yes. I'm not sure it is better to fail relatively silently in this case instead of complaining loudly that the package is broken. Users might wonder why it doesn't work, the devel package is installed, in the right place, and still CMake doesn't pick it up. IMO once find_package locates a package configuration file the corresponding package *has* been found. If the package is broken failure can occur at a number of different times: (1) The package config .cmake file reports a problem. (2) CMake succeeds but compilation fails due to a missing header (3) Compilation works but linking fails due to a missing library (4) Linking works but runtime fails due to a missing resource The sandboxing approach can only hope to ignore packages that will fail as case 1. Even that may not be desirable. If a package is broken it is better to fix it or explicitly request that it not be used than to automatically ignore it (silently or loudly). That way all failure cases for broken packages are resolved in the same way. I can have a look how to make it not an error if the find_package() is optional, if we really want that. I think a better solution is to allow specific package locations to be explicitly disallowed by the user. This gives them an option to deal with broken packages if they are not an admin on the machine capable of fixing it. That way if the package is an optional dependency and the only instance of it on the system is broken the user still has a way to move forward. I'm not sure how the interface might look or how to tell users they may activate it. David Cole suggested in a sibling to this message to lighten the error message in target info files to a warning along with setting package_FOUND to FALSE if the package is not required. This approach is complementary to the above proposal. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0013448]: Cannot detect extensions of cpp files
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=13448 == Reported By:LynnKaye Assigned To: == Project:CMake Issue ID: 13448 Category: CMake Reproducibility:always Severity: major Priority: high Status: new == Date Submitted: 2012-07-31 21:04 EDT Last Modified: 2012-07-31 21:04 EDT == Summary:Cannot detect extensions of cpp files Description: When I try to go over the tutorial, I write add_executable(Tutorial tutorial.cxx) while I have a tutorial.cpp file. When I run cmake, it says Cannot find source file: tutorial.cxx Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp .hxx .in .txx When I change the file extension from .cpp to .cxx, it builds successfully. Apparently, it fails to find the tutorial.cpp == Issue History Date ModifiedUsername FieldChange == 2012-07-31 21:04 LynnKaye 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
