Octave with non-gcc compilers and build testing

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Octave with non-gcc compilers and build testing

John W. Eaton-6

I spent some time today working on Octave with the Sun and Compaq C++
compilers on SPARC and Alpha systems.  I think I've worked out most of
the problems so Octave almost builds out of the box on both systems.

Paul reports that he is also close to being able to build Octave on
SGI systems with the SGI compiler, at least after creating some
header files to wrap the C headers for C++.

Thanks to Mumit's earlier work with the Sun and Intel compilers, and
Paul's recent work with the SGI compiler, my work today wasn't too
hard, though it was somewhat slow going.  The main problems were
regressions that have happened because I normally build Octave only on
Debian systems with gcc.

Maybe it would be useful to set up something like Mozilla's tinderbox
(see http://tinderbox.mozilla.org/showbuilds.cgi?tree=SeaMonkey, for
example).  That way we would have more immediate feedback when there
is a regression in the build process on some platforms.

The closest we have to this kind of setup now is the set of Debian
builds that happen when Dirk makes a new package, but that typically
only happens when I make a new snapshot, and it only tests Debian
systems.

The main problem I see with the tinderbox idea is that we need to have
some poeple donate cycles.  We don't need anything fast, but we do
need some variety.  Currently, I can only offer to set up testing on
Debian x86 and Alpha systems, and perhaps a Sun system (though the
hardware is not mine, so I'm not sure I will be able to get away with
running compile jobs 24/7 on the machines I have access to).  So is
there any interest in helping to set somethign like this up and make
it work?

Thanks,

jwe


Reply | Threaded
Open this post in threaded view
|

Re: Octave with non-gcc compilers and build testing

Paul Kienzle
John W. Eaton wrote:

>Paul reports that he is also close to being able to build Octave on
>SGI systems with the SGI compiler, at least after creating some
>header files to wrap the C headers for C++.
>
It does build and pass make check, but not quite out of the box.  The
new version of the
CC compiler (7.5?) is apparently mostly compliant, so I won't even need
to fake cmath, etc.
We haven't got it yet.

>The main problem I see with the tinderbox idea is that we need to have
>some poeple donate cycles.  We don't need anything fast, but we do
>need some variety.  Currently, I can only offer to set up testing on
>Debian x86 and Alpha systems, and perhaps a Sun system (though the
>hardware is not mine, so I'm not sure I will be able to get away with
>running compile jobs 24/7 on the machines I have access to).  So is
>there any interest in helping to set somethign like this up and make
>it work?
>
Daily builds seem a little excessive.  Maybe weekly?  It would also be
nice if you could trigger
it yourself when you want to release a new version.

It might also be nice if 3rd party packages could build and test.
 Currently that's octave-forge,
but I can see there may be others in the future, once we've got a
Comprehensive Octave
Archive Network up and running.  One problem with octave-forge stuff is
that it may depend
on libraries such as qhull which may or may not be present. Testing
octave-forge/main/parallel
will be even more of a challenge. :-)

For those of us behind firewalls, it will have to be a pull system.
 E.g., a cron job which checks
every 6 hours if  the version mentioned in
http://www.octave.org/buildcheck is newer than the last
version built on your machine.  If so, then download, configure, make,
make check and post
a reply form to http://www.octave.org/buildresults.  This sounds easy
enough to do, but I don't
have the php skills to do it.

Paul Kienzle
[hidden email]



Reply | Threaded
Open this post in threaded view
|

Re: Octave with non-gcc compilers and build testing

John W. Eaton-6
On  4-Jan-2003, Paul Kienzle <[hidden email]> wrote:

| John W. Eaton wrote:
|
| >The main problem I see with the tinderbox idea is that we need to have
| >some poeple donate cycles.  We don't need anything fast, but we do
| >need some variety.  Currently, I can only offer to set up testing on
| >Debian x86 and Alpha systems, and perhaps a Sun system (though the
| >hardware is not mine, so I'm not sure I will be able to get away with
| >running compile jobs 24/7 on the machines I have access to).  So is
| >there any interest in helping to set somethign like this up and make
| >it work?
|
| Daily builds seem a little excessive.  Maybe weekly?  It would also be
| nice if you could trigger
| it yourself when you want to release a new version.

