> On 25 Sep 2016, at 16:53, Braden McDaniel wrote:
>
> Yes, that squares with my understanding of the current semantics.
>
> Interestingly, in Xcode 8, the versioned SDK directory is actually a
> symlink to the unversioned one. It would not surprise me if the
> versioned
On 08/11/2016 06:48 PM, Zan Lynx wrote:
The Fedora /usr/bin/cxxtestgen script calls /usr/bin/python3. NOT
python2 or python.
CMake runs /usr/bin/python /usr/bin/cxxtestgen which is linked to
python2, and the script fails.
I don't quite understand why CMake feels the need to call it explicitly
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".
The branch, next has been updated
via 4994d675cfc9cc52c180dcf7b7fb1b0c8ec9bf40 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".
The branch, next has been updated
via 930dec1e95061983dac19004e0bf5740339fe46b (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".
The branch, next has been updated
via 022bd40319d609099d836bd40fd67ce58f3ce7b2 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".
The branch, next has been updated
via 8b91d5f6730301176bcef83f689267ec433887ef (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".
The branch, next has been updated
via f73fc9bc9e5e0d13da64695e4b2209e00632f874 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".
The branch, next has been updated
via e924a8ef1d469760c614617cb16ed9801dcbd941 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".
The branch, next has been updated
via afe788b028034d796f0fc121eee557930fa73e75 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".
The branch, next has been updated
via 6330c8f70b69e8aac2d05846ad509d9972df2090 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".
The branch, next has been updated
via 5e2813bc7a5fc95e09da993384bad8801df476ee (commit)
via
Thanks for the quick reply. I completely understand the move to Gitlab;
it's a much nicer flow.
I've posted https://gitlab.kitware.com/cmake/cmake/merge_requests/124 for
review.
cheers,
david
On Mon, Sep 26, 2016 at 9:59 AM Brad King wrote:
> On 09/23/2016 06:17 PM,
On 09/26/2016 10:07 AM, Daniel Pfeifer wrote:
> the documentation of the ctest_build command states "Append semantics
> are defined by the dashboard server in use." I think this is not
> precise enough.
>
> The client side effect of APPEND is that CTest creates an
> Append="true" attribute in the
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".
The branch, master has been updated
via 1a5fddfe6d56733528ace3d15899b0739ea28054 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".
The branch, next has been updated
via 519b3173245cc53bd33b22e0b6bfe3780faf9160 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".
The branch, next has been updated
via ed5809dd7da5b11f65ecb3996adc37d9cfecf145 (commit)
via
On 12/09/2016 15:09, Brad King wrote:
On 09/09/2016 04:04 PM, Robert Dailey wrote:
Currently nightly builds are tagged 3.6.2. Are there no nightly builds
for 3.7 or am I missing something?
They are 3.6.2.$date, indicating post-3.6 feature development.
See the documentation of CMAKE_VERSION:
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".
The branch, next has been updated
via cdaf32edb833a9cdfd71b99e2a013206c2a5bc42 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".
The branch, next has been updated
via 5729779fb802ef3dc8fb00ada2d284edd580c022 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".
The branch, next has been updated
via db5b6bf630ddcee02f97bdf368440692250c8d34 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".
The branch, next has been updated
via ccf06ce07151b3e67e8673976d74f03a081eb9de (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".
The branch, next has been updated
via a76645452f07c807260d975ffdbdeba605682d0f (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".
The branch, next has been updated
via faf942d8f24416635e776aec909ba356b2cd1d9e (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".
The branch, master has been updated
via e6a38a84d63b0c247a8f52bb5df76820db32f45e (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".
The branch, master has been updated
via a721830767c6a7819ed82cda5f910b732201f885 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".
The branch, master has been updated
via d57a6493fc667f8a6ffa9fad2566a0cbea785ec5 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".
The branch, master has been updated
via c6f07d06c610a9b1e6062d70ffc78c04bdf48ee4 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".
The branch, master has been updated
via 4d6f0a55731e462a53feb0956484c104ab8c1018 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".
The branch, next has been updated
via b9488840e0a654f46aab074f4fd45be2f116b1ed (commit)
via
Hi,
the documentation of the ctest_build command states "Append semantics
are defined by the dashboard server in use." I think this is not
precise enough.
The client side effect of APPEND is that CTest creates an
Append="true" attribute in the XML. It does not append anything to the
already
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".
The branch, next has been updated
via 3f376968376366e0eb1b31145a2db94f53216f18 (commit)
via
On 09/23/2016 06:17 PM, David Neto via cmake-developers wrote:
> I've attached a patch to add GLSL language support, compiling down to SPIR-V.
> It's based on master from this morning.
Thanks!
We are currently experimenting with a GitLab workflow on
https://gitlab.kitware.com/cmake/cmake
but
_VERSION_MINOR 6)
-set(CMake_VERSION_PATCH 20160926)
+set(CMake_VERSION_PATCH 20160927)
#set(CMake_VERSION_RC 1)
---
Summary of changes:
Source/CMakeVersion.cmake |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
hooks/
If aux_source_directory(. SRCS) or file(glob SRCS "*.c") is used, files in SRCS are not sorted.This can cause a list of files that has different order across machines.
Even though it does not have any correctness issue, there may be a problem.If we have a build infrastructure (e.g., OBS), the
On 9/26/2016 5:50 PM, David Neto via cmake-developers wrote:
I agree. I work for Google but not in this area, and I don't know who
is doing this support. I suspect this is just an accidental duplication
of effort. I've pinged someone to see about finding the right person to
coordinate with.
On Mon, Sep 26, 2016 at 5:23 PM Florent Castelli
wrote:
>
> Have you tried working it out with Google? Maybe dropping your
> implementation and integrate theirs as they released it first and
> started documenting it?
>
> I just don't want to have 2 toolchains to
36 matches
Mail list logo