Dan Hipschman dsh@linux.ucla.edu writes:
This extends the testing framework to allow for tests that need IDL files and RPC clients. It's the same as the last attempt, but I've removed two little development artifacts that slipped in last time, I fixed an indentation glitch, fixed one more thing in the Makefile so "make depend" works for ClientMakefile as well, and I separated the first test case from the infrastructure change (see next patch).
That's very ugly; you shouldn't need any of that stuff, especially not a separate makefile. You should put everything in the same exe, and differentiate server and client through command line arguments, the way the process test does it.
On Fri, Apr 20, 2007 at 11:41:16AM +0200, Alexandre Julliard wrote:
Dan Hipschman dsh@linux.ucla.edu writes:
This extends the testing framework to allow for tests that need IDL files and RPC clients. It's the same as the last attempt, but I've removed two little development artifacts that slipped in last time, I fixed an indentation glitch, fixed one more thing in the Makefile so "make depend" works for ClientMakefile as well, and I separated the first test case from the infrastructure change (see next patch).
That's very ugly; you shouldn't need any of that stuff, especially not a separate makefile. You should put everything in the same exe, and differentiate server and client through command line arguments, the way the process test does it.
Well, I tried to make it as pretty as possible. The problem is that the client and server code won't link together. For each function, there's the implementation and the stub, both with the same name. To get both into the same executable, I'd have to do some sort of renaming hack, either with the preprocessor or something like sed. The reason I like two makefiles better is that messing with the output of widl weakens the test. I can take a second look at that approach, though, or look for an entirely different way if you really hate having two makefiles/exes.
Dan Hipschman wrote:
On Fri, Apr 20, 2007 at 11:41:16AM +0200, Alexandre Julliard wrote:
That's very ugly; you shouldn't need any of that stuff, especially not a separate makefile. You should put everything in the same exe, and differentiate server and client through command line arguments, the way the process test does it.
Well, I tried to make it as pretty as possible. The problem is that the client and server code won't link together. For each function, there's the implementation and the stub, both with the same name. To get both into the same executable, I'd have to do some sort of renaming hack, either with the preprocessor or something like sed. The reason I like two makefiles better is that messing with the output of widl weakens the test. I can take a second look at that approach, though, or look for an entirely different way if you really hate having two makefiles/exes.
midl has an option to add a prefix to the server functions so that you can compile server & client code in the same exe/dll. It might be a good idea to add the equivalent functionality to widl for this reason.
On Sun, Apr 22, 2007 at 05:13:23PM +0100, Robert Shearman wrote:
Dan Hipschman wrote:
On Fri, Apr 20, 2007 at 11:41:16AM +0200, Alexandre Julliard wrote:
That's very ugly; you shouldn't need any of that stuff, especially not a separate makefile. You should put everything in the same exe, and differentiate server and client through command line arguments, the way the process test does it.
Well, I tried to make it as pretty as possible. The problem is that the client and server code won't link together. For each function, there's the implementation and the stub, both with the same name. To get both into the same executable, I'd have to do some sort of renaming hack, either with the preprocessor or something like sed. The reason I like two makefiles better is that messing with the output of widl weakens the test. I can take a second look at that approach, though, or look for an entirely different way if you really hate having two makefiles/exes.
midl has an option to add a prefix to the server functions so that you can compile server & client code in the same exe/dll. It might be a good idea to add the equivalent functionality to widl for this reason.
Thanks, I'm going to try that.
-
Alexandre Julliard -
Dan Hipschman -
Robert Shearman