David Abrahams wrote:
Click on Show Filters, and you can create a filter that shows only errors,
warnings or
other items that you want. The idea will be to be able to save the queries and
create
your own custom views for different purposes.
Nice capability; not a great interface. If I want
on Wed Mar 04 2009, Bill Hoffman wrote:
> David Abrahams wrote:
>
>>> Another new feature in CTest/CDash development heads which may be of
>>> interest
>>> to Boost is support for subproject labeling. See their main dashboard page
>>> here:
>>>
>>>
>>> http://trilinos-dev.sandia.gov/cdash/i
David Abrahams wrote:
Another new feature in CTest/CDash development heads which may be of interest
to Boost is support for subproject labeling. See their main dashboard page here:
http://trilinos-dev.sandia.gov/cdash/index.php?project=Trilinos&date=2009-02-27
Functionally, it's pretty dar
troy d. straszheim wrote:
Maybe I'm missing something... how do I tell what code has been
compiled? By the build timestamp?
CTest's submissions are broken into "Nightly", "Experimental", and
"Continuous" categories. Look at a page like this:
http://trilinos-dev.sandia.gov/cdash/index.php
David Abrahams wrote:
Trilinos is a very large project, so they label pieces of it in CMake,
CTest propagates the labels with failure reports, and CDash interprets
the labels to break results down by subproject. The same thing could
be used for Boost's library hierarchy.
Awesome.
Maybe I'
on Tue Mar 03 2009, Brad King wrote:
> Brad King wrote:
>> The current CDash release will not understand CTest build submissions that
>> use this launcher interface, so one would need CDash from its SVN trunk to
>> try it.
>
> Sandia's Trilinos project is using CTest launchers with CDash from SV
Brad King wrote:
The current CDash release will not understand CTest build submissions that
use this launcher interface, so one would need CDash from its SVN trunk to
try it.
Sandia's Trilinos project is using CTest launchers with CDash from SVN trunk.
Here is an example page showing errors rec
troy d. straszheim wrote:
So the first order of business would be to remove this kind of thing:
set(CMAKE_CXX_COMPILE_OBJECT "\"${PYTHON_EXECUTABLE}\"
\"${BOOST_TEST_DRIVER}\" cxx_compile_object
${CMAKE_CXX_COMPILE_OBJECT}" )
We're 100% agreed on the need for this, as far as I can see.
A
troy d. straszheim wrote:
Further, I have to note that command-line VS builds should be
supported for one simple reason: nmake does not support parallel
builds and probably never will. This makes VS the easiest way of
running a parallel build on Windows (locally or distributed with
additional to
Ingo Albrecht wrote:
Note that vcbuild (the command line driver for VS builds) has command
line arguments for specifying strings to prefix log messages at various log
levels with. This should make log scraping of the compilation much more
reliable, although it still disgusts me. This does not wor
troy d. straszheim schrieb:
Brad King wrote:
troy d. straszheim wrote:
I don't quite get "That doesn't mean we can't test some tools without
log-scraping".
I see two different cases here. There's the developer working under
visual studio or emacs who wants to run some tests. This guy knows (
Brad King wrote:
troy d. straszheim wrote:
I don't quite get "That doesn't mean we can't test some tools without
log-scraping".
I see two different cases here. There's the developer working under
visual studio or emacs who wants to run some tests. This guy knows (or
should know) how to find w
on Mon Jan 19 2009, Brad King wrote:
> Hi Dave,
>
> I think some of the confusion is because my original posting proposed
> *two* different approaches to testing:
>
> 1.) Build all the (run) tests for one library into a single executable.
> Each test gets its own TU but the tests are linked tog
Hi Dave,
I think some of the confusion is because my original posting proposed
*two* different approaches to testing:
1.) Build all the (run) tests for one library into a single executable.
Each test gets its own TU but the tests are linked together. Execution
of the tests is delayed until test
on Thu Jan 15 2009, Brad King wrote:
> troy d. straszheim wrote:
>> I don't quite get "That doesn't mean we can't test some tools without
>> log-scraping".
>>
>> I see two different cases here. There's the developer working under
>> visual studio or emacs who wants to run some tests. This guy
on Thu Jan 15 2009, Brad King wrote:
> David Abrahams wrote:
>> * logfile scraping is too hopelessly fragile to make for a good testing
>> system, and there are better and possibly even easier alternatives.
>
> The question here is whether one wants to test with the same tools users
> might us
troy d. straszheim wrote:
> I don't quite get "That doesn't mean we can't test some tools without
> log-scraping".
>
> I see two different cases here. There's the developer working under
> visual studio or emacs who wants to run some tests. This guy knows (or
> should know) how to find what comp
Brad King wrote:
David Abrahams wrote:
* logfile scraping is too hopelessly fragile to make for a good testing
system, and there are better and possibly even easier alternatives.
The question here is whether one wants to test with the same tools users
might use to build the project. If one
David Abrahams wrote:
> * logfile scraping is too hopelessly fragile to make for a good testing
> system, and there are better and possibly even easier alternatives.
The question here is whether one wants to test with the same tools users
might use to build the project. If one user's tool doesn
on Thu Jan 15 2009, "troy d. straszheim" wrote:
> What to you say to the original question about the preferred format?
Don't know what to say yet, sorry.
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
___
Boost-cmake mailing list
Boost-
on Thu Jan 15 2009, "Beman Dawes" wrote:
>> Have you tried helping a Boost newbie go through the process of
>> building and installing Boost lately? It's extremely painful, but we
>> don't see that pain because we've all gone through the initial hurdles
>> of getting bjam setup just right for ou
on Wed Jan 14 2009, Brad King wrote:
> Hi Folks,
>
> I'm considering attending BoostCon 2009 to provide developer-level
> CMake expertise,
Yes, please!
> and I'm looking into proposing a session as Hartmut
> requested.
Also yes please.
> In preparation I've downloaded and tried the curren
Brad King wrote:
The boost-cmake-for-users talk could of course reflect whatever we
get done between now and then.
Has anyone submitted anything for this yet? We (Kitware) can present
our CMake/CTest/CDash/CPack software process in general, but the
boost-specific part should probably be done
David Abrahams wrote:
on Wed Jan 14 2009, "troy d. straszheim" wrote:
Hi Brad,
There is a lot to discuss here. I'll go back later and make specific comments.
It'd
be great to talk in person at boostcon, (boostcon rocks, by the way.)
I understand/agree with a lot of your points (especially
troy d. straszheim wrote:
> There is a lot to discuss here. I'll go back later and make specific
> comments. It'd be great to talk in person at boostcon, (boostcon rocks,
> by the way.)
>
> I understand/agree with a lot of your points (especially bulkiness, and
> the need to reduce the number of
On Wed, Jan 14, 2009 at 6:16 PM, Doug Gregor wrote:
> On Wed, Jan 14, 2009 at 3:02 PM, Beman Dawes wrote:
>> On Wed, Jan 14, 2009 at 11:52 AM, Brad King wrote:
>>>..
>>> One of the goals of CMake is to let developers use their favorite
>>> native tools.
>>
>> Horrors! As a boost developer, the l
On Thu, Jan 15, 2009 at 9:30 AM, David Abrahams wrote:
>
> on Wed Jan 14 2009, "troy d. straszheim" wrote:
>
>> Hi Brad,
>>
>> There is a lot to discuss here. I'll go back later and make specific
>> comments. It'd
>> be great to talk in person at boostcon, (boostcon rocks, by the way.)
>>
>> I
on Wed Jan 14 2009, "troy d. straszheim" wrote:
> Hi Brad,
>
> There is a lot to discuss here. I'll go back later and make specific
> comments. It'd
> be great to talk in person at boostcon, (boostcon rocks, by the way.)
>
> I understand/agree with a lot of your points (especially bulkiness, a
On Wed, Jan 14, 2009 at 3:02 PM, Beman Dawes wrote:
> On Wed, Jan 14, 2009 at 11:52 AM, Brad King wrote:
>>..
>> One of the goals of CMake is to let developers use their favorite
>> native tools.
>
> Horrors! As a boost developer, the last thing in the world I want is
> to have to know anything a
On Wed, Jan 14, 2009 at 11:52 AM, Brad King wrote:
>..
> One of the goals of CMake is to let developers use their favorite
> native tools.
Horrors! As a boost developer, the last thing in the world I want is
to have to know anything about a platform's native tools. I just want
to be able to enter
Hi Brad,
There is a lot to discuss here. I'll go back later and make specific comments.
It'd be great to talk in person at boostcon, (boostcon rocks, by the way.)
I understand/agree with a lot of your points (especially bulkiness, and the need
to reduce the number of toplevel targets), in m
Hi Folks,
I'm considering attending BoostCon 2009 to provide developer-level
CMake expertise, and I'm looking into proposing a session as Hartmut
requested. In preparation I've downloaded and tried the current
system and read back through some of the discussion on this list:
http://thread.gman
32 matches
Mail list logo
