Richard Cohen richard@daijobu.co.uk writes:
We shouldn't create a new file for *every single* test, but we should do so for an unrelated test. How 'unmanageable' is adding 1 line to Makefile.in?
There are more than 700 APIs in user32 alone. If we create a new file for each one, that means 700 source files. Plus, with all the debug symbols, the smallest object file weighs in at least 100K, so that's a minimum of 70Mb of object files in that single directory. Multiply that by the 150 dlls we have and it should be obvious why it's unmanageable.
I would rather have the tests as *maintaineable*. If a test fails, isn't it easier to look through 200 lines than 2000 lines ?
No, since you get a line number with the failure message, you don't have to look through the whole file.
Alexandre Julliard wrote:
There are more than 700 APIs in user32 alone. If we create a new file for each one, that means 700 source files. Plus, with all the debug symbols, the smallest object file weighs in at least 100K, so that's a minimum of 70Mb of object files in that single directory. Multiply that by the 150 dlls we have and it should be obvious why it's unmanageable.
OK. I see the problem, but it's a one of disk space, rather than manageability.
I would rather have the tests as *maintaineable*. If a test fails, isn't it easier to look through 200 lines than 2000 lines ?
No, since you get a line number with the failure message, you don't have to look through the whole file.
To find the failing test, yes, but to fix the failing test, you potentially have to check the whole file. For example, the failing AdjustWindowRect tests were caused by problems elsewhere in win.c
I think we can agree that
+ Disk space is cheap + Programmer time is expensive, and + 10 independent files of 200 lines are more maintainable than 1 file of 2000 lines
Since 'gcc -c *.c -o bigobject.o' doesn't work, would something like the attached patch (using #include) be acceptable ?
Richard Cohen wrote:
Since 'gcc -c *.c -o bigobject.o' doesn't work, would something like the attached patch (using #include) be acceptable ?
Of course you can use the same technique to compile all the user tests in one file. The total size of the .o goes from 3.2M to 1.2M
Richard Cohen richard@daijobu.co.uk writes:
OK. I see the problem, but it's a one of disk space, rather than manageability.
Well, disk space is part of manageability; but it's also an issue of the number of files, and of the number of total tests (since each separate test needs to create a new process).
I think we can agree that
- Disk space is cheap
- Programmer time is expensive, and
- 10 independent files of 200 lines are more maintainable than 1 file
of 2000 lines
No, I don't agree with that. I think it's must better to group related things in the same file, and while 10 files may seem OK today, that thing will grow, and 10,000 files are much less manageable than 1000.
Since 'gcc -c *.c -o bigobject.o' doesn't work, would something like the attached patch (using #include) be acceptable ?
No, there's no reason to do that.
-
Alexandre Julliard -
Richard Cohen