RE: [Cppunit-devel] RE: Auto registration vs. the linker

[Summerwill, B. <BSu...@eu...>]

>> The only change is I want to spread it over multiple linking units and it
just doesn't
>> work with Visual C++ as the linker is too smart. 
 
I've run up against this on a number of occasions.  I don't think there is a
solution to it, beyond adding explicit code references.  The code registers
the tests using side-effects, which the linker is unaware of.  I believe
GCC-generated code will suffer from the same problem if it is ee-strip'ed.
I'm sorry I can't provide a better solution.
 
 
Cheers,
Bob
 

-----Original Message-----
From: King Dale [mailto:Ki...@tc...]
Sent: 12 November 2001 16:00
To: 'cpp...@li...'
Subject: [Cppunit-devel] RE: Auto registration vs. the linker



I know I can build it with the executable referencing each subsystem and
then the entry point making references to each subsystem. I'm trying to
avoid this referencing from what would be the root of the tree toward the
bottom of the tree. I'd like to have the leaves of the tree attach
themselves to their parent via the autoregistration. The problem is that you
can't seem to do this when objects are linked from libraries but you can
when it is all in one project.

Why would I want to do this? Well it distributes control rather than
centralized control of tests. It would also allow one to easily enable and
disable tests without editing a source file, you just change the project
dependencies. It also allows multiple build possibilities. In the examples
project you have both a GUI version and a console version of the cppunit
tests. Both projects include all of the source code for the tests. Wouldn't
it make more sense to have one project that defines the tests that is linked
with a text runner project or a gui runner project (which would actually be
generic and not know what they are testing). You just can't seem to do this
however.

And the example do in fact use the linker to do that. Look at the test for
cppunit. You see the file CoreSuite.h that defines the name of the Core
suite. You have tests in the Core suite like TestAssertTest that use that
name and use auto-registration to add themselves to the core suite. There is
nothing in any other source file that even knows of the existence of
TestAssertTest.h or TestAssertTest.cpp. If you moved CoreSuite.h,
TestAssertTest.h and TestAssert.cpp into a separate linking unit, for
example moving all core tests into their own project that builds a static
library to be linked with the main executable you will find that it no
longer works. Not all of the test will get registered. In fact you would
find what I did when attempting something along these lines, that only the
last source file that does the auto registration gets registered!

So you see, what I am trying to do is not that different than what is done
already with cppunit. The only change is I want to spread it over multiple
linking units and it just doesn't work with Visual C++ as the linker is too
smart. The gnu tools have a "whole-archive" option which I think would do
what I want forcing objects in the library to be included even if they are
not referenced. The VC++ linker has a force option but that only forces the
inclusion of a symbol, not of an archive. I could already do that by having
a source file make a reference. There is a pragma to pass options to the
linker from the C source code, so I tried having the actual source file do
the forcing, but it didn't work.

-----Original Message----- 
From: "Baptiste Lepilleur" <bl...@cl...> 
To: <cpp...@li...> 
Subject: Re: [Cppunit-devel] Auto registration vs. the linker 
Date: Sun, 11 Nov 2001 11:14:35 +0100 

You don't use the linker to do that. 

In each "linking unit", you add a entry point that return a suite that 
contains all the unit test of that linking unit. You do that using the 
TestFactoryRegistry (you might want to use addTestToSuite() instead of 
makeTest() so you can name the suite after the "linking unit"). 

In the executable that link against all subsystems, you constructs a suite 
that include all the suite published in the "linking units". You use that 
suite to run the test. 

TestPlugInInterface.h define such an entry point in a standard way, so the 
test can be run on a specific DLL without having to build the executable. 

Baptiste. 

----- Original Message ----- 
From: "King Dale" <Ki...@tc...> 
To: <cpp...@li...> 
Sent: Friday, November 09, 2001 8:35 PM 
Subject: [Cppunit-devel] Auto registration vs. the linker 


> I like and am trying to use auto registration in Visual C++ but the linker

> keeps defeating me. The example cppunit tests work fine because you are 
> building everything as one project. But that is not how I want to do it. 
> This is for a large system and it would work much nicer to have the tests 
> for individual subsystems be built as their own projects and simply link 
> them together with a small runner program within the overall workspace. So

I 
> have a project within the workspace that has the main executable and it 
just 
> gets its test from the registry. I don't want any file within that project

> to know about what tests are out there. Each subsystem is built as a 
shared 
> library that gets linked with the main executable. To add a subsystem to 
the 
> lists of tests you just add its project to the dependencies of the main 
> executable project to get them to link in. 
> 
> The problem is that it will not work as I described it. The linker is too 
> smart. It will not even include any of the object files for the unit tests

> unless they are somehow referenced from the main executable. That is of 
> course what the linker is supposed to do. But I don't want to hardcode 
> references to the tests. This requires extra work to add tests, defeats 
the 
> purpose behind auto registration, and makes it more difficult to change 
the 
> tests you want to run. 
> 
> If you don't use a shared library and build in one project you don't have 
> this problem. The linker includes all .obj files into the output even if 
> they are not referenced, but will not do that if the same .obj files are 
> packaged as a shared library. I don't want to build everything in one 
> project. Different subsytems need different build options and things, so I

> want them to be compiled separately with separate configuration. 
> 
> Does anybody have any way to get the linker to do what I want it to do 
which 
> is to say include all translation units from a shared library whether I 
> reference them or not? 
> 
> -- 
>   Dale King 
> 




--__--__-- 

_______________________________________________ 
Cppunit-devel mailing list 
Cpp...@li... 
https://lists.sourceforge.net/lists/listinfo/cppunit-devel
<https://lists.sourceforge.net/lists/listinfo/cppunit-devel>  


End of Cppunit-devel Digest