This sounds like a good idea.  Go ahead and make the change once e-d-s is unbroken :)

Christian: has there been any progress on this?

No, bug 307418 remains.

I tried to add a separate mozilla-1-7 build just for eds, but a) that doubles the pain since now we have to build 2 mozilla branches (which takes ages each!), and b) mozilla 1.8 branch doesn't build without patches (pangocairo patch [] at the very least). cvs builds cannot have patches, and so I tried to add a xulrunner 1.8 tarball build, but that didn't work either because the xulrunner tarball untars into mozilla/ directory...

Created attachment 65640 [details] [review]
Use xulrunner 1.8

Patch to use xulrunner 1.8 (required a change to modtypes/mozillamodule.py), this may be faster to build than Firefox and it works fine (disabling NSS for e-d-s).  (see http://jhbuild.bxlug.be/builds/2006-05-17-0004/ for example)

I took a new look and got e-d-s building successfully against xulrunner 1.8:

 - applying attachment 65640 [details] [review] to build xulrunner in jhbuild;
 - modifying e-d-s configure.in to look for xulrunner pkg-config files;
 - exporting xulrunner lib directory to LD_LIBRARY_PATH (or I would get undefined symbols from libnspr).

the mozillamodule.py part of attachment 65640 [details] [review] has been applied to jhbuild.

2006-06-23  Marco Pesenti Gritti  <marco@gnome.org>

        * jhbuild/modtypes/mozillamodule.py:
        Add xulrunner to app names

This has become a bit more of a problem now as both Epiphany and Yelp have dropped support for mozilla-1-7 and require at least 1.8 branch, so the default setup of jhbuild will fail for both.

Bug 348198 should be fixed on Monday (and I added it to blockers); I also added
a new comment (and the missing patch) to bug 307418, hopefully it gets applied
fast.

evoution and evolution-data-server got fixed; is it ok if I switch jhbuild
2.16 moduleset to xulrunner 1.8 ?

IMHO Firefox (component="browser") is better. Two reasons:

  1. FireFox will be included in all future distros, xulrunner not. So building it in jhbuild tinderboxes could help to re-create a "real" condition.
  2. There is no about:plugins page using xulrunner (a minor issue, but...)

OK, not so strong reasons, but maybe people could like to try FireFox 2.0 :-)

Moreover I think we should notify this change somewhere (d-d-l ml? planet gnome? both?) so people can remove legacy stuff ($prefix/lib/mozilla*, $prefix/include/mozilla*. $prefix/bin/mozilla* and $prefix/share/idl/mozilla*) and rebuild relevant modules.

I would prefer xulrunner since it is smaller than Firefox and less of a moving
target.  Also Mozilla plans seem to target xulrunner 1.9 as a basis for Firefox 3.

Anyway I don't mind the default being to build Firefox, switching to xulrunner
in my builds is not that difficult :)

That said, I won't make a decision here.

Well, NSS and NSPR libs are the same, so no troubles for Evo/E-D-S to use xulrunner or firefox.

Any special needs from Gecko based applications (Ephiphany and Yelp)?

James? you are the master!

Created attachment 69442 [details] [review]
The new patch to use xulrunner

It's just the second half of previous one. Only change moduleset

Created attachment 69443 [details] [review]
The same patch, but using FireFox (compont browser)

> I would prefer xulrunner since it is smaller than Firefox and less of a moving
> target.

I agree, but...

> Also Mozilla plans seem to target xulrunner 1.9 as a basis for Firefox 3.

... IMHO jhbuild should be used to test if GNOME apps under development works in a demi-standard configuration. The gecko 1.9 roadmap should be just a draft, we don't know when it will be available. For the next 6 months/1 year Firefox 2 should be a reasonable target for jhbuild sandboxes, as well as mozilla 1.7 was in the past release cycles.

(In reply to comment #10)
> IMHO Firefox (component="browser") is better. Two reasons:
> 
>   1. FireFox will be included in all future distros, xulrunner not. 
Not true.

> So building
> it in jhbuild tinderboxes could help to re-create a "real" condition.
>   2. There is no about:plugins page using xulrunner (a minor issue, but...)
Very minor indeed.
 
> OK, not so strong reasons, but maybe people could like to try FireFox 2.0 :-)
They can install it from mozilla.org if they want to. Mozilla in jhbuild is here to serve as the embedding package for epiphany, yelp, devhelp and to provide NSS for evo, not to showcase another browser.
 
(In reply to comment #15)
> ... IMHO jhbuild should be used to test if GNOME apps under development works
> in a demi-standard configuration. The gecko 1.9 roadmap should be just a draft,
> we don't know when it will be available. For the next 6 months/1 year Firefox 2
> should be a reasonable target for jhbuild sandboxes, as well as mozilla 1.7 was
> in the past release cycles.

Xulrunner from 1.8 branch should be (as far as I know) fully usable with all concerned gnome modules and there already are distributions shipping xulrunner 1.8.0 as embedding base for gnome (arch linux, debian unstable and suse, there may be others). So IMO there stands nothing against using the 1.8 branch version of xulrunner here. (Trunk has some problems which have yet to be sorted out and it's generally unstable, so I agree we shouldn't go for xulrunner trunk.)

*** Bug 349071 has been marked as a duplicate of this bug. ***

Any progress on this?  Can the patches be applied?

Yelp is starting to receive bug reports / questions about jhbuild failing to compile. (marked as dup above)

Created attachment 70668 [details] [review]
use xulrunner 1.8; with spellchecking extension

This is the same as attachment 69442 [details] [review] plus enabling spellchecking extension,
which can be used by epiphany.

I am going to apply this patch in a few days (unless big concerns are raised).

/me cheers Frederic on

The current fix is not building xulrunner correctly since it passes --enable-application=browser. Looking at the xulrunner-1.5.0.4 tarball, file xulrunner/config/mozconfig shows the correct way to build xulrunner is with these settings:

# This file specifies the build flags for XULRunner.  You can use it by adding:
#  . $topsrcdir/xulrunner/config/mozconfig
# to the top of your mozconfig file.

mk_add_options MOZ_CO_PROJECT=xulrunner
ac_add_options --enable-application=xulrunner

What is actually happening right now is that you are building Firefox from the xulrunner project. That's actually bad since the Mozilla Wiki says that this project does not necessarily contain all the fixes used in the applications like Firefox.

http://wiki.mozilla.org/XUL:Xul_Runner

Created attachment 70874 [details] [review]
Actually build xulrunner application

This is untested. I've never tried building the standalone xulrunner, but this is the proper way to build it.

Thanks for the notice; I patched my local copy, I'll see tomorrow in the
daily builds results if it works.  Hopefully I'll then commit the patch.

One other quick note while I've got your attention. I've built Mozilla extensively on different platforms, so I'm pretty familiar with the build system. Right now, there are a lot of things passed in the configure statement that are unnecessary because they are defaults. It's a pretty cosmetic nitpick. If you're interested, I can open a new bug with a diff and some rationale.

Or, you can read configure.in and find out what the defaults will be for a GNU system.

Ran a quick build (only mozilla, epiphany and yelp) and all went fine (after I
added the file missing from winstripe theme since July 24th); great.

As for other options, they were there before I came so I don't know the rationale
behind them.  Maybe because jhbuild is also used on FreeBSD and Solaris (and...)
and they do not have the same defaults ?  Anyway you can submit a new report and
I'll look into it.