Closed
Bug 208271
Opened 21 years ago
Closed 20 years ago
Remove accessproxy component from build, but keep in tree
Categories
(Core :: Disability Access APIs, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: aaronlev, Assigned: aaronlev)
Details
Attachments
(1 file, 1 obsolete file)
1.51 KB,
patch
|
netscape
:
review+
|
Details | Diff | Splinter Review |
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•21 years ago
|
||
Assignee | ||
Comment 2•21 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)
Comment 3•21 years ago
|
||
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•21 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 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•21 years ago
|
||
Chris, I'm going to write an article for the accessibility projects site so that anyone can use it.
Assignee | ||
Comment 6•21 years ago
|
||
Attachment #124901 -
Attachment is obsolete: true
Assignee | ||
Updated•21 years ago
|
Attachment #124931 -
Flags: review?(seawood)
Comment 7•21 years ago
|
||
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•21 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 9•21 years ago
|
||
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•21 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
Comment 11•21 years ago
|
||
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•20 years ago
|
||
Seawood checked in the remaining part.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•