On Fri 05 Sep 2003 14:51, Abe Timmerman <[EMAIL PROTECTED]> wrote:
> [ Most of the Dutch is (loosly) translated ]
> Op een zonnige zomerdag (Friday 05 September 2003 12:28), schreef H.Merijn 
> Brand:
> 
> > On Fri 05 Sep 2003 10:43, Campo Weijerman <[EMAIL PROTECTED]> wrote:
> > > [EMAIL PROTECTED] (H.Merijn Brand) writes:
> > > > On Fri 05 Sep 2003 01:09, Abe Timmerman <[EMAIL PROTECTED]> wrote:
> > > > > Hoi Merijn,
> > > > >
> > > > > > Automated smoke report for 5.6.1 patch 21024 on hp-ux - b.11.00
> > > > > > (9000/800/2 cpus) (a5) using  version
> > > >
> > > >                      ^        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > > ??
> > > >
> > > > Kun je de versie van cc niet vinden?
> > >
> > > Volgens mij komt dit omdat deze header wordt opgebouwd met het
> > > resultaat van de allerlaatste build in je smoke matrix.  Als die mis
> > > gaat, zoals hier (zie onder) krijg je bogus data in de header.
> > > Tenminste, zo was mijn ervaring met Test::Smoke <= 1.17
> 
> <translation density="high">
> C-compiler info is only retrieved from the last build. No successfull 
> Configure means no c-compiler info.
> </translation>
> 
> Yup, that has always been a problem. I've been thinking about this, but 
> haven't thought up a way to do this without breaking the current "mktest.out" 
> format, so that'll have to go in 1.19 (which will replace mkovz.pl).
> 
> > Hah, en het was niet eens de bedoeling om dit op de reports te posten :)
> 
> I don't mind discussing these issues on <[EMAIL PROTECTED]>, they should be.
> 
> > Heb je suggesties voor een betere benadering? En hoe zou je omgaan met
> 
> <translation>Any suggestions?</translation>
> 
> > ==
> >
> > -Dcc=gcc
> > ==
> 
> My personal view on this is: "Create a separate smoke config for each 
> c-compiler and send multiple (smaller) reports from the same box.". I think

But are *much* harder to start from cron, since you have to write wrapper
scripts that start the separated smokes in sequence (we don't want them
running side by side unless you have more than 2 CPU's), and then the smoke
guards (+HH:MM, HH:MM) will not work anymore.

> that will reveal more detailed information about failures and the environment 
> in which they occur.

True, but still leaves the HP-UX problem where we have different compilers for
gcc in 32 and 64 bit mode, and splitting them up in two separate smokes will
only aggravate the problem I just mentioned.

> The smoke_db has a decent interface to give you the information you may want 
> for specific platforms or even cross platform/specific compiler version. That 
> is why it is there (thanks Alain)!

Yes.

> I now think of the smoke-reports in terms of input for smoke_db (whilst still 
> human readable).

I don't yet, but you've already managed to convert a lot of old smoke habits :)

> > Automated smoke report for 5.6.1 patch 21024 on hp-ux - b.11.00 (9000/800/2
> > cpus) (a5) using cc version B.11.11.25985.GP
> >            gcc version 3.3
> >            gcc64 version 3.3
> > Report by Test::Smoke v1.18.05 (perl 5.8.0) [5 hours 33 minutes]
> 
> Although that looks nice, it needs more work as I want the failures (and 
> successes!) linked with the compiler. It needs an extra reference to/from the 
> configuration. Introducing that, will also need more complex parsing for 
> smoke_db.

That's why it's a module <duck>
Though most of us smokers know more than avarage about the matter, it's still
not an end-user issue, and I've already seen a lot of reports with -Dcc=...
Nick is one of them. (Nick should upgrade anyway: hint)

> Here is the smoke_db:
> 
>       http://cpanplus.keradel.com/cgi-bin/smoke_db.cgi

-- 
H.Merijn Brand        Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using perl-5.6.1, 5.8.0, & 5.9.x, and 806 on  HP-UX 10.20 & 11.00, 11i,
   AIX 4.3, SuSE 8.2, and Win2k.           http://www.cmve.net/~merijn/
http://archives.develooper.com/[EMAIL PROTECTED]/   [EMAIL PROTECTED]
send smoke reports to: [EMAIL PROTECTED], QA: http://qa.perl.org


Reply via email to