How's this look? I've only tested it lightly, but it should be pretty close; with this, "make test" ought to recurse down into programs/cmd/tests and run the cmd tests, too.
Shortcomings: - I don't think I need chomp() in tests/cmd.c anymore, that was a workaround - I think I can turn on echo again in tests/*.cmd, that was another workaround - I have yet to add a way to specify that a test is todo_wine
Feedback welcome. I'll try to submit something tomorrow that takes care of the above known issues and any issues anyone else points out.
(I'm actually kind of amazed the build machinery changes work, I didn't really take the time to understand all of the gears and pulleys.)
Dan Kegel a écrit :
How's this look? I've only tested it lightly, but it should be pretty close; with this, "make test" ought to recurse down into programs/cmd/tests and run the cmd tests, too.
Shortcomings:
- I don't think I need chomp() in tests/cmd.c anymore, that was a workaround
- I think I can turn on echo again in tests/*.cmd, that was another workaround
- I have yet to add a way to specify that a test is todo_wine
Feedback welcome. I'll try to submit something tomorrow that takes care of the above known issues and any issues anyone else points out.
(I'm actually kind of amazed the build machinery changes work, I didn't really take the time to understand all of the gears and pulleys.)
what I don't like in current design: - it requires external files to the generic .c file (but putting it into a resource would do) - but more importantly, you cannot simply have a result that depends on some test conditions or previous results (for example "date"...) - also it won't allow to use some "interactive" features of cmd (like filename completion on tab)
so I'd better like an approach where you decide, command by command, which input strings you send to cmd and how to interpret the final result out of the shell. the file approach you're currently using could be of course implemented on top of this first layer
A+
On Sat, Jan 2, 2010 at 5:25 AM, Eric Pouech eric.pouech@orange.fr wrote:
what I don't like in current design:
- it requires external files to the generic .c file (but putting it into a
resource would do)
The current design *does* put the external files into a resource, so I think I've satisfied that already.
- but more importantly, you cannot simply have a result that depends on some
test conditions or previous results (for example "date"...)
- also it won't allow to use some "interactive" features of cmd (like
filename completion on tab)
so I'd better like an approach where you decide, command by command, which input strings you send to cmd and how to interpret the final result out of the shell. the file approach you're currently using could be of course implemented on top of this first layer
I'm fine with adding those, but I'd prefer to do it later. The current simple approach will handle most of what we need. It has already found lots of problems. - Dan
Dan Kegel schrieb:
On Sat, Jan 2, 2010 at 5:25 AM, Eric Pouech eric.pouech@orange.fr wrote:
what I don't like in current design:
- it requires external files to the generic .c file (but putting it into a
resource would do)
The current design *does* put the external files into a resource, so I think I've satisfied that already.
- but more importantly, you cannot simply have a result that depends on some
test conditions or previous results (for example "date"...)
- also it won't allow to use some "interactive" features of cmd (like
filename completion on tab)
so I'd better like an approach where you decide, command by command, which input strings you send to cmd and how to interpret the final result out of the shell. the file approach you're currently using could be of course implemented on top of this first layer
I'm fine with adding those, but I'd prefer to do it later. The current simple approach will handle most of what we need. It has already found lots of problems.
- Dan
i really like that try, but i guess Eric meant to move it in a real .res-file and compile it as that.(so it should be in some TEXT resource format) but you are right IMO to add further tests later. and i am a bit afraid how that works together with the online winetest scripts, so we dont crash them. i can look into that earliest on monday as i am busy till then
-
André Hentschel -
Dan Kegel -
Eric Pouech