Re: [cmake-developers] Failures re bzip2 in the dashboard

2013-02-20 Thread Richard Wackerbarth
ctest version 2.8.10.20121106-g262ff

I blew away the CMake-build tree.

 New revision of repository is: aaa9ccf325b386d8b500c0b95a2cac1409375d51

It failed again.

Richard

On Feb 20, 2013, at 12:19 PM, Brad King brad.k...@kitware.com wrote:

 On 02/20/2013 01:06 PM, Richard Wackerbarth wrote:
 After noticing the failure, I went back and linked in my old stable 
 version of ctest (from November).
 
 CMake Error at Utilities/cmlibarchive/CMakeLists.txt:916 (MESSAGE):
  pid_t doesn't exist on this platform?
 
 Are you saying it still fails?  In a fresh tree with no pre-existing
 CMakeCache.txt?  It should be fixed in the latest upstream 'next' branch.
 
 Thanks,
 -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] ReactOS: Important filed bug reports went to backlog en masse

2012-08-14 Thread Richard Wackerbarth
Colloquy http://colloquy.info/downloads.html works well for me.


On Aug 14, 2012, at 10:18 AM, David Cole wrote:

 Sorry about that -- I did indeed miss that you were asking to chat with me by 
 IRC or some other IM.
 
 How about just a G+ chat session? Or can you recommend a Mac or Windows IRC 
 client I could use?
 
 
 On Tue, Aug 14, 2012 at 11:12 AM, Amine Khaldi amine.kha...@reactos.org 
 wrote:
 Hello,
 
 I missed to reply to all, in my reply, and I only found out after receiving 
 no reply from David even though he's been replying in the list (so this must 
 be some policy that I'm not aware of). Here goes:
 
 
  Original Message 
 Subject:  Re: [cmake-developers] ReactOS: Important filed bug reports 
 went to backlog en masse
 Date: Mon, 13 Aug 2012 15:30:34 +0100
 From: Amine Khaldi amine.kha...@reactos.org
 To:   David Cole david.c...@kitware.com
 
 Hi David,
 
  I certainly did not mean to offend anyone with my en masse move of
  issues to 'backlog' -- thanks for speaking up.
 
  I would like to make sure that you guys can continue to use CMake for
  ReactOS.
 Thank you, we were surprised to see the long awaited bugs simply 
 disappear, we thought there are just more important things that you guys 
 are working on, so we were patient.
 
  I've got to run right now, but I will reply again tomorrow
  when I have some more time. Do you have time for a quick phone call or
  Google+ hangout this week sometime, so I can understand better what
  your issues are? (And why nobody adopted them when they appeared on
  the mailing list in the form of your bug reports...)
 Due to my net speed, I'm afraid the best we can do is a realtime text 
 conversation, so if irc or any other IM is an option, please let me know 
 and I'll be ready.
 
 Thank you,
 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
 
 --
 
 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

[cmake-developers] CMake + Ninja working almost everywhere

2012-07-19 Thread Richard Wackerbarth
On Jul 19, 2012, at 9:32 AM, Bill Hoffman wrote:

 On 7/19/2012 12:30 AM, Claus Klein wrote:
 I am happy to see it works now and Ninja is eanabled and Mac
 Yes, it is passing all test on the Mac.  There was one build error last night 
 but I see that has been fixed this morning.  So, thanks to Nico and Peter for 
 all the hard work in getting this working!  I am pretty sure CMake is now the 
 only ninja generator that works on linux, Windows and Mac, and can create OSX 
 bundles and apps, and do depend information on Windows!
 
 The only thing left that I would like todo someday is to figure out how to 
 get Fortran depends to work.
 
 -Bill

After the fiasco on Tuesday night's build, I manually recovered all of my ninja 
builds and, with only one exception, they all are running on MacOSX, Linux, and 
FreeBSD. (I don't have any Windows builds).

I'm going to update the system version of ctest (which drives the nightly 
builds) on all of my machines so that I can remove some of fragility caused by 
bootstrapping the ninja builds off of the regular nightly builds.  Is there 
anything else that I should change in the build configurations at the same time?

The remaining issue is that the FreeBSD build seems to show some random 
failures on the coverage test. I don't have bullseye, etc. installed on that 
machine. So, I am suspecting that the error reflects some race condition in 
forming the output stream under heavy parallel building.  Would someone 
familiar with the test please take a look at 

http://open.cdash.org/testDetails.php?test=153966298build=2449990

Richard



--

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] CMake + Ninja working almost everywhere

2012-07-19 Thread Richard Wackerbarth
That's the kind of effect that I suspected.  So, is this an error in CMake, 
Ninja, or FreeBSD ?

On Jul 19, 2012, at 10:19 AM, Bill Hoffman wrote:

 On 7/19/2012 10:55 AM, Richard Wackerbarth wrote:
 The remaining issue is that the FreeBSD build seems to show some
 random failures on the coverage test. I don't have bullseye, etc.
 installed on that machine. So, I am suspecting that the error
 reflects some race condition in forming the output stream under heavy
 parallel building.  Would someone familiar with the test please take
 a look at
 
 http://open.cdash.org/testDetails.php?test=153966298build=2449990
 
 Looks like it is failing because stdin and stderr are not sync'ed the same as 
 on other systems.
 
 Required regular expression not found.Regex=[Process file.*XINDEX.m.*Total 
 LOC:.*127.*Percentage Coverage: 85.83.*
 ]
 
 Here is the output:
 
 /home/dashboard/BotFarm/Chameleon-12/CMake/Ninja/CMake/Source/CTest/cmCTestCoverageHandler.cxx:476
  Process file: 
 /usr/home/dashboard/BotFarm/Chameleon-12/CMake/Ninja/CMake-build/Testing/MumpsCoverage/VistA-FOIA/Packages/Toolkit/Routines/XINDEX.m
 
 ...
 /home/dashboard/BotFarm/Chameleon-12/CMake/Ninja/CMake/Source/CTest/cmParseGTMCoverage.cxx:93
  Can not find mumps file : XLFDT  referenced in this line of mcov data:
 [^ZZCOVERAGE(XLFDT,HTFM,0)=2:0:0:0]
 
 ...
 /home/dashboard/BotFarm/Chameleon-12/CMake/Ninja/CMake/Source/CTest/cmParseGTMCoverage.cxx:93
  Can not find mumps file : XLFDT  referenceotal LOC:   127
   Percentage Coverage: 85.83%
 d in this line of mcov data:
 
 
 You can see the Percent Coverage stuff is getting mixed in with the other 
 output...
 
 
 -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] Why not disable the Unix Makefiles generator for Darwin?

2012-07-14 Thread Richard Wackerbarth
By default, Ninja is disabled on Darwin because it has NEVER worked for a 
number of the scenarios in the test suite.
These have to do with building OSX packages, etc.) If YOU need to use certain 
ninja capabilities and are not affected by those shortcomings, you can easily 
build a version with ninja enabled.

As far as same problems with Unix Makefile generator, then that is because 
you are trying to do something out of the mainstream and THAT aspect (MacPorts 
gcc-4.7 ?) is broken. It doesn't really have to do with ninja support.

However, CMake never claimed to support compilers other than the ones released 
by the vendor. It's a nice extra when it does. But failing to do so is not 
mission critical.

Correctly building Mac OSX packaging IS a requirement.

Richard

--

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] ninja bug

2012-04-18 Thread Richard Wackerbarth
Let me know if someone needs information from the run which has not been posted 
to the dashboard.
I can bring the machine online and retrieve things.

Richard

On Apr 18, 2012, at 11:04 AM, Bill Hoffman wrote:

 Any of the ninja folks have an idea why this test fails on FreeBSD:
 
 http://open.cdash.org/testDetails.php?test=140695467build=2197189
 
 Run Build Command:/usr/local/bin/ninja
 ninja: ERROR: dependency cycle: CMakeFiles/bar.dir/bar.cxx.o - 
 CMakeFiles/bar.dir/bar.cxx.o
 
 I am guessing something wrong with the output of -M on the machine?
 
 -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] ninja status

2012-04-08 Thread Richard Wackerbarth
FYI: Intentionally, Chameleon-00.NFSNet forces the building of CMake to allow, 
and subsequently use, Ninja.
It does so by placing the following line in the configuration

set(dashboard_cache CMAKE_ENABLE_NINJA:BOOL=TRUE)

