vartest.c contains varformat.c tests

[Benjamin Arai]

Hi,

A bug was submitted (http://bugs.winehq.org/show_bug.cgi?id=5306) that
vartest.c was getting too large and that it needs to be smaller.  I don't
think to much can be done about the size but I did notice that all the tests
for varformat.c are being put into vartest.c as opposed to making a new test
file test/varformat.c.  Would there be any problems if I create a new test
file for varformat.c and move the appropriate test from vartest.c to it?

-- 
Benjamin Arai
http://www.benjaminarai.com

[Robert Shearman]

Benjamin Arai wrote:
> Hi,
>
> A bug was submitted (http://bugs.winehq.org/show_bug.cgi?id=5306) that 
> vartest.c was getting too large and that it needs to be smaller.  I 
> don't think to much can be done about the size but I did notice that 
> all the tests for varformat.c are being put into vartest.c as opposed 
> to making a new test file test/varformat.c.  Would there be any 
> problems if I create a new test file for varformat.c and move the 
> appropriate test from vartest.c to it?

No, that sounds good.

-- 
Rob Shearman

[Michael Stefaniuc]

Hello!

Benjamin Arai wrote:
> A bug was submitted (http://bugs.winehq.org/show_bug.cgi?id=5306) that 
> To be honest i do not think that bug is really valid:
> a.) he hasn't enough swap configured or
> b.) gcc problem
> vartest.c was getting too large and that it needs to be smaller.  I 
> It is big but that is more a compile time than runtime issue. It runs 
> very fast but it's dog slow when compiling. But so is also vartype.c.
> don't think to much can be done about the size but I did notice that all 
> There are some very heavy macros at least in the variant arithmetic 
> function tests. I was pondering to make them functions instead so those 
> will be compiled and optimized only once. But as it isn't a runtime 
> problem i went myself for the easy path of just keeping the macros.
> the tests for varformat.c are being put into vartest.c as opposed to 
> making a new test file test/varformat.c.  Would there be any problems if 
> I create a new test file for varformat.c and move the appropriate test 
> from vartest.c to it? 
> You can do that; i do not think that many people mind about that. The 
> only reason for that would be to make the vartest.c file more readable. 
> But if you end up having to replace a lot of the infrastructure at the 
> beginning of the file (macros, defines and that like) than it's not 
> worth the effort.

bye
	michael
-- 
Michael Stefaniuc               Tel.: [phone]
Sr. Network Engineer            Fax.: [phone]
Red Hat GmbH                    Email: mstefani(a)redhat.com
Hauptstaetterstr. 58            http://www.redhat.de/
D-70178 Stuttgart

[Dan Kegel]

On 7/26/06, Michael Stefaniuc <mstefani(a)redhat.com> wrote:
> > A bug was submitted (http://bugs.winehq.org/show_bug.cgi?id=5306) that
> > To be honest i do not think that bug is really valid:
> > a.) he hasn't enough swap configured or
> > b.) gcc problem

No, it's for real.  I measured gcc-4.0.3's memory usage on that file.
It uses 120MB, and for long enough that swapping is not really an option.
> > vartest.c was getting too large and that it needs to be smaller.
> > It is big but that is more a compile time than runtime issue. It runs
> > very fast but it's dog slow when compiling. But so is also vartype.c.

One workaround for people developing on 64MB machines
is to edit oleauto32/tests/Makefile to replace -O2 with -O0.
Memory usage still exceeds 64MB with that, but not by as much,
and for less time, so it should be bearable.

But it's reasonable to consider splitting up or otherwise speeding up the
compile of vartest.c and vartype.c.
- Dan