1. Use of SONAME for library versioning.
2. [pvDataCPP] new Thread::Config (#14) 
3. [pvDataCPP] header files in pv/ sub-directories (#15) 
 These minutes https://docs.google.com/document/d/1hM4j_sv-XLUqYU23YIVGCF7uASbdthjIjMxMCmI8y_Y/edit?usp=sharing
Present: MS, MD, DH, GW, RL, KK, MK
DH: Took a quick look. If MSs is happy I’m happy.
MS: Looked at it. Provides a nice and necessary thing. I would accept.
MD: This addition adds helpers for defining a thread, with parameters for defining and configuring a thread. Motivation is that in pvAccess the existing config didn’t give meaningful names when showing running threads, and making it easy to code new threads.
Consensus: proceed with merge
DH: Does this involve moving every header file in every module?
DH: Well then I’m very much against it.
MD: ok, why - not user visible?
DH: true but it’s developer visible. This will compromise compare tool results, [because real functional changes will be obfuscated]. Wouldn’t mind if good justification.
MD: core issue the locations of include files in source tree doesn’t match the installed tree. Eg sharedPtr, is imported as pv/sharedPtr.h, but in source tree it’s in another directory, [maybe misc/].
MS: with current design you also need to be careful of filename clashes, since all includes go into one dir.
MD: True, but I’m not suggesting that the install dir name / structure should be changed
DH: so it doesn’t address duplicate header file names
MD: right, this suggestion doesn’t address conflicting names. Only the source tree dir would change.
MD: example: in qtCreator, it can’t - out of the box - find any of the header files. To make it work you need to make symlinks in every module src dir to the header file dir
Dh: so say in pvData:
bytebuffer.h and bytebuffer.cpp in src/factory/misc then .cpp stays in misc and .h goes into src/factory/misc/pv.
KK: There is a similar issue in Eclipse as in qtCreator.
MD: Maybe every IDE
DH/MK: If we are going to make this change, it’s big and we’ll have to coordinate.
MK: since I have many modules checked out,
MD: git will handle all of the merge - that is, the move of teh header files.
RL: [and GW] in theory but skeptical - but still not a show stopper
MK: if little work is being done in pvDataCPP, then let’s start in that module.
RL: Can MD do it in pvDataCPP and then tell us, so we can all each merge to see how it works.
Consensus: We’ll start to make the header files move in pvDataCPP, and see what effect it has on other developers.
DH: Happy to try this and see what happens - agree.
conclusion: So, MD will make the move of headers in his git - then notify people so we can pull from there to check it out.
RL: SONAME adds a version tag to a library, which helps runtime check that executable is using the right name of a library.
MD: It’s a modification to help EPICS users, not developers. … gives an example.
KK: Does it require additional code?
RL: No, the dynamic linker does the check. [you only need an addition in the makefile that build the module]
GW: Check only major version number, allow API compatibility?
RL, MD: In C++, almost every change affects the binary interface (ABI). Need to match complete version number.
RL: How should we proceed with each module? Should not be done differently in each module.
A common place in the makefiles to put in the version string.
AI on *MD*: Propose a pattern for including the version string.
MD: There will be 2 changes: setting the version number, then in downstream modules you tell it that it depends on upstream module.
DH: presently, you can’t specify the pv request to a rpc. Like to add that. Has anyone looked.
MS: not looked, will do so and merge
Mark wants send a response the priorities. V4 merged with base, more training, address people comparing unfavourably with 0mq and Tango.
Meeting ends: 8:43 am PST