Advice on developing DLLs?

MrShawn

Hi guys,

I am experimenting with making some DLLs that I can be called in LV. I need some pointers from some more experienced developers.

My biggest issue that I am having is testing that my code is working quickly. For example I can't run my DLL I have to build it and then I create a separate project that calls the DLL and write some code to call some of the stuff I added/changed. This process is cumbersome and takes time, from what I have figured out I need to copy the newly built DLL into the working directory of the test apps exe. My main question is if there are and if so what are better ways to help improve the speed of developing DLLs.

I also think it would be improved by being able to not have to copy the newest DLL into the directory with my test apps exe. In the .pro file I specify the build directory of the DLL for the LIBS variable, that doesn't seem to do anything.

Any other advice welcome :)

Thanks,
Shawn

mrjj

Hi
There are multiple ways using the .pro/qmake
https://stackoverflow.com/questions/3984104/qmake-how-to-copy-a-file-to-the-output

For testing, you do need a loader app that calls the code.

koahnig

@MrShawn

You can have subdirs templated project.
You basically set up different projects for each library dll on different subdirectories and compile them at once.
I am using it with a couple of applications sharing the same dll. One of those applications could be the test application.
The output of those projects I am putting to a central folder with DESTDIR of qmake or you could use DLLDESTDIR.

MrShawn

@mrjj
So I can't avoid a separate app? Should I at this time start looking into the unit testing thing?

@koahnig + @mrjj
So looking at both links and then checking out the qmake stuff (I am honestly pretty weak with QMake, and even the CMake stuff when I did that before). I found the simplest solution is to set the DLLDESTDIR. I added a single line defining this and now it puts the new one where i specify. That is super duper helpful.

I need to look into more about some of the other things, for now it is a little over my head.

:)

mrjj

@MrShawn
well unit testing is a good idea as
you can then have pretty simple app that simply loads the dll and call
the CheckCode which will then run new code etc.
So you dont have to modify the loader also.

I normally points Creator to the loader app so it can start it automatically and i can step into
the DLL code.
However, you still need something to call the new code. being in dll or in loader.

MrShawn

@mrjj said in Advice on developing DLLs?:

I normally points Creator to the loader app so it can start it automatically and i can step into
the DLL code.

Do you mean to point to the loader app when you try to "run" the DLL, I have pressed that instead of build a few times, in which case there is a popup that is looking for an executable, is that where you do that?

mrjj

@MrShawn
yes
That popup ask "what to use to run it ?"

JKSH

@MrShawn said in Advice on developing DLLs?:

So I can't avoid a separate app?

@mrjj's loader approach is the proper way, but there's also a quick and dirty way.

Are you mostly interested in testing the logic only, or do you want to test the DLL interface too?

If logic only, you could set up your project like this:

realdll.h
realdll.cpp
realdll.pro
testapp.cpp
testapp.pro

realdll.pro is the project that produces the actual DLL. It should only contain realldll.h + realdll.cpp.

For testing purposes, use testapp.pro instead. This project should include all 3 *.h and *.cpp files and build all the code into a single app (without a DLL). In testapp.cpp, #include "realdll.h" and call the functions like a regular app does.

Should I at this time start looking into the unit testing thing?

Agreed with @mrjj, unit testing is never a bad idea

MrShawn

Thanks guys, I have been going full speed on the DLL lately, these tips have helped a lot.