As you can see from the recent dashboards, enabling this option does not 
produce a version which fails when used with Unix Makefiles.
However, a recent change has broken its ability to configure to use Ninja as 
the make executable (a week ago it was configuring OK).

 Error(s) when configuring the project
 ./Branch.sh: line 84: 67233 Segmentation fault  ${CTEST} -S 
 ${CTEST_CONFIGURATION_FILE} -V

The ...-Ninja- builds use the nightly version of CMake that was produced 
minutes earlier.

It seems to me that we need to add some simple unit tests for each of the 
generators.
There should be both a configure test and a simple make test.
It should be reasonable to run the former even if the latter cannot run because 
resources are missing.

It is appropriate to have platform sensitive switches to to turn particular 
generators OFF by default.
When they are forced ON, we could issue a warning, e.g. The Ninja generator is 
experimental on this platform

On Apr 8, 2012, at 7:47 AM, Peter Kümmel wrote:

 On 08.04.2012 14:12, Óscar Fuentes wrote:
 Peter Kümmelsyntheti...@gmx.net  writes:
 
 I know ninja should not be enabled on other platforms than Linux, and it 
 wasn't,
 even with my patch. This was not a try the enable ninja through the 
 backdoor!
 
 I've fixed it and changed the message so it could not happen again:
 http://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=2a081a2b3a3064530fe173a2930828e2232e844b
 
 There is a typo on the patch:
 
  SET(CMAKE_ENABLE_NINJA ${_CMAKE_DEFAULT_NINJA_VALUE} CACHE BOOL
 -Enable the ninja generator for CMake. On Windows and OSX broken FORCE)
 +Enable the ninja generator for CMake. On Windows and OSX broken)
 
 [...]
 
  ELSE()
 -  MESSAGE(STATUS Ninja generator disabled, enforce with -DENABLE_NINJA=ON)
 +  MESSAGE(STATUS Ninja generator disabled, enforce with 
 -DCMAKE_ENABLE_NINJA=ON)
 
 You mention CMAKE_USE_NINJA on the last message, when it should be
 CMAKE_ENABLE_NINJA.
 
 
 Thanks, CMAKE_ENABLE_NINJA is the name of the macro.
 
 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

--

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] ninja broken on windows?

2012-02-16 Thread Richard Wackerbarth
What are we trying to accomplish here?

I have set up 3 of my machines (1 each MacOSX, FreeBSD, and Linux --- like my 
housekeeper, I don't do Windows) to submit nightly builds using the Ninja 
generator. That will test the impact of changes in the generator.

But it appears that we may also need to be testing the evolving state of ninja.
For that, it would seem that we need a different dashboard and (at least as a 
wrapper) a CMake driven build of ninja.

Am I missing something?

Richard

On Feb 16, 2012, at 3:46 PM, Peter Kümmel wrote:

 On 16.02.2012 21:38, Bill Hoffman wrote:
 On 2/16/2012 2:57 PM, Peter Kümmel wrote:
 
 They are not interested.
 There is another patch in the pipeline but with
 this the current generator doesn't work.
 
 Use the official ninja and drop Win atm.
 
 Bummer.  I am most interested in windows.  Would love to stop using
 
 OK, I could update my branch with the official one, disable all
 Windows specific patches on Linux. This way, testing on Linux is like
 testing against the official ninja, and an Windows we have intermediate
 version until ninja supports win32.
 
 But I don't wanna touch the generator atm because I don't like the actual
 proposal for response file support.
 
 
 gmake...  Seems like they are doing lots of stuff with .d files for
 windows.  So, they seem interested in supporting the platform.  Is there
 something we can change in the cmake generator to make it work with the
 way ninja is today, and will be for the foreseeable future?
 
 
 -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] Git fun

2011-12-05 Thread Richard Wackerbarth
James,

You have not defined stage as the nickname for the remote repository.

If you set it up with  `git remote add stage g...@cmake.org:stage/cmake.git`, 
then your push syntax should work.
Alternately, `git push g...@cmake.org:stage/cmake.git CUDAv3.2PathChanges` 
would push using the full name.

Richard

