On 16-Nov-15 21:01, rle...@codelibre.net wrote:
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.
Since it's `Boost::date_time` I expect that it will be `Boost::bo
On 13-Nov-15 20:59, Bartosz Kosiorek wrote:
Hello.
Main reason for using Makefile instead of Xcode is performance reason. Xcode
generator is much slower that Makefile in our project.
The performance was improved in Cmake 3.2 but still it is much slower on Xcode.
Similar slowness could be obser
I also forgot to mention that this patch is based on the 'next'
branch. Originally it was based on 'master' but I rebased it to
'next'. Let me know if this is correct. I'm assuming the master branch
is used for maintenance releases only and would not be appropriate for
such a change.
On Mon, Nov 1
Hello everyone,
I apologize for the long hiatus, but I've finally gotten back to this.
I've implemented the suggestions here:
* deleteCache() now clears the toolset
* When the binary directory changes, the GUI now reloads the toolset
(The toolset isn't used by anything except the first-time dialo
IMHO, the code style in the CMake code base is incredibly
inconsistent, but even the consistent style that is there is a giant
pain to follow by hand.
I'm constantly fighting my tooling's auto formatting. I prefer to keep
my code additions similar to surrounding code. Do you use some tool
such as
>
> How did you test these? For full testing we need the CMake test
>> suite to pass with the Intel compilers. In particular, tests with
>> 'CompileFeatures' in their name cover this functionality.
>
>
> I was able to build and use (or not use as appropriately) C++11 and C++14
> for a given proje
The following issue has been SUBMITTED.
==
https://public.kitware.com/Bug/view.php?id=15847
==
Reported By:Erik Sjölund
Assigned To:
On Mon, Nov 16, 2015 at 11:31 AM, Brad King wrote:
> On 11/16/2015 12:21 PM, Levi Morrison wrote:
> > I found and fixed a mistake in my macro.
>
> Great. Did you mean to attach the corrected version?
>
It seems my attachments are getting scrubbed or something?
> I have now tested this on Intel
Thanks, Brad.
Update to my previous email--I forgot that we have switched to building
cmake 3.3.2 with
gcc 4.8.2 now, not Studio.
Here's what I see, on x86,
CMakeCCompiler.cmake:
set(CMAKE_C_IMPLICIT_LINK_DIRECTORIES
"/lib/amd64;/usr/lib/amd64;/usr/gcc/4.8/lib/gcc/i386-pc-solaris2.12/4.8.2/amd64;
On 11/16/2015 12:21 PM, Levi Morrison wrote:
> I found and fixed a mistake in my macro.
Great. Did you mean to attach the corrected version?
> I have now tested this on Intel 12, 13, 14, and 15 for both C++11 and C++14.
How did you test these? For full testing we need the CMake test
suite to p
On Mon, Nov 16, 2015 at 9:54 AM, Levi Morrison
wrote:
> Note that the Intel compiler may be tricky because it simulates MSVC
>> on Windows and GNU elsewhere. The needed options may vary across
>> platforms, and our tables need to reflect this.
>
>
> See the attached patch; will the if UNIX check
>
> Note that the Intel compiler may be tricky because it simulates MSVC
> on Windows and GNU elsewhere. The needed options may vary across
> platforms, and our tables need to reflect this.
See the attached patch; will the if UNIX check will suffice for now?
0001-Add-CXX_STANDARD-support-to-In
On 11/16/2015 11:46 AM, Levi Morrison wrote:
> should I bound this by versions that exist? For instance, there is no
> Intel 17.0 so should I limit this?
No. For other compilers we just assume newer versions are at least
as capable as previous versions and are compatible with the needed
options a
On 11/16/2015 11:30 AM, Stuermer, Michael SP/HZA-ZSEP wrote:
>>
>> https://github.com/sphinx-doc/sphinx/commit/034c4e942451fad40350ae3bb3beda6c63a49064
>
> The warning itself is not the problem, sphinx (at least my current version)
> simply
> does not have any "default" theme so the design is c
On Mon, Nov 16, 2015 at 9:42 AM, Brad King wrote:
> HI Levi,
>
> Thanks for coming forward to work on this!
>
> On 11/16/2015 11:34 AM, Levi Morrison wrote:
> > Why is MSVC doing a version check around the CXX_STANDARD_DEFAULT?
>
> The version check delimits the set of versions for which CMake
>
HI Levi,
Thanks for coming forward to work on this!
On 11/16/2015 11:34 AM, Levi Morrison wrote:
> Why is MSVC doing a version check around the CXX_STANDARD_DEFAULT?
The version check delimits the set of versions for which CMake
has recorded knowledge of C++ feature availability.
> Should I be
Message was rejected – retrying.
On Mon, Nov 16, 2015 at 9:31 AM, Levi Morrison
wrote:
> First off, this is my first attempt at a CMake contribution ever, so
> please be gentle!
>
> I have a few questions about my patch, though:
>
> Why is MSVC doing a version check around the CXX_STANDARD_DEFAU
> -Original Message-
> From: cmake-developers [mailto:cmake-developers-boun...@cmake.org]
> On Behalf Of Brad King
> Sent: Monday, November 16, 2015 4:57 PM
> To: cmake-developers@cmake.org
> Subject: Re: [cmake-developers] PATCH: fix sphinx-documentation theme
>
> On 11/16/2015 10:45 AM
On 11/16/2015 10:45 AM, Stuermer, Michael SP/HZA-ZSEP wrote:
> Sphinx does not seem to provide any "default" theme anymore,
> it's called "classic" now.
Thanks. This was previously discussed here:
https://cmake.org/pipermail/cmake/2015-July/061096.html
Upstream Sphinx has decided to drop the w
Sphinx does not seem to provide any "default" theme anymore, it's called
"classic" now. I'm not sure if this breaks documentation generation at Kitware,
but the documentation on cmake.org is generated using sphinx 1.4a0+ and I'm
using 1.3.1 here.
It might even be better to make the html_theme v
On 11/13/2015 05:40 PM, A Chin wrote:
> I tested using Solaris Studio 12.4 on our latest Solaris development release,
> post Solaris 11 Update 3.
[snip]
On 11/13/2015 03:05 PM, C Bergström wrote:
> At a glance - I'd 1/2 agree with you on what SS will do.
> /opt/SUNWspro/lib /opt/SUNWspro/prod/lib -
On 11/13/2015 04:51 PM, Michael Scott wrote:
> Here's the original patch split up into smaller more specific patches.
> Let me know if there's any issues or if everything's okay, so I can
> continue with the rest of the intended changes.
Thanks. That is much easier to review and see the purpose
Hi Roger,
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
There is some discussion there about similar FindBoost changes.
Also please take a look at these tests
It’s nice and I was thinking of doing the same!
But one there’s one thing that comes to mind. Some compiled libraries have
dependencies on other compiled libraries.
Don’t you think it would make sense to teach FindBoost about those so we link
everything properly?
And also maybe add the native d
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
25 matches
Mail list logo
