Closed Bug 1038639 Opened 5 years ago Closed 5 years ago

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

Categories

(Firefox Build System :: General, defect)

defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED
mozilla33

People

(Reporter: glandium, Assigned: glandium)

References

Details

Attachments

(1 file, 2 obsolete files)

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.
Blocks: 1036894
Attachment #8456079 - Flags: review?(benjamin)
Assignee: nobody → mh+mozilla
Status: NEW → ASSIGNED
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?
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.
Flags: needinfo?(mh+mozilla)
(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.
(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.
Flags: needinfo?(mh+mozilla)
Attachment #8456505 - Flags: review?(benjamin)
Attachment #8456079 - Attachment is obsolete: true
Attachment #8456079 - Flags: review?(benjamin)
Attachment #8456505 - Attachment is obsolete: true
Attachment #8456505 - Flags: review?(benjamin)
Attachment #8456515 - Flags: review?(benjamin) → review+
https://hg.mozilla.org/mozilla-central/rev/4d1f2d26fef1
https://hg.mozilla.org/mozilla-central/rev/4cbe04a905ef
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla33
Blocks: 1224490
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.
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.