450015 - Remove support for --enable-extensions=all, since we can't remember to feed or walk it

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[Jens Hatlak (:InvisibleSmiley)]

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]]

I'm not sure all those options work now - kairo should know, I think.

Comment 2

[Mark Banner (:standard8)]

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]

--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)]

Attachment: Remove it

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

Well, alrighty then!

Comment 5

[(not currently active) Ted Mielczarek]

Comment on attachment 344851 [details] [diff] [review]
Remove it

Seems like an attractive nuisance that ought to go away.

Comment 6

[Phil Ringnalda (:philor)]

http://hg.mozilla.org/mozilla-central/rev/b10cc446eb4c

Comment 7

[Justin Wood (:Callek)]

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]

> 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)]

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 [:bzbarsky]]

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)]

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 [:bzbarsky]]

> 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 [:bzbarsky]]

Er, nevermind.  Some of my builds do get the error message.  Interesting.

Comment 14

[Phil Ringnalda (:philor)]

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 [:bzbarsky]]

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]

> 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)]

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 [:bzbarsky]]

I'm probably just going to build the things I need to get work done, and not worry about breaking other stuff.