I have a workspace that produces dozens of binaries (DLLs & EXEs).
For Each of them I would like to export a function that returs a TestSuite, then I can run test-prog that tries to load every one of my binaries and look for this TestSuite factory. This way my modules are self-contained: every module has a TestSuite to test itself.
And now for my <b>question</b>: The test loader should know about CppUnit, so do the binaries. But if I link each with the static CppUnit lib there will be problems as the classes will be defined in both the loader and the binaries.
Are there any plans making the CppUnit compile as a DLL as well (This implies using the __declspec(...) stuf in the header files)?
Did I miss anything with my idea?
thanks,
Mike.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In each cppUnit header, this header-file should be included and the class definition should be changed the following way:
class A {...};
will become:
class EXP_IMP A {...};
In that way Unix-like environments won't perceive any difference. And WinUsers would specify either EXP_DLL (for building the dll; of course we need here another make-target) or IMP_DLL (when using CppUnit)
Or are there other suggestions regarding this problem?
I would also volunteer in doing the necessary changes if there is a project guy available with whom I can discuss the details of the changes etc.
Regards,
bored
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've already done the DLL, so if you need a working project email me.
This feature is indeed very helpful for us poor windows programmers. What it enables me to do is load all the DLLs under any path I choose and try to get a test factory from each. This sure beats the requirement to make a special binary for testing - the DLL contains it's own test code!
How can I contribute my changes into the CppUnit CVS?
Now I'm facing another problem: I manage to load EXE files that expose a test factory but I get an access violation crash when I try to call the function. I guess that has something to do with EXE mapping which is different than the DLL mapping (both are loaded using LoadLibrary).
Any thoughts?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have a workspace that produces dozens of binaries (DLLs & EXEs).
For Each of them I would like to export a function that returs a TestSuite, then I can run test-prog that tries to load every one of my binaries and look for this TestSuite factory. This way my modules are self-contained: every module has a TestSuite to test itself.
And now for my <b>question</b>: The test loader should know about CppUnit, so do the binaries. But if I link each with the static CppUnit lib there will be problems as the classes will be defined in both the loader and the binaries.
Are there any plans making the CppUnit compile as a DLL as well (This implies using the __declspec(...) stuf in the header files)?
Did I miss anything with my idea?
thanks,
Mike.
Basically, I have the same problem.
It would really help a lot, if the cppUnit-classes would feature dllexport/import capabilities.
Maybe a simple solution would be the following:
------
DllExpImpConfig.h:
#ifndef DLL_EXP_IMP_CONFIG_H
#define DLL_EXP_IMP_CONFIG_H
#ifdef EXP_DLL
#define EXP_IMP __declspec(dllexport)
#endif
#ifdef IMP_DLL
#define EXP_IMP __declspec(dllimport)
#endif
#endif
-------
In each cppUnit header, this header-file should be included and the class definition should be changed the following way:
class A {...};
will become:
class EXP_IMP A {...};
In that way Unix-like environments won't perceive any difference. And WinUsers would specify either EXP_DLL (for building the dll; of course we need here another make-target) or IMP_DLL (when using CppUnit)
Or are there other suggestions regarding this problem?
I would also volunteer in doing the necessary changes if there is a project guy available with whom I can discuss the details of the changes etc.
Regards,
bored
Thanks Michel,
I've already done the DLL, so if you need a working project email me.
This feature is indeed very helpful for us poor windows programmers. What it enables me to do is load all the DLLs under any path I choose and try to get a test factory from each. This sure beats the requirement to make a special binary for testing - the DLL contains it's own test code!
How can I contribute my changes into the CppUnit CVS?
Now I'm facing another problem: I manage to load EXE files that expose a test factory but I get an access violation crash when I try to call the function. I guess that has something to do with EXE mapping which is different than the DLL mapping (both are loaded using LoadLibrary).
Any thoughts?
Hi.
It would be very kind of you, if you could mail me your dll/lib.
I've also opened a feature request, and here I am waiting for responses. If you could mail me your modified project, it would be very helpful.
Thanks
bored
Sure,
I just need an email address, the one from SourceForge does not accept attachments.
Here you are:
a_bored@gmx.de
Regards
Armin
Can you post your changes as a patch to sourceforge ? This way I could also benefit from this.
I'm in the same boat as you and self-contained test suites are very important.
Thanks
Phil