405042 - make patcher2.pl work on old and new build machines

Status: RESOLVED FIXED

(Release Engineering :: General, defect, P2)

Description

[[e-mail] (:bhearsum)]

Attachment: remove default toolkit mozconfig line

patcher2.pl currently uses --enable-default-toolkit=gtk2, which doesn't work on trunk. Removing this line will make patcher2 work on the 1.8 branch and trunk. (I did tests to confirm this).

Comment 1

[Reed Loden [:reed]]

Comment on attachment 289863 [details] [diff] [review]
remove default toolkit mozconfig line

>         # these aren't required and introduce more dependencies
>         $mozconfig .= "ac_add_options --disable-dbus\n";
>         $mozconfig .= "ac_add_options --disable-svg\n";

Is there even a reason to have these options anymore?

Comment 2

[[e-mail] (:bhearsum)]

(In reply to comment #1)
> (From update of attachment 289863 [details] [diff] [review])
> >         # these aren't required and introduce more dependencies
> >         $mozconfig .= "ac_add_options --disable-dbus\n";
> >         $mozconfig .= "ac_add_options --disable-svg\n";
> 
> Is there even a reason to have these options anymore?
> 

I don't know. But considering they're causing no harm I'm inclined to leave them.

Comment 3

[(not currently active) Ted Mielczarek]

patcher just builds the update tools, not an actual gecko, so things like that shouldn't matter except to reduce the number of bogus dependencies.  I wonder if it wouldn't make more sense to stick the update tools in a separate SVN repo or something with a simple makefile, to avoid all the cruft of our build system.

Comment 4

[[e-mail] (:bhearsum)]

(In reply to comment #3)
> patcher just builds the update tools, not an actual gecko, so things like that
> shouldn't matter except to reduce the number of bogus dependencies.  I wonder
> if it wouldn't make more sense to stick the update tools in a separate SVN repo
> or something with a simple makefile, to avoid all the cruft of our build
> system.
> 

It should, definitely. For the purposes of make-it-work-now I think this is OK though.

Comment 5

[[e-mail] (:bhearsum)]

Just wanted to summarize talk in #build earlier today:
* Removing the default toolkit completely will break the *prometheus-vm machines.
* Hard coding gtk2 or cairo-gtk2 will break either trunk or branch.
* It would be good if there was a target to build the update tools that does not run configure.

Comment 6

[Nick Thomas [:nthomas] (UTC+12)]

Comment on attachment 289863 [details] [diff] [review]
remove default toolkit mozconfig line

Unsetting review request until we figure out how to solve this.

Comment 7

[[e-mail] (:bhearsum)]

Attachment: possible patcher2 solution

Here's what I've come up with: patcher2.pl uses pkg-config to test the version of Pango. If it's too old, it uses gtk2 as the default toolkit. I ran this version on staging-prometheus-vm (using MOZILLA_1_9a2_RELEASE), staging-build-console (using MOZILLA_1_9a2_RELEASE), and staging-trunk-automation (using MOZILLA_1_9a8_RELEASE) and it works OK on all of them. It's not an ideal solution, the version numbers will have to be bumped if our Pango minimum version changes but it _does_ avoid branching patcher2.pl.

Comment 8

[Robert Helmer [:rhelmer]]

Comment on attachment 291441 [details] [diff] [review]
possible patcher2 solution

Argh. Yeah, it's kind of nasty but I think the real fix for this would be in the build system (not require configure for update-packaging, be able to turn off default-toolkit, etc.)

Comment 9

[[e-mail] (:bhearsum)]

Checking in patcher2.pl;
/cvsroot/mozilla/tools/patcher/patcher2.pl,v  <--  patcher2.pl
new revision: 1.25; previous revision: 1.24
done