TestHarness should be TESTPROD instead of PROD

[Dirk Zimoch]

Several "TestHarness" vxWorks and RTEMS products are built as PROD_vxWorks and PROD_RTEMS instead of TESTPROD_vxWorks and TESTPROD_RTEMS even though they depend on TESTLIB code. This seems a bit inconsistent. Changing them to TESTPROD would allow to build EPICS base without tests, which could speed up the development cycle in an early phase when building the tests is not yet needed.

Attached is a patch for EPICS 7 base. The same could be done for the submodules.

[Andrew Johnson (anj)]

When we first started running the libCom tests on VxWorks I found it useful for the test harness munch file to be installed into the bin/<arch> directory instead of buried somewhere inside the source tree. This is no longer as advantageous since the tests now depend on various other files (mostly .dbd and .db) which are also spread around the source tree (although maybe not quite as much), so I have to cd around the tree anyway to be able to run them.

We don't currently have a way to build Base without also building the tests, but that's actually a completely orthogonal issue. If we wanted that I would probably implement it by adding a TEST_DIRS variable (analogous to DIRS) and only descend into those directories when actually building tests. We only have one TESTPROD being built in a non-test directory at the moment:

Entering 'pva2pva'
p2pApp/Makefile:TESTPROD_HOST += testmon

[Dirk Zimoch (dirk.zimoch)]

> We don't currently have a way to build Base without also building the tests,
Well, I simply tried to call 'make TESTS= TESTLIB= TESTPROD=' to speed up compilation while implementing my changes to iocLogClient.

[Dirk Zimoch (dirk.zimoch)]

Same patch for pvData submodule

[Dirk Zimoch (dirk.zimoch)]

Same patch for pvDatabase submodule

[Dirk Zimoch (dirk.zimoch)]

Same patch for pvAccess submodule

[Andrew Johnson (anj)]

These patches should have been applied for this release, sorry this fell through the cracks.

[mdavidsaver (mdavidsaver)]

> tests now depend on various other files

The RTEMS test harness executables remain self-contained, with necessary test files baked into the executable.

Personally, I don't see skipping re-linking test executables as a major slow down. At least when compared with compiling c++ code like libpvAccess.

@Andrew, Have you committed any of these changes? If not, then I would rather defer this issue again.

[Andrew Johnson (anj)]

I have not committed or tested any of these yet. I'll remove the milestone.