1038639 - Remove --with-libxul-sdk and --with-system-libxul

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[Mike Hommey [:glandium]]

It's not really working well, and I'm going to break it in bug 1036894. Not that it's impossible not to break it, but I figured considering the current state of affairs, I don't think it's worth the effort.

Comment 1

[Mike Hommey [:glandium]]

Attachment: Remove --with-libxul-sdk and --with-system-libxul

Comment 2

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

Comment on attachment 8456079 [details] [diff] [review]
Remove --with-libxul-sdk and --with-system-libxul

Review of attachment 8456079 [details] [diff] [review]:
-----------------------------------------------------------------

::: configure.in
@@ +4072,5 @@
>  if test -n "$WITH_APP_BASENAME" ; then
>      MOZ_APP_BASENAME="$WITH_APP_BASENAME"
>  fi
>  
>  # Now is a good time to test for logic errors, define mismatches, etc.

Keep this?

Comment 3

[Benjamin Smedberg]

Good riddance to --with-system-libxul.

The loss of --with-libxul-sdk makes me a little sad, primarily because it means that people building binary XPCOM components are going to have a much harder time of it. But we want to discourage that anyway. I presume you've checked that no Linux distros are still using that config?

In what ways will bug 1036894 break this config, and if somebody cared about it would they be able to recover it?

If it's going to be broken, we should definitely remove the configure flag or make it AC_ERROR. I'm not convinced that we should remove all the in-tree bits yet until we're sure that we won't accept them back ever.

Comment 4

[Joshua Cranmer [:jcranmer]]

(In reply to Benjamin Smedberg  [:bsmedberg] Away 19-July through 3-Aug from comment #3)
> Good riddance to --with-system-libxul.
> 
> The loss of --with-libxul-sdk makes me a little sad, primarily because it
> means that people building binary XPCOM components are going to have a much
> harder time of it. But we want to discourage that anyway. I presume you've
> checked that no Linux distros are still using that config?

The only person I know who builds binary XPCOM components does it by sticking his code in mozilla/extensions/{name} and using --enable-extensions.

Comment 5

[Mike Hommey [:glandium]]

(In reply to Benjamin Smedberg  [:bsmedberg] Away 19-July through 3-Aug from comment #3)
> Good riddance to --with-system-libxul.
> 
> The loss of --with-libxul-sdk makes me a little sad, primarily because it
> means that people building binary XPCOM components are going to have a much
> harder time of it. But we want to discourage that anyway. I presume you've
> checked that no Linux distros are still using that config?

The only distros that I know were using it were Fedora and Debian. Fedora has stopped using it a while ago, and Debian more recently.

> In what ways will bug 1036894 break this config, and if somebody cared about
> it would they be able to recover it?

It will only break this config by not supporting it. That is, I want to avoid the extra hoops required to continue supporting it. /But/ further down the road, it should be possible to support it again, if we really want to.

> If it's going to be broken, we should definitely remove the configure flag
> or make it AC_ERROR. I'm not convinced that we should remove all the in-tree
> bits yet until we're sure that we won't accept them back ever.

Ok.

Comment 6

[Mike Hommey [:glandium]]

Attachment: Remove --with-libxul-sdk and --with-system-libxul

Comment 7

[Mike Hommey [:glandium]]

Attachment: Remove --with-libxul-sdk and --with-system-libxul

Comment 8

[Mike Hommey [:glandium]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/4d1f2d26fef1

Comment 9

[Mike Hommey [:glandium]]

And a fixup:
https://hg.mozilla.org/integration/mozilla-inbound/rev/4cbe04a905ef

Comment 10

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/4d1f2d26fef1
https://hg.mozilla.org/mozilla-central/rev/4cbe04a905ef

Comment 11

[Connor Behan]

I'm not a fan of this. Builds --with-libxul-sdk have always worked for me and it's by far the most sensible thing to do for a person who regularly dabbles with simple UI patches and doesn't want to rebuild the whole engine. I also use instantbird and want it to be 3MB instead of 90MB.