204292 - Fix --disable-activex

Status: RESOLVED INCOMPLETE

(SeaMonkey :: Build Config, defect)

Description

[Brian Ryner (not reading)]

Passing --disable-activex to configure used to simply disable building the
activex control in embedding/browser/activex.  Now, it causes the following error:

configure: error: Cannot enable ActiveX scripting support when ActiveX support
is disabled.

There should be an option to disable building the activex control independent of
any other options for IDispatch and the activex plugin.  I think those are both
controlled by --disable-activex-scripting, so I'm thinking we can just restore
--disable-activex to mean "don't build the activex gecko wrapper".

Comment 1

[David Bradley]

We're still working on this in bug 203362 I believe, but it wasn't reopened, so
maybe this is a better place to handle that.

Comment 2

[Adam Lock]

Attachment: Patch

Patch, simplified from 203362

Comment 3

[Adam Lock]

Attachment: Patch

Patch again

Comment 4

[Adam Lock]

Attachment: Patch again

Third time lucky...

Comment 5

[Adam Lock]

Comment on attachment 122447 [details] [diff] [review]
Patch again

Requesting an r= on this please

Comment 6

[hacker formerly known as [e-mail]]

Comment on attachment 122447 [details] [diff] [review]
Patch again

You're still using the plugin variable to test whether to build the control. 
And since you removed MOZ_NO_ACTIVEX_SUPPORT from autoconf.mk.in, it will never
be set so the test in embedding/browser/Makefile.in will fail and activex will
never be built.


How does this patch fit in with our current nightly automation setup?  Since we
use the same base configuration for all builds, how will the plugin ever get
built w/o tainting the original tree?

Comment 7

[locka]

Attachment: Updated patch

Fixes typo, adds missing makefile.

The patch deliberately does not build the plugin but enables the scripting.
Anyone who wants to build the plugin has to set the --enable-activex-plugin
flag for themselves or step in afterwards and build it manually. This means the
plugin will no longer be built.

Comment 8

[Adam Lock]

Comment on attachment 122500 [details] [diff] [review]
Updated patch

Requesting r on fixed version, thanks

Comment 9

[David Bradley]

With XPC_IDISPATCH_SUPPORT = @MOZ_ACTIVEX_SCRIPTING_SUPPORT@ is this still going
to build the IDispatch code in Mozilla by default? It should be be building the
IDispatch code even if we're not building and/or installing the plugin, so that
if it's installed later it will be scriptable. (Sorry I'm still trying to figure
out how the build machinery works).

Comment 10

[Adam Lock]

MOZ_ACTIVEX_SCRIPTING_SUPPORT is defined to be 1 on Win32 platforms, so yes
MOZ_ACTIVEX_SCRIPTING_SUPPORT and XPC_IDISPATCH_SUPPORT should both be defined
in autoconf.mk by default. This means scripting support is built but the plugin
(MOZ_ACTIVEX_PLUGIN_SUPPORT) is not.

Previously it used to be built but not exported which didn't give much in return
except to confuse everyone a great deal.

Comment 11

[Adam Lock]

Comment on attachment 122500 [details] [diff] [review]
Updated patch

Requesting 1.4b approval for checkin. The new build switches resolve the
confusion and ambiguity concerning what --disable-activex means and remove the
need to build the plugin when it is not being used or exported.

Comment 12

[Asa Dotzler [:asa]]

Comment on attachment 122500 [details] [diff] [review]
Updated patch

a=asa (on behalf of drivers) for checkin to 1.4b.

Comment 13

[locka]

Attachment: Updated patch

Simplified again, this patch removes the --enable-activex-plugin switch, but
builds the plugin when --enable-activex-scripting is defined. The plugin is
still not exported unless MOZ_USE_ACTIVEX_PLUGIN is defined.

This almost puts us almost back to square 1 concerning difficulties surrounding
the plugin and not exposing it to dist/bin but needing to build. The patch
should at least fix the confusion of what --enable-activex does.

Comment 14

[David Bradley]

Adam, I had forgotten about this bug. Is this still valid? Should you own this?

Comment 15

[Adam Lock]

I'll take it for now. I might close it and reopen it if necessary.

Comment 16

[Anton van Bohemen]

Is this bug still valid? I'm not an expert, but since it is not working in
Firefox, it should make FF builds a lot smaller if the control is not included.

Comment 17

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614