Re: build test farm [was Re: [Chicken-users] Cmake broken again: paths are not quoted]
felix winkelmann wrote: On 7/21/06, Bill Hoffman <[EMAIL PROTECTED]> wrote: We should be able to setup a chicken dashboard at Kitware. But only the server end. You will need clients to run the tests and populate the dashboard. We have a public dashboard that you can try this on. If you enable dashboards in the cmake files of chicken the default server is the kitware public dashboard. This is a very generous offer, and if somebody wants to pick up here and take this over, I'd be very grateful. Unfortunately I can't manage this in the moment, as I have a million other things to do. Anybody interested in becoming test-organizer? To be honest, I really want someone else to take responsibility for this. I feel like if I don't push for other people getting involved with CMake and related technologies, I'm going to get stuck doing everything, and in the real world I simply won't do it / can't do it. I've been working on this build stuff for 9 months and haven't written a lick of OpenGL code. I really want to move on. Also remember, I'm dirt poor, I need a job, I'm about to overdraft my bank account to pay rent. I can't afford the kind of attention I've been giving anymore, and even that is not enough it seems. I'm happy to keep stewarding and improving the build, but I really don't want to do the heavy lifting on test stuff. I think it's time for there to be more than 1 person with "serious buy-in" to CMake paradigms. I mean, what if I get hit by a truck? Well, you've got the source, but I think the interest would languish. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: build test farm [was Re: [Chicken-users] Cmake broken again: paths are not quoted]
On 7/21/06, Bill Hoffman <[EMAIL PROTECTED]> wrote: We should be able to setup a chicken dashboard at Kitware. But only the server end. You will need clients to run the tests and populate the dashboard. We have a public dashboard that you can try this on. If you enable dashboards in the cmake files of chicken the default server is the kitware public dashboard. This is a very generous offer, and if somebody wants to pick up here and take this over, I'd be very grateful. Unfortunately I can't manage this in the moment, as I have a million other things to do. Anybody interested in becoming test-organizer? cheers, felix -- http://galinha.ucpel.tche.br:8081/blog/blog.ssp ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: build test farm [was Re: [Chicken-users] Cmake broken again: paths are not quoted]
We should be able to setup a chicken dashboard at Kitware.
But only the server end. You will need clients to run the tests
and populate the dashboard. We have a public dashboard that you can
try this on. If you enable dashboards in the cmake files of chicken
the default server is the kitware public dashboard.
Here is the link:
http://public.kitware.com/Public/Dashboard/20060721-0100-Nightly/Dashboard.html
Here is a link to other dashboards at kitware:
http://public.kitware.com/dashboard.php
Why don't you try a few submissions and see if it is what you want, and
then we can set up a chicken specific dashboard.
To get things going:
http://www.cmake.org/Wiki/CMake_Testing_With_CTest
Basically:
ENABLE_TESTING()
INCLUDE(Dart)
Then make Experimental should send an experimental submission to the
public dashboard.
-Bill
At 07:21 PM 7/20/2006, Brandon J. Van Every wrote:
>Toby Butzon wrote:
>>
>>On Thu, Jul 20, 2006 at 04:00:48PM -0400, John Cowan wrote:
>>
>>>
>>>Sourceforge.net does provide a "compile farm" that provides the ability
>>>to build on multiple platforms, though Felix would have to move Chicken
>>>there to take advantage of it. It doesn't do Windows, though.
>>>
>>
>>
>>Hmm... maybe it would be possible to construct our own, with volunteered
>>resources. The normal process would be to pull from darcs, try the build,
>>and post apparent success or failure (maybe to a page on the swiki?). If
>>it fails, a log could be posted, too. (A similar alternate process would
>>exist for checking release tarballs, but this would run only when a new
>>tarball has been released, so as not to waste cycles rebuilding something
>>that's already been tested.) I would envision this being a chicken
>>script ("compilefarm.egg"?) and it'd be triggered by cron/task
>>scheduler, on the volunteer's terms (so volunteers are in full control
>>of how much it encroaches upon their system).
>>
>
>I think it's worth asking William Hoffman of Kitware whether they can provide
>CMake + CTest + Dashboard testing resources. If they don't provide the
>testing machines themselves, I'm sure they can at least give us pointers on
>how to set up such a thing, and what the consequences / impacts are. I do not
>believe CMake currently supports Darcs, that's an issue. But perhaps we can
>scare someone up to deal with that issue, for CMake's benefit.
>
>>
>>
>>I don't think the program to do it would be all that complicated; the
>>question is, could we find volunteers to give up some cpu cycles on
>>various platforms? (I for one have at least a Windows box and a Linux
>>2.6 box I leave always running that would be offered.)
>>
>
>It would be worth knowing if the Dashboard can function in a distributed or
>peer-to-peer manner.
>
>>
>>
>>The product would be a page with a table on it, showing each volunteered
>>machine, architecture and OS, build schedule, when the last build ran, and
>>success/failure. (And, if failure, a link to the log of what happened.)
>>
>
>I feel that this sort of reportage reinvents the Dashboard, and thus is a
>waste of open source development resources. Unless someone out there is such
>a Chicken web guru that they deliver proof-of-concept in a few days work.
>
>>
>>
>>Maybe this would also provide some more incentive for a test suite, and
>>at a minimum, we could start with one for (use srfi-1) and whatever other
>>problems might be diagnosed after "successfully" building.
>>
>>I'd like to hear what others think about this.
>>
>
>I think test suites need no additional motive. Even without a nightly build,
>test suites are quite valuable to development. Bigloo has an excellent test
>suite, for instance. The question is, will someone do the work of providing
>and integrating a test suite.
>
>
>Cheers,
>Brandon Van Every
>
___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: build test farm [was Re: [Chicken-users] Cmake broken again: paths are not quoted]
felix winkelmann wrote: On 7/20/06, Toby Butzon <[EMAIL PROTECTED]> wrote: I'd like to hear what others think about this. I think this is a very good idea (but I won't move chicken to sourceforge, their servers are too unreliable, in my experience). I would also note I'm unwilling to give up Darcs to gain automated build testing. Dual existence with Darcs and Subversion is reasonable, but of course it introduces delay in the testing. That's a bad or a good thing, depending on your perspective. I think a Darcs capable solution is to be preferred, but I don't know if there is such a solution. I have no idea how much work it would take to get CTest and Dart Dashboard working with Darcs. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: build test farm [was Re: [Chicken-users] Cmake broken again: paths are not quoted]
On 7/20/06, Toby Butzon <[EMAIL PROTECTED]> wrote: I'd like to hear what others think about this. I think this is a very good idea (but I won't move chicken to sourceforge, their servers are too unreliable, in my experience). Now, who is going to volunteer cycles? cheers, felix -- http://galinha.ucpel.tche.br:8081/blog/blog.ssp ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: build test farm [was Re: [Chicken-users] Cmake broken again: paths are not quoted]
Toby Butzon wrote:
On Thu, Jul 20, 2006 at 04:00:48PM -0400, John Cowan wrote:
Sourceforge.net does provide a "compile farm" that provides the ability
to build on multiple platforms, though Felix would have to move Chicken
there to take advantage of it. It doesn't do Windows, though.
Hmm... maybe it would be possible to construct our own, with volunteered
resources. The normal process would be to pull from darcs, try the build,
and post apparent success or failure (maybe to a page on the swiki?). If
it fails, a log could be posted, too. (A similar alternate process would
exist for checking release tarballs, but this would run only when a new
tarball has been released, so as not to waste cycles rebuilding something
that's already been tested.) I would envision this being a chicken
script ("compilefarm.egg"?) and it'd be triggered by cron/task
scheduler, on the volunteer's terms (so volunteers are in full control
of how much it encroaches upon their system).
I think it's worth asking William Hoffman of Kitware whether they can
provide CMake + CTest + Dashboard testing resources. If they don't
provide the testing machines themselves, I'm sure they can at least
give us pointers on how to set up such a thing, and what the
consequences / impacts are. I do not believe CMake currently supports
Darcs, that's an issue. But perhaps we can scare someone up to deal
with that issue, for CMake's benefit.
I don't think the program to do it would be all that complicated; the
question is, could we find volunteers to give up some cpu cycles on
various platforms? (I for one have at least a Windows box and a Linux
2.6 box I leave always running that would be offered.)
It would be worth knowing if the Dashboard can function in a
distributed or peer-to-peer manner.
The product would be a page with a table on it, showing each volunteered
machine, architecture and OS, build schedule, when the last build ran, and
success/failure. (And, if failure, a link to the log of what happened.)
I feel that this sort of reportage reinvents the Dashboard, and thus is
a waste of open source development resources. Unless someone out there
is such a Chicken web guru that they deliver proof-of-concept in a few
days work.
Maybe this would also provide some more incentive for a test suite, and
at a minimum, we could start with one for (use srfi-1) and whatever other
problems might be diagnosed after "successfully" building.
I'd like to hear what others think about this.
I think test suites need no additional motive. Even without a nightly
build, test suites are quite valuable to development. Bigloo has an
excellent test suite, for instance. The question is, will someone do
the work of providing and integrating a test suite.
Cheers,
Brandon Van Every
___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users
build test farm [was Re: [Chicken-users] Cmake broken again: paths are not quoted]
On Thu, Jul 20, 2006 at 04:00:48PM -0400, John Cowan wrote:
> Sourceforge.net does provide a "compile farm" that provides the ability
> to build on multiple platforms, though Felix would have to move Chicken
> there to take advantage of it. It doesn't do Windows, though.
Hmm... maybe it would be possible to construct our own, with volunteered
resources. The normal process would be to pull from darcs, try the build,
and post apparent success or failure (maybe to a page on the swiki?). If
it fails, a log could be posted, too. (A similar alternate process would
exist for checking release tarballs, but this would run only when a new
tarball has been released, so as not to waste cycles rebuilding something
that's already been tested.) I would envision this being a chicken
script ("compilefarm.egg"?) and it'd be triggered by cron/task
scheduler, on the volunteer's terms (so volunteers are in full control
of how much it encroaches upon their system).
I don't think the program to do it would be all that complicated; the
question is, could we find volunteers to give up some cpu cycles on
various platforms? (I for one have at least a Windows box and a Linux
2.6 box I leave always running that would be offered.)
The product would be a page with a table on it, showing each volunteered
machine, architecture and OS, build schedule, when the last build ran, and
success/failure. (And, if failure, a link to the log of what happened.)
Maybe this would also provide some more incentive for a test suite, and
at a minimum, we could start with one for (use srfi-1) and whatever other
problems might be diagnosed after "successfully" building.
I'd like to hear what others think about this.
--
Toby Butzon
___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users
