Last Comment Bug 450015 - Remove support for --enable-extensions=all, since we can't remember to feed or walk it
: Remove support for --enable-extensions=all, since we can't remember to feed o...
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: Build Config (show other bugs)
: Trunk
: All All
: -- normal (vote)
: mozilla1.9.1b2
Assigned To: Phil Ringnalda (:philor)
:
Mentors:
: 467704 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-08-10 06:00 PDT by Jens Hatlak (:InvisibleSmiley)
Modified: 2008-12-02 18:54 PST (History)
6 users (show)
philringnalda: in‑testsuite-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Remove it (1.59 KB, patch)
2008-10-26 23:41 PDT, Phil Ringnalda (:philor)
ted: review+
Details | Diff | Review

Description Jens Hatlak (:InvisibleSmiley) 2008-08-10 06:00:02 PDT
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de-AT; rv:1.8.1.16) Gecko/20080702 SeaMonkey/1.1.11
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-AT; rv:1.8.1.16) Gecko/20080702 SeaMonkey/1.1.11

Build environment: MozillaBuild 1.3, MSVC 8, Vista SDK, WinXP; current comm-central etc. pulled with python client.py checkout.

I have --enable-extensions=all,-xmlterm in my .mozconfig. Since the move to hg I'm getting the following error while running make -f client.mk build:

configure: error: Unrecognized extension provided to --enable-extensions

It started with p3p and continued with datetime, finger, cview, tasks, sql and xforms after I had added each one with a minus to the comma-separated list. Then I gave up and tried "default" instead of "all" which seems to work.

Reproducible: Always

Steps to Reproduce:
1. try to run make -f client.mk build on current hg trunk sources with --enable-extensions=all,-xmlterm in .mozconfig
Actual Results:  
I'm getting an error as described above.

Expected Results:  
No error should be returned.

This is a regression.
Comment 1 Stefan [:stefanh] 2008-08-19 05:37:45 PDT
I'm not sure all those options work now - kairo should know, I think.
Comment 2 Mark Banner (:standard8) 2008-08-19 05:54:56 PDT
This is actually a mozilla-central bug, MOZ_EXTENSIONS_ALL in mozilla/configure.in lists out of date items (i.e. not in mozilla-central), and therefore gets it wrong.

comm-central has a MOZ_EXTENSIONS_ALL, but that has no effect, removing that is therefore a different bug.

What needs to happen is for the mozilla-central version to be updated with what it actually supports.

Therefore moving to core -> build config.
Comment 3 Robert Kaiser (not working on stability any more) 2008-08-19 06:34:57 PDT
--enable-extensions=all has been deprecated for a long time and is not really maintained, just fixed sometimes as we go. I wonder if we might actually want to completely remove that option.
Comment 4 Phil Ringnalda (:philor) 2008-10-26 23:41:50 PDT
Created attachment 344851 [details] [diff] [review]
Remove it

/me looks around for anyone wanting it fixed...

Well, alrighty then!
Comment 5 Ted Mielczarek [:ted.mielczarek] 2008-10-27 10:06:34 PDT
Comment on attachment 344851 [details] [diff] [review]
Remove it

Seems like an attractive nuisance that ought to go away.
Comment 6 Phil Ringnalda (:philor) 2008-10-27 19:56:02 PDT
http://hg.mozilla.org/mozilla-central/rev/b10cc446eb4c
Comment 7 Justin Wood (:Callek) 2008-10-27 20:10:21 PDT
Is it really worth error here, and not simply a warn?

If so, I'm ok with it just wondering why we're forcing removing the option from local mozconfigs this way vs just warning on its presence
Comment 8 Karsten Düsterloh 2008-10-28 11:45:28 PDT
> If so, I'm ok with it just wondering why we're forcing removing the option from
> local mozconfigs this way vs just warning on its presence

Probably because I won't notice else. *narf*
Comment 9 Phil Ringnalda (:philor) 2008-10-28 11:55:38 PDT
No, you were just a bonus bit of evil pleasure: really, I'm gunning for bz, who's practically the only person to ever mention it being broken for as long as I've been around. When he builds with a mozconfig that he thinks will tell him whether or not his core change will break compiling any extensions, I want him to know unambiguously that he can no longer count on it working.
Comment 10 Boris Zbarsky [:bz] 2008-10-28 21:54:20 PDT
OK, so at this point how _do_ I sanely do "build the maximal set of code that might break because of these changes I'm making"?
Comment 11 Phil Ringnalda (:philor) 2008-10-28 22:33:02 PDT
I can't imagine a sane way, in the current world.

