If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Remove accessproxy component from build, but keep in tree

RESOLVED FIXED

Status

()

Core
Disability Access APIs
RESOLVED FIXED
15 years ago
6 years ago

People

(Reporter: Aaron Leventhal, Assigned: Aaron Leventhal)

Tracking

Trunk
x86
Windows 2000
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

1.51 KB, patch
hacker formerly known as seawood@netscape.com
: review+
Details | Diff | Splinter Review
(Assignee)

Description

15 years ago
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.
(Assignee)

Comment 1

15 years ago
Created attachment 124901 [details] [diff] [review]
Even if built, don't install. Not sure how to remove if from --enable-extensions=all
(Assignee)

Comment 2

15 years ago
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.
Attachment #124901 - Flags: review?(seawood)
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 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 .
Attachment #124901 - Flags: review?(seawood) → review-
(Assignee)

Comment 5

15 years ago
Chris, I'm going to write an article for the accessibility projects site so that
anyone can use it.
(Assignee)

Comment 6

15 years ago
Created attachment 124931 [details] [diff] [review]
New patch with cls's improvements
Attachment #124901 - Attachment is obsolete: true
(Assignee)

Updated

15 years ago
Attachment #124931 - Flags: review?(seawood)
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
Attachment #124931 - Flags: review?(seawood) → review+
(Assignee)

Comment 8

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

Okay, will do. Thanks.
Attachment #124931 - Flags: superreview?(brendan)
Comment on attachment 124931 [details] [diff] [review]
New patch with cls's improvements

You need only r= for build changes.

/be
Attachment #124931 - Flags: superreview?(brendan)
(Assignee)

Comment 10

15 years ago
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
Afaict, the updated configure script was never checked in and the autoupdate
script didn't work.  I just checked in the updated script.
(Assignee)

Comment 12

14 years ago
Seawood checked in the remaining part.
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.