Re: [cmake-developers] -GNinja on Windows
Hi, I just tested this with ReactOS and the results are really promising ! Thank you Peter for working on this. One thing I noticed is the lack of dependency tracking for the resource files (*.rc, they are compiled with rc and not cl). If you #include a file in an .rc and then alter that included file, nothing will happen. We had the same problem with the gcc builds, but since windres is more flexible re. the preprocessor pass, I introduced this line into our cmake files: set(CMAKE_DEPFILE_FLAGS_RC --preprocessor \CMAKE_C_COMPILER -E -xc-header -MMD -MF DEPFILE -MT OBJECT\) I wonder what would be the solution in order to track such dependencies with the msvc toolchain. Regards, Amine. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] -GNinja on Windows
Another thing I noticed while testing ReactOS is that we end up with entries like e:\reactos\ntoskrnl\include/../mm/ARM3/miarm.h (for example) in the .d files, and this triggers recompiles. If this /../ construct is eliminated (not that it's practically possible, I did it just for testing) the dependency works fine. Regards, Amine. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0013291]: find_path(WIN32_INCLUDE_DIR windows.h) does not work with Visual Studio 10 generator
The following issue has been SUBMITTED.
==
http://cmake.org/Bug/view.php?id=13291
==
Reported By:Dimitri Merejkowsky
Assigned To:
==
Project:CMake
Issue ID: 13291
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2012-06-11 09:58 EDT
Last Modified: 2012-06-11 09:58 EDT
==
Summary:find_path(WIN32_INCLUDE_DIR windows.h) does not work
with Visual Studio 10 generator
Description:
Using find_path to find headers from the Microsoft SDK does not work
when using the Visual Studio 10 generator.
Steps to Reproduce:
CMakeLists.txt looking like:
cmake_minimum_required(VERSION 2.8.8)
project(foo C)
find_path(WIN32_INC windows.h)
message(STATUS WIN32_INC: ${WIN32_INC})
Ran from normal cmd.exe:
cmake ..
-- Building for: Visual Studio 10
-- Check for working C compiler using: Visual Studio 10
-- Check for working C compiler using: Visual Studio 10 -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- WIN32_INC: WIN32_INC-NOTFOUND
-- Configuring done
-- Generating done
-- Build files have been written to: C:/Users/dmerejkowsky/work/tmp/cmake_bug/b
Additional Information:
Note that this works when ran from Microsoft Visual Studio command prompt:
cmake -G NMake Makefiles ..
-- The C compiler identification is MSVC 16.0.30319.1
-- Check for CL compiler version
-- Check for CL compiler version - 1600
-- Check if this is a free VC compiler
-- Check if this is a free VC compiler - no
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio
10.0/VC/bin/cl.exe
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio
10.0/VC/bin/cl.exe -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- WIN32_INC: C:/Program Files (x86)/Microsoft SDKs/Windows/v7.0A/Include
-- Configuring done
-- Generating done
-- Build files have been written to: C:/Users/dmerejkowsky/work/tmp/cmake_bug/b
==
Issue History
Date ModifiedUsername FieldChange
==
2012-06-11 09:58 Dimitri MerejkowskyNew Issue
==
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] libarchive and SCHILY.fflags
Am Mittwoch, 6. Juni 2012 um 07:38:44, schrieb Brad King brad.k...@kitware.com On Tue, Jun 5, 2012 at 5:46 PM, Kornel Benko kor...@lyx.org wrote: Try the patch below when building CMake against Ubuntu's libarchive. This one works. But wait ... checking again without the patch ... ERROR You made it. Thanks for testing: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a34015d3 -Brad Hmm, may I ask, when it should (have been) be committed? I regularly check out the sources, but the change is still missing. Kornel signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] libarchive and SCHILY.fflags
On 06/11/2012 10:08 AM, Kornel Benko wrote: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a34015d3 Hmm, may I ask, when it should (have been) be committed? I regularly check out the sources, but the change is still missing. The topic is in the 'next' branch of the Git repo. We have weekly meetings, usually on Tuesday, to review and merge topics to 'master'. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] libarchive and SCHILY.fflags
Am Montag, 11. Juni 2012 um 10:10:16, schrieb Brad King brad.k...@kitware.com On 06/11/2012 10:08 AM, Kornel Benko wrote: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a34015d3 Hmm, may I ask, when it should (have been) be committed? I regularly check out the sources, but the change is still missing. The topic is in the 'next' branch of the Git repo. We have weekly meetings, usually on Tuesday, to review and merge topics to 'master'. -Brad OK, thanks Kornel signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] conditionals in generator expressions
On 06/07/2012 05:47 PM, Stephen Kelly wrote: Brad King wrote: cmGeneratorExpression::Evaluate can be taught to handle everything pretty easily. Then more places need to be taught to pass values through instances of cmGeneratorExpression, such as the INCLUDE_DIRECTORIES property just before it is used in the generators. Each place that constructs a cmGeneratorExpression instance must give it enough information to evaluate all the expressions supported in that context. Documentation must be updated accordingly, and tests added of course. So can this be done in 2.8.10? Hopefully. It's definitely too late for 2.8.9 ;) And can Kitware do it? I've started a local topic branch and implemented $0:..., $1:..., and $CONFIG: When I get a chance I'll add some of the other queries, documentation, and tests for the generator expression features. I don't think I'll have time to add new places like INCLUDE_DIRECTORIES that evaluate values through cmGeneratorExpression. It should be pretty straightforward for you to try though. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] KWStyle line length test failure
In 'next' we are seeing dashboard test failures (and I am seeing it on my local build too, of course) that are related to recent edits in Source/cmNinjaTargetGenerator.cxx. 193: Processing /Users/davidcole/Dashboards/My Tests/CMake/Source/cmNinjaTargetGenerator.cxx 193: Error #0 (341) Line length exceed 80 (max=79) 193: Error #0 (382) Line length exceed 100 (max=79) Please fix them in time for the dashboard run tonight if it's at all possible. Brad and I would like to do our final merge session before 2.8.9-rc1 tomorrow. Thanks, David -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0013292]: Windows : CMake Does Not Define _CONSOLE When Not Building A Win32 Target
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13292 == Reported By:Ryan H. Kawicki Assigned To: == Project:CMake Issue ID: 13292 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2012-06-11 16:24 EDT Last Modified: 2012-06-11 16:24 EDT == Summary:Windows : CMake Does Not Define _CONSOLE When Not Building A Win32 Target Description: Command add_executable does not define _CONSOLE when WIN32 is not specified. Expected that final output would have _CONSOLE defined for preprocessor definitions if WIN32 is not specified and _WINDOWS when WIN32 is specified. Steps to Reproduce: Create a very simple test with one single file. Additional Information: project(test-console) add_executable(test test.cpp) # the generated project has _WINDOWS define when _CONSOLE should be defined. == Issue History Date ModifiedUsername FieldChange == 2012-06-11 16:24 Ryan H. KawickiNew Issue == -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0013293]: INTERNAL: Cache value overwritten without a FORCE option set.
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=13293
==
Reported By:Michael.jeulinl
Assigned To:
==
Project:CMake
Issue ID: 13293
Category: CMake
Reproducibility:always
Severity: feature
Priority: normal
Status: new
==
Date Submitted: 2012-06-11 18:44 EDT
Last Modified: 2012-06-11 18:44 EDT
==
Summary:INTERNAL: Cache value overwritten without a FORCE
option set.
Description:
On INTERNAL type, the cache value is overwritten without a FORCE option set.
Steps to Reproduce:
cmake_minimum_required(VERSION 2.8.8)
#
# From CMake 2.8.8 documentation:
#
# If type is INTERNAL, then the value is always written into the cache,
replacing any values
# existing in the cache. If it is not a cache variable, then this always writes
into the current
# makefile. The FORCE option will overwrite the cache value removing any changes
by the user.
#
project(testSetInternal)
message(STATUS 0-Foo:${Foo})
set(Foo TrueFoo CACHE STRING Foo value FORCE)
message(STATUS 1-Foo:${Foo})
set(Foo Foo CACHE STRING Foo value)
message(STATUS 2-Foo:${Foo})
message(STATUS 0-Bar:${Bar})
set(Bar TrueBar CACHE INTERNAL Bar value FORCE)
message(STATUS 1-Bar:${Bar})
set(Bar Bar CACHE INTERNAL Bar value)
message(STATUS 2-Bar:${Bar})
==
Issue History
Date ModifiedUsername FieldChange
==
2012-06-11 18:44 Michael.jeulinlNew Issue
==
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] KWStyle line length test failure
On 11.06.2012 18:02, David Cole wrote: In 'next' we are seeing dashboard test failures (and I am seeing it on my local build too, of course) that are related to recent edits in Source/cmNinjaTargetGenerator.cxx. 193: Processing /Users/davidcole/Dashboards/My Tests/CMake/Source/cmNinjaTargetGenerator.cxx 193: Error #0 (341) Line length exceed 80 (max=79) 193: Error #0 (382) Line length exceed 100 (max=79) Please fix them in time for the dashboard run tonight if it's at all possible. Brad and I would like to do our final merge session before 2.8.9-rc1 tomorrow. OK, I fix it. Maybe more than 'allowed'. Peter -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] -GNinja on Windows
On 11.06.2012 13:23, Amine Khaldi wrote: Another thing I noticed while testing ReactOS is that we end up with entries like e:\reactos\ntoskrnl\include/../mm/ARM3/miarm.h (for example) in the .d files, and this triggers recompiles. If this /../ construct is eliminated (not that it's practically possible, I did it just for testing) the dependency works fine. One of my last changes was to replaces back slashes with slashes exactly because of \../../ problems. Have you used cl and recent next? Peter -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] -GNinja on Windows
All tests pass now for MSVC and MinGW! With some small patches for ninja: https://github.com/syntheticpp/ninja/commits/ninja-for-cmake The changes are only needed for msvc when the build dir path contains spaces, and for mingw because of slashes in path names. Cheers, Peter -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] -GNinja on Windows
On 6/11/2012 10:21 PM, Peter Kümmel wrote: All tests pass now for MSVC and MinGW! With some small patches for ninja: https://github.com/syntheticpp/ninja/commits/ninja-for-cmake The changes are only needed for msvc when the build dir path contains spaces, and for mingw because of slashes in path names. Great work. Nice to see. What are the chances of those changes being accepted upstream? I am a bit concerned about the quote stuff. Putting quotes in and then taking them out. Where do the quotes come from? Is there another way to put paths with spaces into ninja? Most of the tests except the depend stuff was passing with spaces in the path before these changes. Is this all about the .d file contents? -Bill -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] -GNinja on Windows
On 12.06.2012 04:33, Bill Hoffman wrote: On 6/11/2012 10:21 PM, Peter Kümmel wrote: All tests pass now for MSVC and MinGW! With some small patches for ninja: https://github.com/syntheticpp/ninja/commits/ninja-for-cmake The changes are only needed for msvc when the build dir path contains spaces, and for mingw because of slashes in path names. Great work. Nice to see. What are the chances of those changes being accepted upstream? I am a bit concerned about the quote stuff. The patches are not critical, but there's not much traffic the last days. Putting quotes in and then taking them out. Where do the quotes come from? Is there another way to put paths with spaces into ninja? Yes sounds strange, but atm I've no better idea, ninja adds the quotes because it internally has a space separated list, see the link in my comment in merge request: https://github.com/martine/ninja/pull/324 But I think the patch is straight forward. The Win32 functions simply don't need them, even worse they reject the quoted path as Invalid argument. Most of the tests except the depend stuff was passing with spaces in the path before these changes. Is this all about the .d file contents? Yes, ninja can't open the .d files when they are behind a space and stops. It works when your build folder has no spaces. The other patch also isn't critical. https://github.com/martine/ninja/pull/322 It's like a fall back. Peter -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