Of course, it won't involve Firefox, or mozilla-central, if you actually want to test your changes against extensions, considering how many didn't make that cut.

I guess you do a SeaMonkey comm-central pull, plus some added CVS checkouts, and then some shell scripting to get from ls src/mozilla/extensions/ to a list which doesn't include those that aren't going to give you any pleasure, like access-builtin on Mac, since you don't want to just have a personal hard-coded list that won't include new ones.
Comment 12 Boris Zbarsky [:bz] 2008-10-29 03:22:24 PDT
> When he builds with a mozconfig that he thinks will tell him whether or not his
> core change will break compiling any extensions, I want him to know
> unambiguously that he can no longer count on it working.

Maybe I'm missing something, but I got no error messages.  The relevant configure option is:

ac_add_options --enable-extensions=all,-typeaheadfind,-wallet,-sroaming,-help,-p3p,-venkman,-irc,-datetime,-finger,-cview,-tasks,-sql,-xforms,-schema-validation

(have to subtract out the things that don't actually build and all).

So I strongly suspect that the main effect of this change will be to silently disable DOM inspector in my builds.  That could be pretty unfortunate come me trying to debug stuff tomorrow.  :(
Comment 13 Boris Zbarsky [:bz] 2008-10-29 03:23:49 PDT
Er, nevermind.  Some of my builds do get the error message.  Interesting.
Comment 14 Phil Ringnalda (:philor) 2008-10-29 08:55:37 PDT
So you were using "all" as an incredibly verbose way of saying "default,inspector"?

*So* not feeling guilty about disabling that for you.
Comment 15 Boris Zbarsky [:bz] 2008-10-29 09:56:37 PDT
Dunno.  I only disabled the extensions that actually failed to build.

It's certainly not the same as "default,inspector", since it also included "layout-debug"
Comment 16 Karsten Düsterloh 2008-10-29 16:14:38 PDT
> So you were using "all" as an incredibly verbose way of saying
> "default,inspector"?

Erm, no. When I (like Boris, it seems) set =all in ye olden CVS days, it was working. The blacklist (mainly) grew with the switch to c-c, not because the extensions wouldn't work - I guess cview and others would still build if they were there...
Comment 17 Phil Ringnalda (:philor) 2008-10-29 20:55:28 PDT
bz: yeah, sorry, I was going back and forth between too many tabs. Unless you say not to, I'll get you a list of what mozilla-central extensions should build on each platform sometime this weekend, since we shouldn't spend your time on finding that out. Your own list of all the extensions you want to build may not automatically get new things added, but then, there's absolutely no reason to believe that using "all" would have, either. widgetutils didn't get added, metrics looks to be 2.5 years old without being in the list, jssh is a bit over 3 without ever having been all...

both of you: let me know if you figure out something that would work, that you need my help with. Clearly, that doesn't involve a list like the one that was in mozilla-central, of a semi-random subset of all the extensions that have ever been in CVS. If comm-central wants to be able to pass a list down to mozilla-central, but can't, that should be filed if it isn't. Anyone who thinks mozilla-central should have an "all" that covers its in-the-repo but not default extensions is more than welcome to either write the patch and try to convince their reviewer that this time we'll remember to feed and walk our pet, or to convince me that I should write the patch and convince someone else.

Other than that, dunno. I just closed a bug from 2001, where dbaron was (and then wasn't) trying to deal with the fact that all didn't actually include all, and another from 2003 where sicking wanted to prohibit putting a tinderbox that built with all anywhere that he would be expected to see it, because all included random totally unmaintained crap. Add those two abandoned bugs onto the mountain you need to climb, to have a way of specifying nondefault extensions other than by building and maintaining your own list.
Comment 18 Boris Zbarsky [:bz] 2008-10-29 21:38:22 PDT
I'm probably just going to build the things I need to get work done, and not worry about breaking other stuff.
Comment 19 Robert Kaiser (not working on stability any more) 2008-12-02 18:54:02 PST
*** Bug 467704 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.