Re: initialization files for test suite

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

Re: initialization files for test suite

Rik-4
On 02/07/2019 11:54 AM, [hidden email] wrote:
> Subject: > Re: RC2 / 5.0.91 > From: > Mike Miller [hidden email] > Date: > 02/07/2019 11:45 AM > To: > [hidden email] > List-Post: > [hidden email] > Precedence: > list > MIME-Version: > 1.0 > References: > [hidden email] <MTAwMDAwMy5ub21hZA.1549473997@quikprotect> <MTAwMDAyMC5ub21hZA.1549480678@quikprotect> [hidden email] [hidden email] > In-Reply-To: > [hidden email] > Message-ID: > [hidden email] > Content-Type: > multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="oyUTqETQ0mS9luUI" > Message: > 4 > > On Thu, Feb 07, 2019 at 14:15:04 -0500, Andrew Janke wrote: >> I wonder if, for the test suite, the system and/or site octavercs should be >> treated differently from the user octaverc, because this might be used to >> make configuration changes for Octave to work correctly in the environment >> in which it's installed? > In that case, you can choose to run the test suite with octave > --no-init-file. This loads the system startup files but avoids loading > user startup files. > > I feel like this subthread is trying to define a strict environment that > the test suite should always be run in. IMHO that is not the right > direction at all. The test suite should be run in the user's normal > working environment. > I think this is a good aspirational goal, but not something that we can implement immediately.  What I did do, immediately, was to change the invocation of octave when running 'make check' to use '--no-init-file' rather than '--norc'.  See https://hg.savannah.gnu.org/hgweb/octave/rev/8e97a2e5ab66.  This is a step towards the eventual goal, and will do the right thing when the system (such as Mac) require customization even to run.

I haven't checked whether run-octave does the correct thing in a newly unpacked and compiled source tree and takes the system-wide octaverc from the build directory, versus the install directory.  If it is the latter then a previous installation of Octave would be required to run 'make check' which is not ideal.

@Andrew: Could you file an issue report about making the entire test suite robust against changes in the user's environment?  Some simple scenarios that would flush out various problems:

1) Change save_default_options to something obtuse, like '-ascii', and run test suite.
2) Change default graphics_toolkit to "fltk", and run test suite
3) Change default graphics_toolkit to "gnuplot", and run test suite
4) Make all working directories read-only (perhaps 'chmod -R 555 *'), and run test suite

--Rik

Reply | Threaded
Open this post in threaded view
|

Re: initialization files for test suite

Mike Miller-4
On Fri, Feb 08, 2019 at 09:17:19 -0800, Rik wrote:
> I think this is a good aspirational goal, but not something that we can
> implement immediately.  What I did do, immediately, was to change the
> invocation of octave when running 'make check' to use '--no-init-file'
> rather than '--norc'.  See
> https://hg.savannah.gnu.org/hgweb/octave/rev/8e97a2e5ab66.  This is a step
> towards the eventual goal, and will do the right thing when the system
> (such as Mac) require customization even to run.

This was not necessary, but also shouldn't hurt much.

It's still not clear to me whether Andrew's discussion of customizations
on macOS are relevant to the context of "make check", or whether this
was about running the test suite in a different manner and environment.

> I haven't checked whether run-octave does the correct thing in a newly
> unpacked and compiled source tree and takes the system-wide octaverc from
> the build directory, versus the install directory.  If it is the latter
> then a previous installation of Octave would be required to run 'make
> check' which is not ideal.

The run-octave script already sets the environment variables
OCTAVE_SITE_INITFILE and OCTAVE_VERSION_INITFILE to point to the source
tree, not an issue, very well tested by now.

--
mike

signature.asc (849 bytes) Download Attachment