208271 - Remove accessproxy component from build, but keep in tree

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[Aaron Leventhal]

I'm planning to start updating the accessproxy component again soon, because
there is s a screen reader vendor who wants to start using it.

However, they will be installing the component as part of their own software, in
their own installer.

I want to remove this from the normal build, because it is really a special
component that needs to be built on an individual basis.

Comment 1

[Aaron Leventhal]

Attachment: Even if built, don't install. Not sure how to remove if from --enable-extensions=all

Comment 2

[Aaron Leventhal]

Comment on attachment 124901 [details] [diff] [review]
Even if built, don't install. Not sure how to remove if from --enable-extensions=all

Not sure if this is enough to allow me NPOB "Not Part Of Build" checkins.
That's part of the goal here.

Comment 3

[hacker formerly known as [e-mail]]

I don't understand the desire to keep code in the tree that *one* customer is
going to use.  IMO, it should be moved to a private repository (or not pulled by
default at the very least) or made available for everyone.

Comment 4

[hacker formerly known as [e-mail]]

Comment on attachment 124901 [details] [diff] [review]
Even if built, don't install. Not sure how to remove if from --enable-extensions=all

NO_INSTALL only prevents the code from being installed during a 'make install'.
You need to also set NO_DIST_INSTALL to prevent it from being installed into
$(DIST).  
To remove accessproxy from --enable-extensions=all, you need to remove it from
the MOZ_EXTENSIONS_DEFAULT & MOZ_EXTENSIONS_ALL lists in configure.in .

Comment 5

[Aaron Leventhal]

Chris, I'm going to write an article for the accessibility projects site so that
anyone can use it.

Comment 6

[Aaron Leventhal]

Attachment: New patch with cls's improvements

Comment 7

[hacker formerly known as [e-mail]]

Comment on attachment 124931 [details] [diff] [review]
New patch with cls's improvements

The empty 'install::' ruleset isn't needed.  gmake shouldn't choke on the empty
rule with the defines immediately below it that but you should probably remove
the empty rule just to be sure. r=cls

Comment 8

[Aaron Leventhal]

Comment on attachment 124931 [details] [diff] [review]
New patch with cls's improvements

Okay, will do. Thanks.

Comment 9

[Brendan Eich [:brendan]]

Comment on attachment 124931 [details] [diff] [review]
New patch with cls's improvements

You need only r= for build changes.

/be

Comment 10

[Aaron Leventhal]

Chris, for some reason this didn't actually remove it from the tinderbox builds.
I see:
ac_add_options --enable-extensions=all
in the tinderbox scripts.

And the line from configure.in has been changed. I don't want to remove it from
allmakefiles.sh, because we occasionally will need to specifically
--enable-extensions=access-builtin

Comment 11

[hacker formerly known as [e-mail]]

Afaict, the updated configure script was never checked in and the autoupdate
script didn't work.  I just checked in the updated script.

Comment 12

[Aaron Leventhal]

Seawood checked in the remaining part.