Mailing-List: contact stdcxx-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: stdcxx-dev@incubator.apache.org
Received-SPF: pass (herse.apache.org: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Windows solution generator bugs
Date: Tue, 24 Oct 2006 20:10:27 +0300
Message-ID: <F92433E3D38672499C549EB615AFADA0998F71@exkiv.kyiv.vdiweb.com>
Thread-Topic: Windows solution generator bugs
Thread-Index: Acb3igp6ClmB66U+SJS7a5K3hBN1ZgAAGUMQ
From: "Farid Zaripov" <FaridZ@kyiv.vdiweb.com>
To: <stdcxx-dev@incubator.apache.org>

> -----Original Message-----
> From: Andrew Black [mailto:ablack@roguewave.com]=20
> Sent: Tuesday, October 24, 2006 7:30 PM
> To: stdcxx-dev@incubator.apache.org
> Subject: Windows solution generator bugs
>=20
> I am working with the solution generator in an effort to=20
> start automated testing of stdcxx on windows.  During this=20
> process, I have observed a couple flaws with the infrastructure.
>=20
> The first flaw I have observed is that the /LOCALES:no switch=20
> to the generate.wsf script seems to be broken.  When I=20
> specify this switch, I observe the following behavior:
>=20
> > C:\build\ablack\stdcxx-test>generate.bat /CONFIG:msvc-8.0=20
> > /BUILDDIR:build /LOCALES:no Solution generation script Checking=20
> > arguments...
> > Building directory tree created
> > Checking consistence...
> > Creating projects definitions...
> >=20
> C:\build\ablack\stdcxx-test\etc\config\windows\generate.wsf(740, 10)=20
> > Microsoft JScript runtime error: 'this.prototype' is null or not an=20
> > object
>=20
> I suspect that this is a fairly simple problem to fix, but I=20
> don't have the needed familiarity with the code to fix it quickly.
  Thanks for testing. I have just fixed it:
http://svn.apache.org/viewvc?view=3Drev&rev=3D467383

> The second (less critical) flaw I have observed is in the use=20
> of the exec utility.  The utility is designed to run multiple=20
> targets (tests or
> examples) in a single shot, and examine the return code and=20
> output of the runs, comparing example output against the=20
> reference files or extracting the test assertion count from=20
> tests.  My reading of the runall.wsf script is that it=20
> ignores all these features, treating it as a simple wrapper=20
> around the test that is to be run.
> =20
> I am willing to try to rewrite this script to utilize more of=20
> the capabilities of the utility, but I don't know what other=20
> scripts would be affected by changes in the behavior.
  runall.wsf script also produces the examples and tests log files
(%BUILDDIR%\%CONFIG%\examples\*\temphtm\*.htm;
%BUILDDIR%\%CONFIG%\tests\*\temphtm\*.htm) for the makelog.wsf script.

Farid.