The idea for more frequent builds (continuous for Mozilla) is that you
know almost immediately when a change results in a problem, so it is
easier to determine the cause.  Also, the Mozilla tinderbox client
apparently does

  forever
    {
      cvs update
      make
      mail log file to server
    }

this assumes that make can rebuild and rerun configure scripts, but we
should probably fix that problem in Octave's makefiles anyway.  Using
CVS to update the sources instead of downloading complete tar files
will generally mean faster builds but it doesn't test the distribution
process, so it would be nice to also be able to ask the tinderbox
clients to download tar files and build from those.

The server collects the log files and generates the web page that
makes it easy to see whether a problem exists.  I would modify the
client loop to be more like

  forever
    {
      cvs update
      if (no changes)
        {
          wait a while
        }
      else
        {
          make
          mail log file to server
        }
    }

to avoid lots of pointless running of make and cvs update, but
otherwise, I don't see a problem with having something like this
running all the time, with "wait a while" being something like 30
minutes.

| It might also be nice if 3rd party packages could build and test.

It seems that it wouldn't be too hard to set up additional software
for testing once you have the basic tinderbox stuff set up.

jwe


Reply | Threaded
Open this post in threaded view
|

Re: Octave with non-gcc compilers and build testing

Paul Kienzle
John W. Eaton wrote:

>On  4-Jan-2003, Paul Kienzle <[hidden email]> wrote:
>
>| John W. Eaton wrote:
>|
>| >The main problem I see with the tinderbox idea is that we need to have
>| >some poeple donate cycles.  We don't need anything fast, but we do
>| >need some variety.  Currently, I can only offer to set up testing on
>| >Debian x86 and Alpha systems, and perhaps a Sun system (though the
>| >hardware is not mine, so I'm not sure I will be able to get away with
>| >running compile jobs 24/7 on the machines I have access to).  So is
>| >there any interest in helping to set somethign like this up and make
>| >it work?
>|
>| Daily builds seem a little excessive.  Maybe weekly?  It would also be
>| nice if you could trigger
>| it yourself when you want to release a new version.
>
>The idea for more frequent builds (continuous for Mozilla) is that you
>know almost immediately when a change results in a problem, so it is
>easier to determine the cause.
>
With more people working, this may make more sense.  Since it is mostly
just you, though, I can't
imagine there will be that much difficulty sorting out the causes of
build problems.

Plus you are more likely to get spare cycles if the supplier of the
cycles can determine how
frequently they want to rebuild things.

>this assumes that make can rebuild and rerun configure scripts, but we
>should probably fix that problem in Octave's makefiles anyway.  
>
I prefer a less conservative rebuild process in general because
sometimes I don't want to
wait for everything to recompile just because of minor configure changes
for a separate
environment.

>Using
>CVS to update the sources instead of downloading complete tar files
>will generally mean faster builds but it doesn't test the distribution
>process, so it would be nice to also be able to ask the tinderbox
>clients to download tar files and build from those.
>
Distribution is by snapshots.  Most people are not building from CVS.
 You want more frequent
builds than that.  I think it is reasonable for tinderboxes to
reconfigure when configure.in changes,
but other than that CVS seems reasonable.  Maybe a forced make
clean/reconfigure every so
often just to make sure things are consistent.

Paul Kienzle
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Octave with non-gcc compilers and build testing

JD Cole-2
In reply to this post by Paul Kienzle
>
> It might also be nice if 3rd party packages could build and test.
> Currently that's octave-forge,
> but I can see there may be others in the future, once we've got a
> Comprehensive Octave
> Archive Network up and running.  One problem with octave-forge stuff
> is that it may depend
> on libraries such as qhull which may or may not be present. Testing
> octave-forge/main/parallel
> will be even more of a challenge. :-)
>
Paul,
   Just a thought on testing the parallel stuff...it shouldn't be too
much trouble to come up with a test for Fujiwara's parallel code
locally. As for code based which uses 3rd party packages, like MPI, I'm
thinking that octave-forge should only compile it given if the configure
script was given a -have-mpi or -with-parallel support, or something of
this nature, in that case the appropriate tests could be run on a
 single machine. I don't think that testing the ability of the script to
run on multiple machines should be the responsibility of the
octave-forge test, this seems more like the responsibility of the
parallel user.

Best,
JD