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 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
>
>> 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
> 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
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.
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
--
> 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
>
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
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
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
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
12 matches
Mail list logo