FAQ
1. Once I start a smoke running, is it safe to overwrite files in the
source directory? (cdir in the config file).

2. How do I set flags that I would normally pass to Configure, e.g.
compiler flags.

I have four Solaris boxes running 2.6, 2.7, 2.8 & 2.9, all patched up and
ready to go. I also have a local 'p4 sync'd copy of the 5.6.x, 5.8.x and
5.10.x branches from the perl repository and I'm in the process of writing a
script to drive all four machines. I'm intending that the script will sync
with the repository a couple of times a day, and automatically kick off
smokes on machines as they become idle. Hopefully once it is running I
won't have to touch it.

--
Alan Burlison
--

Search Discussions

  • Abe Timmerman at Aug 7, 2003 at 10:22 am
    Op een zonnige zomerdag (Thursday 07 August 2003 00:51), schreef Alan
    Burlison:
    1. Once I start a smoke running, is it safe to overwrite files in the
    source directory? (cdir in the config file).
    Sure, that is probably the only way to keep your local copy of the source-tree
    up to date. You only need to take care that you don't start a smoke while
    doing that.
    2. How do I set flags that I would normally pass to Configure, e.g.
    compiler flags.
    Configure options are set in the build-configuration files (the defaults are
    perlcurrent.cfg [5.9 and 5.8] and perl562.cfg). Merijn has documented them
    pretty well and there is some more on that in the FAQ file.
    I have four Solaris boxes running 2.6, 2.7, 2.8 & 2.9, all patched up and
    ready to go. I also have a local 'p4 sync'd copy of the 5.6.x, 5.8.x and
    5.10.x branches from the perl repository and I'm in the process of writing
    a script to drive all four machines. I'm intending that the script will
    sync with the repository a couple of times a day, and automatically kick
    off smokes on machines as they become idle.
    F<configsmoke.pl> creates a little shellscript that starts the smokes, you
    could put an endless-loop around the

    /usr/bin/perl smokeperl.pl -c "$CFGNAME" $continue $* > smokecurrent.log 2>&1

    line. (But I'm no shell programmer)
    Hopefully once it is running I
    won't have to touch it.
    You might need to keep your eye on it for a bit, I've had trouble with
    Solaris-8 running out of processes (although I'm not sure if that is smoke
    related). And if we see test failures, you might need to investigate.

    I'll see if I can manage some sort of archive mechanism that archives the
    report and the smokeperl logfile so one can go back to them whilst in
    continous smoke-mode.

    Good luck,

    Abe
    --
    I think this requires more thought, therefore
    I'm excising the "promise" from perldelta and replacing it with more
    non-committal mumbling.
    -- Jarkko Hietaniemi on p5p @ 2002-05-27
  • Alan Burlison at Aug 7, 2003 at 2:29 pm

    Abe Timmerman wrote:

    Sure, that is probably the only way to keep your local copy of the source-tree
    up to date. You only need to take care that you don't start a smoke while
    doing that.
    That will work fine - thanks.
    2. How do I set flags that I would normally pass to Configure, e.g.
    compiler flags.

    Configure options are set in the build-configuration files (the defaults are
    perlcurrent.cfg [5.9 and 5.8] and perl562.cfg). Merijn has documented them
    pretty well and there is some more on that in the FAQ file.
    Ok, thanks for the pointer
    I have four Solaris boxes running 2.6, 2.7, 2.8 & 2.9, all patched up and
    ready to go. I also have a local 'p4 sync'd copy of the 5.6.x, 5.8.x and
    5.10.x branches from the perl repository and I'm in the process of writing
    a script to drive all four machines. I'm intending that the script will
    sync with the repository a couple of times a day, and automatically kick
    off smokes on machines as they become idle.
    F<configsmoke.pl> creates a little shellscript that starts the smokes, you
    could put an endless-loop around the

    /usr/bin/perl smokeperl.pl -c "$CFGNAME" $continue $* > smokecurrent.log 2>&1

    line. (But I'm no shell programmer)
    It's a little more complicated - I have to sync the repository up first, and
    only run if something has changed.
    Hopefully once it is running I
    won't have to touch it.
    You might need to keep your eye on it for a bit, I've had trouble with
    Solaris-8 running out of processes (although I'm not sure if that is smoke
    related). And if we see test failures, you might need to investigate. Indeed.
    I'll see if I can manage some sort of archive mechanism that archives the
    report and the smokeperl logfile so one can go back to them whilst in
    continous smoke-mode.
    That would be useful. Another RFE is for a 'status' command that shows you
    how many tests of a run have completed.

    --
    Alan Burlison
    --
  • Abe Timmerman at Aug 7, 2003 at 3:08 pm
    Op een zonnige zomerdag (Thursday 07 August 2003 16:29), schreef Alan
    Burlison:
    Abe Timmerman wrote:
    <snip>
    F<configsmoke.pl> creates a little shellscript that starts the smokes,
    you could put an endless-loop around the

    /usr/bin/perl smokeperl.pl -c "$CFGNAME" $continue $* > smokecurrent.log
    2>&1

    line. (But I'm no shell programmer)
    It's a little more complicated - I have to sync the repository up first,
    and only run if something has changed.
    That's why there is 'smartsmoke', F<smokeperl.pl> will check if the patchlevel
    changed after its synctree-step. No change, no smoke...

    <snip>
    I'll see if I can manage some sort of archive mechanism that archives the
    report and the smokeperl logfile so one can go back to them whilst in
    continous smoke-mode.
    That would be useful.
    The basics are finished, I just need to integrate it in F<configsmoke.pl>, It
    will be in the first MAINT release for 1.18
    Another RFE is for a 'status' command that shows you
    how many tests of a run have completed.
    Individual tests per configuration/$ENV{PERLIO} cannot be determined. But I
    can interpret the F<mktest.out> file and match it against the buildconfig
    file and report what is already done and what is still to be expected.
    But that will have to wait until 1.19 for which I've planned to modularise
    F<mkovz.pl> in such a way that this sort of thing is easy...

    Good luck,

    Abe
    --
    Perl "configure" is not GNU configure, Perl is not "other GNU program".
    Do not confuse one of Perl's licenses with the GNU project itself.
    -- Jarkko Hietaniemi on p5p @ 2002-05-27
  • Alan Burlison at Aug 7, 2003 at 3:47 pm

    Abe Timmerman wrote:

    It's a little more complicated - I have to sync the repository up first,
    and only run if something has changed.
    That's why there is 'smartsmoke', F<smokeperl.pl> will check if the patchlevel
    changed after its synctree-step. No change, no smoke...
    Yes, but my UberSmoke script needs not to keep calling smokeperl.pl in a
    tight loop when there is actually nothing to do, hence it need to know as
    well. No problem, I already have this sorted out.
    Another RFE is for a 'status' command that shows you
    how many tests of a run have completed.

    Individual tests per configuration/$ENV{PERLIO} cannot be determined. But I
    can interpret the F<mktest.out> file and match it against the buildconfig
    file and report what is already done and what is still to be expected.
    But that will have to wait until 1.19 for which I've planned to modularise
    F<mkovz.pl> in such a way that this sort of thing is easy...
    Yes, I'm not really bothered about individual test status, more like
    '5 of 27 configurations tested, 2 configurations failed tests'
    or similar. A 'started ad date' and 'estimated completion by' would be a
    bonus ;-)

    --
    Alan Burlison
    --

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdaily-build @
categoriesperl
postedAug 6, '03 at 10:51p
activeAug 7, '03 at 3:47p
posts5
users2
websiteperl.org

2 users in discussion

Alan Burlison: 3 posts Abe Timmerman: 2 posts

People

Translate

site design / logo © 2019 Grokbase