Re: [cmake-developers] [CMake] CMake 2.8.9-rc1 ready for testing!
Yes, you are right. My fault, I was really not up to date. It works fine with your fix. Thanks Claus On 27.06.2012, at 20:07, Peter Kümmel wrote: Works also here on Windows, Ubuntu 12.04, and Mac 10.8 (gcc-4.2, i386), at least when I use cmake as sources. Are you sure your sources are up to date? Recently I fixed another(?) crash reported by you: https://github.com/syntheticpp/CMake/commit/2fb07fc44c49da70a609fbc0df013c0301e9f36a #Source/cmExtraEclipseCDT4Generator.cxx -- 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 0013370]: Visual Studio filter tree as source directory tree (with patch)
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=13370 == Reported By:LordJZ Assigned To: == Project:CMake Issue ID: 13370 Category: CMake Reproducibility:always Severity: feature Priority: normal Status: new == Date Submitted: 2012-07-02 17:35 EDT Last Modified: 2012-07-02 17:35 EDT == Summary:Visual Studio filter tree as source directory tree (with patch) Description: Currently, CMake groups the source files into 'Header Files', 'Source Files', etc. When there are quite a lot of files, it becomes hard to navigate through this mess. A lot of other IDEs make the same solution tree as directory tree. Netbeans in particular. I have created a rough patch to implement this feature for Visual Studio. Links: My CMake fork with this feature: https://github.com/LordJZ/CMake/commits/master Direct patch file: https://dl.dropbox.com/u/9241118/cmake.patch (also attached) An example of the resulting tree: https://dl.dropbox.com/u/9241118/cmake-file-tree-respect-trinitycore.png Compiled binaries for Windows: https://github.com/downloads/LordJZ/CMake/cmake-file-tree-respect.7z (no dependencies) There are some issues of the patch: 1) Works for Visual Studio 10 (2010 pre-release), Visual Studio 2010, Visual Studio 11 (2012 pre-release), and Visual Studio 2012. 2) My changes are not yet fixed to fit CMake coding style. 3) The patch eliminates in-Studio view of source groups (though they are not seen in other IDEs). Seems to deprecate bug http://www.cmake.org/Bug/view.php?id=11229. 4) Is possibly still affected by bug http://www.cmake.org/Bug/view.php?id=7921. RFC. == Issue History Date ModifiedUsername FieldChange == 2012-07-02 17:35 LordJZ New Issue 2012-07-02 17:35 LordJZ File Added: cmake.patch == -- 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] trouble with running cpack --help during cmake step
2012/7/2 David Cole :
> On Mon, Jul 2, 2012 at 11:58 AM, Eric Noulard wrote:
>> 2012/7/2 David Cole :
>>>
>>> On our dashmacmini3 dashboards, we're getting:
>>>
>>> DPKG_EXECUTABLE='/sw/bin/dpkg'
>>>
>>> It's found by find_program at CMake configure time, but cpack does not
>>> find this program (it's not in the PATH) at testing time.
>>>
>>> What should we do about this?
>>>
>>> I could just set DPKG_EXECUTABLE=OFF to circumvent the test on these 3
>>> dashboards for now... But I'd like a real fix for it. Seems like cpack
>>> should find it if CMake's find_program can find it.
>>
>> Yes I [apparently wrongly] supposed
>>
>> that
>> cmSystemTools::FindProgram("dpkg")
>>
>> would find 'dpkg' iff:
>> find_program(DPKG_EXECUTABLE NAMES dpkg)
>> did find it...
>>
>> Why is the result of this two commands differents?
>> Are there some env var that makes the behavior different?
>> Or may be the configure environement is different from
>> the test environment...
>>
>>
>> --
>> Erk
>> Le gouvernement représentatif n'est pas la démocratie --
>> http://www.le-message.org
>
>
> Probably because of this:
>
> LIST(APPEND CMAKE_SYSTEM_PREFIX_PATH
> /sw# Fink
> /opt/local # MacPorts
> )
>
> from Darwin.cmake...
OK could you try my proposal I just pushed on stage:
To g...@cmake.org:stage/cmake.git
848f220..a8c659c HEAD -> DoNotInvokeCPackAtCMakeTime-forCMakeTests
And of course you were right for the "get the list at test time"
because at least
the "non-finding" would have been consistent.
I'll do that but probably not for 2.8.9.
--
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--
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] trouble with running cpack --help during cmake step
On Mon, Jul 2, 2012 at 11:58 AM, Eric Noulard wrote:
> 2012/7/2 David Cole :
>>
>> On our dashmacmini3 dashboards, we're getting:
>>
>> DPKG_EXECUTABLE='/sw/bin/dpkg'
>>
>> It's found by find_program at CMake configure time, but cpack does not
>> find this program (it's not in the PATH) at testing time.
>>
>> What should we do about this?
>>
>> I could just set DPKG_EXECUTABLE=OFF to circumvent the test on these 3
>> dashboards for now... But I'd like a real fix for it. Seems like cpack
>> should find it if CMake's find_program can find it.
>
> Yes I [apparently wrongly] supposed
>
> that
> cmSystemTools::FindProgram("dpkg")
>
> would find 'dpkg' iff:
> find_program(DPKG_EXECUTABLE NAMES dpkg)
> did find it...
>
> Why is the result of this two commands differents?
> Are there some env var that makes the behavior different?
> Or may be the configure environement is different from
> the test environment...
>
>
> --
> Erk
> Le gouvernement représentatif n'est pas la démocratie --
> http://www.le-message.org
Probably because of this:
LIST(APPEND CMAKE_SYSTEM_PREFIX_PATH
/sw# Fink
/opt/local # MacPorts
)
from Darwin.cmake...
--
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] Fwd: [CMake 0013366]: Ninja generator on windows does not take everything into account when checking the command line length limit
On 02.07.2012 17:40, Bill Hoffman wrote: Can we just put the link step into the response files? The code now catches nearly all cases. I don't think it will fail in any real-live usage. Peter Original Message Subject: [CMake 0013366]: Ninja generator on windows does not take everything into account when checking the command line length limit Date: Sun, 1 Jul 2012 16:59:52 -0400 From: Mantis Bug Tracker To: bill.hoff...@kitware.com The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=13366 == Reported By:Josh Faust Assigned To: == Project:CMake Issue ID: 13366 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2012-07-01 16:59 EDT Last Modified: 2012-07-01 16:59 EDT == Summary:Ninja generator on windows does not take everything into account when checking the command line length limit Description: When generating the ninja build files, on windows cmake will check the command line length and generate a response file if it's too long. It does this by checking the args and the build line passed to the ninja rule. This does not take into account, though, what the ninja rule actually expands to including any variables passed such as link flags, full executable path, etc. CMake sets the command line limit to 8000 characters on windows, though the actual limit is 8192. I'm assuming it's set to 8000 because it's trying to account for the lack of these flags, but this is not always enough. In rare cases the build can still fail with a "The command line is too long." error. In my specific case, these extra flags account for ~500 characters, while cmake only actually checks http://www.cmake.org/Bug/view.php?id=5058#c7700 characters -- and added together they're above the 8192 limit. The quick fix seems to be changing the max command line to be shorter (say, 7000) in cmNinjaNormalTargetGenerator.cxx:483. The real fix would be to retrieve the rule and expand all the variables in the command, which I do not see an easy way of doing after a quick look through the code. == Issue History Date ModifiedUsername FieldChange == 2012-07-01 16:59 Josh Faust New 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 -- 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] trouble with running cpack --help during cmake step
2012/7/2 David Cole :
>
> On our dashmacmini3 dashboards, we're getting:
>
> DPKG_EXECUTABLE='/sw/bin/dpkg'
>
> It's found by find_program at CMake configure time, but cpack does not
> find this program (it's not in the PATH) at testing time.
>
> What should we do about this?
>
> I could just set DPKG_EXECUTABLE=OFF to circumvent the test on these 3
> dashboards for now... But I'd like a real fix for it. Seems like cpack
> should find it if CMake's find_program can find it.
Yes I [apparently wrongly] supposed
that
cmSystemTools::FindProgram("dpkg")
would find 'dpkg' iff:
find_program(DPKG_EXECUTABLE NAMES dpkg)
did find it...
Why is the result of this two commands differents?
Are there some env var that makes the behavior different?
Or may be the configure environement is different from
the test environment...
--
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--
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] trouble with running cpack --help during cmake step
On Thu, Jun 28, 2012 at 8:04 AM, Eric Noulard wrote:
> 2012/6/27 David Cole :
>> On Tue, Jun 26, 2012 at 6:31 PM, David Cole wrote:
>>> On Tue, Jun 26, 2012 at 5:56 PM, Eric Noulard
>>> wrote:
2012/6/26 Bill Hoffman :
> So, this code here:
>
> 2a34b579 Tests/CMakeLists.txt (Eric NOULARD 2012-03-30
> 17:07:06 +0200 720) # Analyze 'cpack --help' output for list of
> available generators:
> 2a34b579 Tests/CMakeLists.txt (Eric NOULARD 2012-03-30
> 17:07:06 +0200 721) execute_process(COMMAND ${CMAKE_CPACK_COMMAND}
> --help
>
>
> The trouble is the cpack that is being tested is the one from the build
> tree. If you have a very old CMake build tree, and you do a git pull and
> gets lots of new cmake code. Then when you re-run cmake on the build
> tree,
> the cpack --help might crash. I am not sure how this works on a fresh
> build tree either as cpack won't even exist.
You are right this kind of tests may not be safely done at CMake time.
I did that in order to avoid to replicate the code inside CPack factory
(have a look at cmCPackDebGenerator::CanGenerate()
and cmCPackRPMGenerator::CanGenerate())
which checks whether if a generator may be instantiated or not.
This was done for conditionnally enabling RPM or DEB generator on MacOS
see http://public.kitware.com/Bug/view.php?id=13064
This is was mistake to do that in Tests/CMakeLists.txt.
This should be harmless since it will probably "only" prevent RPM and DEB
CPack tests to be run (ACTIVE_CPACK_GENERATORS will be empty)
but this is a mistake.
I shall implement proper CMake-time check in Tests/CMakeLists.txt.
Unfortunately I may not be able to do that until sunday 1rst of July...
Is this blocking 2.8.9 ?
I'll try tomorrow night but I cannot ensure I'll have time to do it.
Basically this would be something like:
set(ACTIVE_CPACK_GENERATORS)
then
find_program(RPMBUILD_EXECUTABLE NAMES rpmbuild)
if (RPMBUILD_EXECUTABLE)
list(APPEND ACTIVE_CPACK_GENERATORS "RPM")
endif()
find_program(DPKG_EXECUTABLE NAMES dpkg)
if (DPKG_EXECUTABLE)
list(APPEND ACTIVE_CPACK_GENERATORS "DEB")
endif()
--
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--
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
>>>
>>>
>>> It's not blocking 2.8.9 -- yet! -- but please get to it as soon as you
>>> can, and let us know when you've merged a fix to 'next'.
>>>
>>> Thanks,
>>> David
>>
>>
>>
>> A better alternative (I think) would be to run the same kind of code
>> you are running now, but to do it at the correct time. i.e. -- execute
>> the code that is currently running at cmake configure time via a
>> script that gets invoked when the test is run.
>
> This is true but it makes the CPack testing not so obvious.
> Since the current code was used to create tests so we get a
> chicken and eggs problem.
>
> currently after (initial) configuration I can do:
> ctest -R RPM -N
>
> and get the list of tests?
> What filtering capability would I get if the test itself is generating
> subtest?
>
> The issue here is that CMake is assumed to be there when CMake itself
> is built ( because CMake can/must be boostrapped) whereas CPack may
> not be there when it is built.
>
> A possible solution would be to separate the definition of all the
> CPack related tests
> in order to define them when we know that CPack has been built.
>
>> Then you *can* reliably
>> use the built cpack to see what generators it says it supports, and
>> use those as the list of generators to test.
>
> In order to get this fix fast enough I did not implement this solution now,
> I'll think more about.
> The current fix (in next):
> Merge topic 'DoNotInvokeCPackAtCMakeTime-forCMakeTests' into next
>
> 848f220 Do not run cpack at CMake time it is not available.
>
> just checks for rpmbuild and dpkg availability.
>
> --
> Erk
> Le gouvernement représentatif n'est pas la démocratie --
> http://www.le-message.org
On our dashmacmini3 dashboards, we're getting:
DPKG_EXECUTABLE='/sw/bin/dpkg'
It's found by find_program at CMake configure time, but cpack does not
find this program (it's not in the PATH) at testing time.
What should we do about this?
I could just set DPKG_EXECUTABLE=OFF to circumvent the test on these 3
dashboards for now... But I'd like a real fix for it. Seems like cpack
should find it if CMake's find_program can find it.
Thx,
Dav
[cmake-developers] Fwd: [CMake 0013366]: Ninja generator on windows does not take everything into account when checking the command line length limit
Can we just put the link step into the response files? Original Message Subject: [CMake 0013366]: Ninja generator on windows does not take everything into account when checking the command line length limit Date: Sun, 1 Jul 2012 16:59:52 -0400 From: Mantis Bug Tracker To: bill.hoff...@kitware.com The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=13366 == Reported By:Josh Faust Assigned To: == Project:CMake Issue ID: 13366 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2012-07-01 16:59 EDT Last Modified: 2012-07-01 16:59 EDT == Summary:Ninja generator on windows does not take everything into account when checking the command line length limit Description: When generating the ninja build files, on windows cmake will check the command line length and generate a response file if it's too long. It does this by checking the args and the build line passed to the ninja rule. This does not take into account, though, what the ninja rule actually expands to including any variables passed such as link flags, full executable path, etc. CMake sets the command line limit to 8000 characters on windows, though the actual limit is 8192. I'm assuming it's set to 8000 because it's trying to account for the lack of these flags, but this is not always enough. In rare cases the build can still fail with a "The command line is too long." error. In my specific case, these extra flags account for ~500 characters, while cmake only actually checks http://www.cmake.org/Bug/view.php?id=5058#c7700 characters -- and added together they're above the 8192 limit. The quick fix seems to be changing the max command line to be shorter (say, 7000) in cmNinjaNormalTargetGenerator.cxx:483. The real fix would be to retrieve the rule and expand all the variables in the command, which I do not see an easy way of doing after a quick look through the code. == Issue History Date ModifiedUsername FieldChange == 2012-07-01 16:59 Josh Faust New 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] new Generator
On 7/2/2012 10:25 AM, J Decker wrote: lcc lcc-win32/64 Using nmake,jom, gmake or ninja that should not require a new generator. Just a few platform files. See Modules/Platform: altneratively some other flavors of visual studio projects These would most likely be sub-classes of the existing generators. What flavors where you thinking of? (chocolate, vanilla?) :) Might also be just a flag or two set on existing generators. -Bill -- Bill Hoffman Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 bill.hoff...@kitware.com http://www.kitware.com 518 881-4905 (Direct) 518 371-3971 x105 Fax (518) 371-4573 -- 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] new Generator
On Mon, Jul 2, 2012 at 6:55 AM, Bill Hoffman wrote: > On 6/21/2012 12:10 PM, J Decker wrote: >> >> Is tehre anywhere that I can find a howto of how to approach creating >> a new genreator? >> -- > > > What generator are you planning to write? > lcc lcc-win32/64 altneratively some other flavors of visual studio projects > -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 -- 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] new Generator
On 6/21/2012 12:10 PM, J Decker wrote: Is tehre anywhere that I can find a howto of how to approach creating a new genreator? -- What generator are you planning to write? -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
