-
-
Notifications
You must be signed in to change notification settings - Fork 641
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Compiling as Dll maybe is wrong #196
Comments
This issue is somewhat of lower priority as compiling doctest inside dll is rare. |
But does the code work - is this just a warning? And is it a problem only on Windows (as I suspect)? I suppose you are familiar with the DOCTEST_CONFIG_IMPLEMENTATION_IN_DLL option which is used in the multi-dll example. That option is necessary ONLY when you want to have a single test registry between multiple .dll (and maybe +1 .exe) files - in your case if you have tests only in a single .dll then you don't need that option and thus An issue I remember - only on Windows! (as a warning which I think I silence) - is when DOCTEST_CONFIG_IMPLEMENTATION_IN_DLL is used - what ends up happening is that the TU in the .dll which implements the test runner "exports" the symbols using In order to be able to have a consistent Also perhaps So what is your exact workaround since it is of low priority? Is there a manifestation of a problem at all? To be honest I want to push version 2.3 out with an xml reporter so people can use doctest properly on their CI in the next 10 days because after that I'll have perhaps the busiest 4 months of my life so my attention is on the xml reporter. And in case you are really writing tests in multiple .dll files - that might make you the first person/organization I know of that uses this feature of doctest! (apart from me :D - I made it for myself) And are you writing tests along with your production code - the spirit of the framework? Splitting tests into multiple .dll files is rarely necessary unless you are indeed writing them next to the actual code which is itself split into modules. |
Well, "works for me" is not a real argument. The example works because the example itself is wrong and is doing overlinking. I discovered this bug when I tried to fix the ovelinking in the example in the cmake scripts.
It is necessary.
Indeed this is a lower priority, I might make a patch some day in the future.
No :). I discovered the bug when tried to fix the cmake scripts of the dll example. |
Perhaps exploring if |
On windows When compiling the dll you must have dllexport. When consuming the dll you must have dllimport. You can not skip this, you will get linking error. On linux, you don't need anything in the declarations, unless you explicitly compile the dll with default visibility to be hidden. Then you need to prefix the declarations with "visibility default" only when compiling. When consuming it does not matter if you have visibility attributes or not, I think. |
I'll explain the correct scenario:
fwd.h
and the.cpp
. The declarations in fwd must be marked as exported.fwd.h
with the declarations marked as imported.You should have two macros, or one with the values of 0, 1 and 2 that controls the dll attribute.
DOCTEST_CONFIG_IMPLEMENT
should not decide whether we are exporting or importing, as it does now.The text was updated successfully, but these errors were encountered: