On 01/12/2015 16:19, Brad King wrote:
On 12/01/2015 10:58 AM, rle...@codelibre.net wrote:
oking for it when the version number is high enough.
I've attached an updated version of the patch which does this. The
behaviour is otherwise identical to the earlier patches. It's less awful
than I e
The following issue has been SUBMITTED.
==
https://public.kitware.com/Bug/view.php?id=15869
==
Reported By:Igor Mironchik
Assigned To:
On 12/01/2015 02:41 PM, Dan Liew wrote:
>> Perhaps, but after regenerating the project the build tool will not
>> re-load the build files and start building again. That will take
>> an additional invocation. The number of iterations required is
>> bounded only by the depth of dependency chains.
>
> I fail to see why that should not work. Producing LLVM bitcode from
> C++ with Clang is just adding -emit-llvm flag, right? So, why can't
> the SuperBuild configure the child build to use Clang and this flag?
> And Bob's your uncle...
Hmm, to be honest I hadn't tried. It works better than expect
>> There is an alternative which I suggested in the post. Have CMake
>> determine the dependencies of the files passed to ``IMPLICIT_DEPENDS``
>> at configure time and spit that into the build files of the generator
>> (that would work for any generator). Then have any changes made to the
>> files
On 12/01/2015 12:47 PM, Levi Morrison wrote:
> I am having trouble reproducing this failure. When I do an
> unrestricted ctest (test everything) it will fail, but if I do
> something like `ctest -VV -R WriteCompilerDetectionHeader` it will
> pass. Any ideas?
Try ensuring that it is a fresh run of
On Tue, Dec 1, 2015 at 7:11 AM, Brad King wrote:
> On 11/30/2015 02:13 PM, Levi Morrison wrote:
>> Hmm.
>
> Thanks. I applied it yesterday and merged to 'next' for testing:
>
> Features: Record standards and features for Intel C++ on UNIX
> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=11
On 12/01/2015 10:58 AM, rle...@codelibre.net wrote:
> I'd definitely like to see this for future Boost releases, though for
> historical releases we're a bit stuck. I'll revisit the work I pointed to
> and see if I can figure out bjam/boost-build and integrate this, since it
> would effectively gi
> 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
> Bo
On 11/30/2015 02:16 PM, Michael Scott wrote:
> Great, I've changed the nullptr references to NULL instead.
Thanks. Applied with minor tweaks and merged to 'next' for testing:
Merge topic 'cmake-W-options' into next
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cfcc9d52
-Brad
--
Power
Hello,
During the last days I worked on the iOS Universal Install topic which
now would benefit from a review. Especially the core changes could need
a third pair of eyes:
https://cmake.org/gitweb?p=stage/cmake.git;a=commit;h=8fb23b42cfc2fb7490e8645fff328add9c231713
I will now concentrate on add
On 11/30/2015 11:05 PM, Kylie McClain wrote:
>> Does work here instead?
>
> Yes, appears to work just fine.
Thanks. Applied accordingly:
Include `sys/types.h` header to get `mode_t`
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=16f5d184
-Brad
--
Powered by www.kitware.com
Please k
On 11/30/2015 02:13 PM, Levi Morrison wrote:
> Hmm.
Thanks. I applied it yesterday and merged to 'next' for testing:
Features: Record standards and features for Intel C++ on UNIX
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=117d49b8
However, it fails the Module.WriteCompilerDetectionHe
13 matches
Mail list logo
