Remove accessproxy component from build, but keep in tree

RESOLVED FIXED

Status

()

RESOLVED FIXED
16 years ago
8 years ago

People

(Reporter: aaronlev, Assigned: aaronlev)

Tracking

Trunk
x86
Windows 2000
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Assignee)

Description

16 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

16 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

16 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

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

Comment 6

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

Updated

16 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

16 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

16 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

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