Merge lp://staging/~sergei.glushchenko/percona-server/5.5-BT32840-ps-bug1196460 into lp://staging/percona-server/5.5

http://jenkins.percona.com/job/percona-server-5.5-param/783/

Why there is need to add -DDISABLE_DTRACE option in addition to the already-existing -DENABLE_DTRACE one?

Passing --enable-dtrace to cmake/configure won't take any effect. Moreover, providing --enable-dtrace would mean that dtrace is turned off by default, which changes current behavior. Currently it is turned ON by default. Current meaning of ENABLE_DTRACE variable is more appropriate to name HAVE_DTRACE.

What about adding -DENABLE_DTRACE=OFF to cmake?

Let's for a moment not consider the configure wrapper with --options.

What default value would ENABLE_DTRACE have?
If ON - we need to force it to OFF if dtrace is not supported.
If OFF - we will break current behavior.

I mean, the default behavior is to link dtrace wherever we find support for it. To produce dtrace-free binary even if support is present, I add DISABLE_DTRACE. I think it is reasonable.

Hi Sergei,

On Wed, 03 Jul 2013 13:12:27 -0000, Sergei Glushchenko wrote:
> What default value would ENABLE_DTRACE have?
> If ON - we need to force it to OFF if dtrace is not supported.
> If OFF - we will break current behavior.
>

The former I think is more reasonable than adding DISABLE_DTRACE. I
don't even understand what goal does -DDISABLE_DTRACE tries to achieve.
I.e. what's wrong with cmake -DENABLE_DTRACE=0?

Alexey, Laurynas,

Could you please provide me desired behavior for following combinations:
1. ENABLE_DTRACE=ON, dtrace support not found
2. ENABLE_DTRACE=ON, dtrace support found
3. ENABLE_DTRACE=OFF, dtrace support not found
4. ENABLE_DTRACE=OFF, dtrace support found
5. ENABLE_DTRACE not specified, dtrace support found
6. ENABLE_DTRACE not specified, dtrace support not found

I really don't know which behavior is desired for some of them.

Thanks,
Sergei

Hi Sergei,

On Fri, 05 Jul 2013 10:53:24 -0000, Sergei Glushchenko wrote:
> Alexey, Laurynas,
>
> Could you please provide me desired behavior for following combinations:
> 1. ENABLE_DTRACE=ON, dtrace support not found
> 2. ENABLE_DTRACE=ON, dtrace support found
> 3. ENABLE_DTRACE=OFF, dtrace support not found
> 4. ENABLE_DTRACE=OFF, dtrace support found
> 5. ENABLE_DTRACE not specified, dtrace support found
> 6. ENABLE_DTRACE not specified, dtrace support not found
>
> I really don't know which behavior is desired for some of them.
>

Build with DTrace support when possible (there's DTrace support) *and*
ENABLE_DTRACE=ON. When not specified, use the default value?

Yes, Alexey, this looks reasonable, but the question was mostly about which value is default? Doc states it is OFF, but the behavior is like I'd specified ENABLE_DTRACE=ON.

So, when I implement ENABLE_DTRACE=ON/OFF switch for user, should I set it OFF by default?

Hi Sergei,

On Mon, 08 Jul 2013 08:46:28 -0000, Sergei Glushchenko wrote:
> So, when I implement ENABLE_DTRACE=ON/OFF switch for user, should I set it OFF by default?
>

Yes, I think it should be OFF by default. But cmake should also fail
with an error when building with -DENABLE_DTRACE=ON and the dtrace
binary is not found.

Thank you, this is good for me. My concerns was about that by implementing this we breaking current behavior, which is undocumented, but somebody may already rely on it. If it is OK by you, it is fine by me as well.

Changes: ENABLE_DTRACE instead of DISABLE_DTRACE.

Approving. I'll hold off merging it for a couple of days, in case Alexey or somebody else has objections.

Sergei, consider submitting the patch under OCA to Oracle.

Looks good to me.