It turns out this was my fault: removing the instantiation/export of
std::char_traitschar
was sufficient to correct the linker errors.
Sorry for the noise,
Roger
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Did you try to remove all the explicit template exports? I never had to do
it and compiled many static and shared libraries on Windows. Of course VS
is going to complain about exporting template classes but as long as you
don't try to mix VS versions I think you can safely ingore those
On 2016-06-06 16:39, B00083603 Michael O Brien wrote:
Hi Roger,
When I run sudo -s I get bash: /home/myaccount/ : Permission denied
but I get a root prompt on the terminal. I get a permission denied
when I try to cd into anything deeper than /home/myaccount/
Yes the /home/ is an NFS mount as
On 2016-04-12 11:22, Joachim Wuttke wrote:
FindBoost does not detect absence of header files.
To be specific: Run the following under cmake version 3.5.1:
set(Boost_NO_BOOST_CMAKE ON) # prevent shortcut
set(Boost_USE_STATIC_LIBS OFF)
set(Boost_USE_MULTITHREADED ON)
set(Boost_USE_STATIC_RUNTIME
On 2016-05-11 19:30, Chuck Atkins wrote:
I guess it doesn't really matter but for the libraries that don't have
a single include header, should you be using these instead:
* container/container_fwd.hpp
* exception/all.hpp
* filesystem.hpp
* math_fwd.hpp (instead
I've come across an odd situation where I'm unsure what the most
portable and recommended solution would be.
I'm linking a program against the CURL and ICU libraries. CURL has
traditional variables for the includes and libraries; ICU has imported
targets.
In FindICU:
On 2016-08-12 15:50, Ken Boulange wrote:
I am a one man company that needs to get a Library built from C/C++
source using CMake.
My system is windows 7 Professional. I am running MVS 8 (Microsoft
Visual Studios 8) I need the following library built from the below
URL (It's a DICOM image
On 2016-10-12 15:28, Konstantin Tokarev wrote:
Hello,
In my cmake project I need to use system version of libxml2 on macOS
(/usr/lib/libxml2.dylib), however in case it is installed in MacPorts
the latter version is picked by find_package. On the other hand I'd
like to avoid hardcoding absolute
ot at top of my list. If you wanted to
propose a change an/or open a merge request that would certainly be
welcome.
I have done some preliminary work here:
https://gitlab.kitware.com/rleigh/cmake/commits/ice-3.7.0
It's working on Linux, but not yet finding the libraries on Windows w
On 2017-08-10 09:50, Jones J.W. wrote:
I'm building my code on Linux using the g++ flags "-std=c++11". This
means that I must link with the libIce++11 libraries instead of
libIce.
The FindIce module, however as no provision for choosing these
libraries thus resulting in unresolved symbols at
On 2017-07-14 03:33, Florian Lindner wrote:
Now, in the docs I everywhere read not to add the files using GLOB.
However, I have found no definitive guide how to add
project files in a large project with subdirs like that.
How would you do it in cmakeish fashion?
List each file explicitly.
On 2018-05-21 18:39, Mateusz Loskot wrote:
I've been recently trying to update/add Find-modules to CMake:
updated FindJPEG, proposed FindODBC and most recently FindLZ4.
[…]
The FindLZ4 discussion basically ended with suggestion from Brad that,
instead of adding Find-module to CMake, I should
Please find attached two patches which allow these libraries to detect
debug versions of the libraries on Windows. I copied the behaviour from
the PNG module as suggested on #cmake.
Kind regards,
Roger Leigh
0001-FindTIFF-Find-debug-libraries.patch
Description: Binary data
On 08/07/2015 09:59 AM, rle...@codelibre.net wrote:
Please find attached two patches which allow these libraries to detect
debug versions of the libraries on Windows. I copied the behaviour from
the PNG module as suggested on #cmake.
Thanks. Here are some comments:
+if(NOT TIFF_LIBRARY)
I often configure projects with an empty install prefix and install with
DESTDIR set. This works for most projects and they are relocatable.
However, the configure_package_config_file function breaks if this is
done:
CMake Error at cmake/CMakePackageConfigHelpers.cmake:254 (file):
file
I encountered an unexpected build failure in a superbuild project today,
and after investigation with the help of ngladitz on #cmake, we got to the
bottom of the problem.
http://blogs.msdn.com/b/dsvc/archive/2012/02/29/output-from-exec-task-resulting-in-build-failure.aspx
When cmake runs an
I have attached a patch to add imported targets to FindBoost, in the form
of Boost:: (e.g. Boost::date_time) or Boost::Boost as a generic
interface library for header-only components.
If this type of patch is acceptable, I would like to do this for a number
of other modules for which I would like
Patch attached to add imported target (XercesC::XercesC), along with a
unit test.
Regards,
Roger
0001-XercesC-Add-imported-targets-and-unit-test.patch
Description: Binary data
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
> On 12/01/2015 05:11 PM, Roger Leigh wrote:
>> Attached. I also attached the BoostScanDeps raw output and after
>> search-and-replace to make into valid cmake conditionals, and then after
>> simplifying where following release dependencies are unchanged, so you
>> can see where the logic in
- Add TIFF::TIFF imported target
- Document imported target
- Add testcase to test the standard variables and the imported
target
Also:
- Add TIFF_INCLUDE_DIRS to match common practice
- Update documentation generally, including documenting
TIFF_INCLUDE_DIRS
Patch attached.
Regards,
- Add TIFF::TIFF imported target
- Document imported target
- Add testcase to test the standard variables and the imported
target
Also:
- Add TIFF_INCLUDE_DIRS to match common practice
- Update documentation generally, including documenting
TIFF_INCLUDE_DIRS
Patch actually attached this
> - Add unit test to test imported targets and existing variables
I should mention that to run the unit test, you must define the GTEST_ROOT
environment variable to point to the gtest build, due to gtest being
annoyingly crippled to be uninstallable for dubious reasons. You can pass
> - Adds GTest::GTest and GTest::Main imported targets (including
> Thread::Thread dependency for GTest::GTest and GTest::GTest for
> GTest::Main; the latter might not be appropriate and could be removed if
> needed--but I'm unaware of any situation where you would want to use
> GTest::Main
Pushed to
https://cmake.org/gitweb?p=stage/cmake.git;a=shortlog;h=refs/heads/gtest-
imported-targets
and merged into next for review and testing.
- Adds GTest::GTest and GTest::Main imported targets (including
Thread::Thread dependency for GTest::GTest and GTest::GTest for
GTest::Main; the
> On 11/30/2015 11:26 AM, rle...@codelibre.net wrote:
>> I have improved the parsing speed somewhat and added some progress
>> diagnostics to inform the user what's happening to compensate for the
>> time
>> it takes to process the dependencies. It's still slower than I'd
>> ideally
>> like, but
> On 11/30/2015 11:54 AM, rle...@codelibre.net wrote:
>> I do worry about the maintenance burden of hardcoding the information in
>> the script.
>
> I do too. We already have to update the script for each Boost release.
> This is among the reasons the work is better integrated with upstream
>
> Thanks for working on this. Please read through this mailing list
> thread:
>
> IMPORTED targets for some Find modules
> https://cmake.org/pipermail/cmake-developers/2014-June/010694.html
Done.
> On 11/16/2015 09:26 AM, Florent Castelli wrote:
>> But one thereâs one thing that comes to
> On 01/19/2016 12:43 PM, Sam Thursfield wrote:
>> Imported targets are now the recommended way of dealing with external
>> library dependencies.
>
> Thanks! Applied with minor doc format fixup and merged to 'next'
> for testing:
>
> FindPNG: Create an imported PNG::PNG target (#15911)
>
On 2016-04-12 11:22, Joachim Wuttke wrote:
FindBoost does not detect absence of header files.
To be specific: Run the following under cmake version 3.5.1:
set(Boost_NO_BOOST_CMAKE ON) # prevent shortcut
set(Boost_USE_STATIC_LIBS OFF)
set(Boost_USE_MULTITHREADED ON)
set(Boost_USE_STATIC_RUNTIME
On 2016-05-11 19:30, Chuck Atkins wrote:
I guess it doesn't really matter but for the libraries that don't have
a single include header, should you be using these instead:
* container/container_fwd.hpp
* exception/all.hpp
* filesystem.hpp
* math_fwd.hpp (instead
30 matches
Mail list logo