On Dec 5, 2011, at 4:41 PM, James Bigler wrote:

 I used to be able to push directly to next, because I'm a Module maintainer.  
 Now I get this:
 
 $ git push origin next
 Enter passphrase for key '/Users/jbigler/.ssh/id_rsa': 
 Counting objects: 12, done.
 Delta compression using up to 2 threads.
 Compressing objects: 100% (7/7), done.
 Writing objects: 100% (7/7), 1001 bytes, done.
 Total 7 (delta 5), reused 0 (delta 0)
 --
 James Bigler jamesbig...@gmail.com may not push directly to this repository.
 Use the CMake Topic Stage to merge your topic:
   http://www.cmake.org/Wiki/CMake/Git#Topic_Stage
 --
 error: hook declined to update refs/heads/next
 To g...@cmake.org:cmake.git
  ! [remote rejected] next - next (hook declined)
 error: failed to push some refs to 'g...@cmake.org:cmake.git'
 
 
 OK. So I tried to do a stage merge:
 
 $ git checkout CUDAv3.2PathChanges
 Switched to branch 'CUDAv3.2PathChanges'
 
 $ git push stage HEAD
 fatal: 'stage' does not appear to be a git repository
 fatal: The remote end hung up unexpectedly
 
 
 $ git branch
 * CUDAv3.2PathChanges
   master
   next
   topics/CudaRTEmuLibraryForCUDA30
   topics/FindCUDA-allow-g3
   topics/FixCudaVersionAfterFirstRun
 
 Can anyone help with with my ignorance of Git?  The only thing I used Git for 
 is CMake and I just don't use it enough to learn all the nooks and crannies 
 of this tool.
 
 Thanks,
 James
 
 --
 
 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] Keeping unit tests useful and splitting feature support from platform support

2011-10-16 Thread Richard Wackerbarth

On Oct 16, 2011, at 6:21 PM, Stephen Kelly wrote:

 On 10/16/2011 02:56 PM, Richard Wackerbarth wrote:
 On Oct 16, 2011, at 6:54 AM, Stephen Kelly wrote:
 Having so many old platforms and compilers on the dashboard going red with
 failure
 So, I think I'm talking about two separate issues. One is whether failures
 on platforms I don't care about are my responsibility, and the other is
 ensuring that unit tests fail when something breaks.
 Steve,
 
 This is the backward compatibility issue that plagues all projects.

 I think that it is YOUR responsibility to make any new feature work on all 
 supported platforms.
 If you cannot support some particular platform, you can petition the CMake 
 community to drop support for certain platforms. But it should not be your 
 unilateral choice to do so.
 
 Richard
 
 Hi Richard,
 
 I'm trying to find a solution to an issue I perceive about unit tests not 
 counting for much if we only run them when they are testably already working.

Steve,

In many respects, I agree with your concern about the unit test situation. 
(More on that later)
However, what I was really addressing was the expected platform support issue.

With your latest message, it appears that your reference platforms are the 
same as my supported platforms.
In effect, if some platform is not included in the reference platform set, it 
becomes an unsupported platform.
Deciding to drop support for any platform should not be a choice made by the 
authors of features, but rather needs to be a well-thought-out community 
decision.

With respect to your comparison to Qt, I see a fundamental difference. It is 
one thing to say Qt has this existing feature set. If you want to add a new 
platform, then you need to provide the implementation. On the other hand, if 
you want to add a feature, then you should have to provide the implementation 
for all of the already working platforms.

As for the unit test situation, I agree that the present CMake infrastructure 
addresses only a portion of the development cycle.
Acceptance into next implicitly implies that the feature is expected to 
work on ALL supported platforms.

The nightly builds are very effective in assuring that regression issues do not 
occur.

But, since none of the feature developers have access to all of the supported 
platforms, I think that a scheme for trial runs against the supported 
platforms is needed.

My vision would be to have a system whereby a temporary branch could be 
submitted for a single dashboard build. But it would not be a part of next. 
Only those features that work across all platforms would be committed for the 
continuing runs on the next branch.

In my case, CPU identification does not work on FreeBSD (unless you install 
Linux emulation). To fix it properly, the code really should be refactored. 
However, since I have no access to Windows systems, I cannot considering doing 
the needed refactoring because I don't have adequate testing resources.

Richard

 There may be other ways to make that work, but your response indicates that 
 you strongly think what I proposed is the wrong approach. You might be right, 
 I don't know.
 
 I came up with this proposal after looking at the Qt approach to platform 
 support -- They define reference platforms, and if others want to make Qt 
 work on WinCE for example, they can do that work and be the experts in it. I 
 don't mean to say that what Qt does will automatically work for CMake 
 (unlikely in fact). I'm trying to explore options.
 
 All the best,
 
 Steve.

--

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