558180 - Move mozconfigs into source tree

Status: RESOLVED FIXED

(Release Engineering :: General, defect, P3)

Description

[Chris AtLee [:catlee]]

It makes more sense for the mozconfigs used for builds to be in the source tree instead of in buildbot-configs.

Two things need to happen:
- Adding mozconfigs into source tree

- Updating our factories to use this mozconfig instead of the one from buildbot-configs

Comment 1

[(not currently active) Ted Mielczarek]

This would prevent stuff like bug 659630 from happening.

Comment 2

[Robert Kaiser]

If that's done, it makes sense to put them under ${srcdir}/${MOZ_BUILD_APP}/ somewhere, I'd guess inside the config/ subdir there makes sense, i.e. for Firefox that would be under browser/config/

Comment 3

[Armen [:armenzg]]

I am marking this bug as tracking for the day we do merges.

If this is not ready for the next train we should do it manually something similar to what we did it on bug 658167#c4.

> I did this:
> * for each platform I cd into it and run this:
> > rsync -r mozilla-central/* mozilla-aurora
> * I added new files like this:
> > for file in `hg st -un`; do hg add $file; done
> * then I run this:
> > for file in `find . -type f -name mozconfig | grep aurora`; do sed s/nightly/aurora/ < $file > $file.2; mv $file.2 $file; done
> 
> The last one fixes keeping the right update channel.

I hope I got the flags right.

Comment 4

[Armen [:armenzg]]

Clearing tracking-firefox5 flag as this was not accomplished during the firefox5 train.

For July 5th we have the workaround mentioned on comment 3.

This is still wanted so mozconfig changes like gcc-4.5 can get all the way from m-c to mozilla-release without human intervention.

I can give a hand with this.

Comment 5

[Chris AtLee [:catlee]]

So I've got the buildbot side of things figured out. What I'm stuck on is a few related issues:

* Once the mozconfigs are in the source tree, how do we manage the update channel? Currently this is set in the mozconfig with something like
ac_add_options --enable-update-channel=nightly

or 

ac_add_options --enable-update-channel=nightly-tracemonkey

* How do we ensure that repo-specific flags in the mozconfig are not accidentally merged into m-c from a project branch?

Comment 6

[(no longer active)]

(In reply to comment #5)
> * How do we ensure that repo-specific flags in the mozconfig are not
> accidentally merged into m-c from a project branch?

My suggestion to Chris was to have one mozconfig per project branch (for those which need custom mozconfigs)

Comment 7

[(not currently active) Ted Mielczarek]

We could do a mozconfig-common and source it from individual project branch mozconfigs, all in-tree, or have a common mozconfig that uses an env var to set certain flags.

Comment 8

[Chris AtLee [:catlee]]

Attachment: mozconfigs in the tree!

Comment 9

[Chris AtLee [:catlee]]

Attachment: Using in-tree mozconfigs

Comment 10

[Armen [:armenzg]]

Can we also move the mobile mozconfigs? or use a separate bug?

Comment 11

[(not currently active) Ted Mielczarek]

Comment on attachment 544057 [details] [diff] [review]
mozconfigs in the tree!

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

I'm okay with all of this except the xulrunner mozconfigs.

::: browser/config/mozconfigs/win64/xulrunner
@@ +1,1 @@
> +ac_add_options --target=x86_64-pc-mingw32

Why are there xulrunner mozconfigs under browser/ ? Surely these want to be under xulrunner/config...

Comment 12

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

Comment on attachment 544057 [details] [diff] [review]
mozconfigs in the tree!

I like the way you drop the directories (hopefully we won't need nightly-rpm and qt-rpm at some point), and really clean up the Mac configs. macosx64/shark should be in macosx-universal/ though, and I agree with ted's comments about xulrunner. Oh, and if we can disambiguate mobile-for-devices and mobile-for-desktop explicitly there is free booze in your future.

What are you thinking of doing for release ? codecoverage is missing too.

For the update channel, I wonder if we can write something like
  ac_add_options --enable-update-channel=${MOZ_UPDATE_CHANNEL}
so that it's clear the value is coming from the environment. Easy to miss that sort of thing in the list of environment vars in a log, and buildbot code is pretty opaque unless you're used to it. (As I mentioned on IRC there's no need to special case shark.)

A small nit, but having a mozconfig file and mozconfigs/ dir in browser/config/ is a bit confusing to newbies. Perhaps rename mozconfigs dir to indicate it's for the build infrastructure.

Comment 13

[Chris AtLee [:catlee]]

Attachment: mozconfigs in the tree!

Comment 14

[Chris AtLee [:catlee]]

Attachment: Using in-tree mozconfigs

Comment 15

[Chris AtLee [:catlee]]

Attachment: buildbot-config changes

we'll leave the old ones around for now

Comment 16

[Chris AtLee [:catlee]]

I think the repack scripts will need to be updated as well...

Comment 17

[[e-mail] (:bhearsum)]

Comment on attachment 546875 [details] [diff] [review]
buildbot-config changes

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

::: mozilla/config.py
@@ +1174,5 @@
>  BRANCHES['shadow-central']['platforms']['macosx64']['env']['MOZ_SYMBOLS_EXTRA_BUILDID'] = 'macosx64-shadow-central'
>  
>  ######## mozilla-release
>  BRANCHES['mozilla-release']['repo_path'] = 'releases/mozilla-release'
> +BRANCHES['mozilla-release']['update_channel'] = 'release'

By setting this we'll end up producing on-change builds on the release channel, which will end up with stranding anyone using it (until AUS3 comes around...). Not that they won't be if we don't set it, but at least we won't be knowingly stranding people on the "release" channel. Maybe I'm making it out to be a bigger deal than it is, though?

Comment 18

[Chris AtLee [:catlee]]

(In reply to comment #17)
> Comment on attachment 546875 [details] [diff] [review] [review]
> buildbot-config changes
> 
> Review of attachment 546875 [details] [diff] [review] [review]:
> -----------------------------------------------------------------
> 
> ::: mozilla/config.py
> @@ +1174,5 @@
> >  BRANCHES['shadow-central']['platforms']['macosx64']['env']['MOZ_SYMBOLS_EXTRA_BUILDID'] = 'macosx64-shadow-central'
> >  
> >  ######## mozilla-release
> >  BRANCHES['mozilla-release']['repo_path'] = 'releases/mozilla-release'
> > +BRANCHES['mozilla-release']['update_channel'] = 'release'
> 
> By setting this we'll end up producing on-change builds on the release
> channel, which will end up with stranding anyone using it (until AUS3 comes
> around...). Not that they won't be if we don't set it, but at least we won't
> be knowingly stranding people on the "release" channel. Maybe I'm making it
> out to be a bigger deal than it is, though?

MOZ_UPDATE_CHANNEL won't get set in the environment unless create_snippet is also true, which it isn't for mozilla-release.

Comment 19

[(not currently active) Ted Mielczarek]

Comment on attachment 546873 [details] [diff] [review]
mozconfigs in the tree!

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

This looks good to me. There was some discussion on IRC about making it easier for developers to use the in-tree mozconfigs to get builds matching what we produce on Tinderbox, which would involve figuring out a way around hardcoded paths, but we can punt that to a followup bug. The benefits here should be pretty great without any additional work.

Comment 20

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

Comment on attachment 546873 [details] [diff] [review]
mozconfigs in the tree!

>+. $topsrcdir/configs/mozilla2/win32/include/choose-make-flags

Eh?

Comment 21

[[e-mail] (:bhearsum)]

(In reply to comment #18)
> (In reply to comment #17)
> > Comment on attachment 546875 [details] [diff] [review] [review] [review]
> > buildbot-config changes
> > 
> > Review of attachment 546875 [details] [diff] [review] [review] [review]:
> > -----------------------------------------------------------------
> > 
> > ::: mozilla/config.py
> > @@ +1174,5 @@
> > >  BRANCHES['shadow-central']['platforms']['macosx64']['env']['MOZ_SYMBOLS_EXTRA_BUILDID'] = 'macosx64-shadow-central'
> > >  
> > >  ######## mozilla-release
> > >  BRANCHES['mozilla-release']['repo_path'] = 'releases/mozilla-release'
> > > +BRANCHES['mozilla-release']['update_channel'] = 'release'
> > 
> > By setting this we'll end up producing on-change builds on the release
> > channel, which will end up with stranding anyone using it (until AUS3 comes
> > around...). Not that they won't be if we don't set it, but at least we won't
> > be knowingly stranding people on the "release" channel. Maybe I'm making it
> > out to be a bigger deal than it is, though?
> 
> MOZ_UPDATE_CHANNEL won't get set in the environment unless create_snippet is
> also true, which it isn't for mozilla-release.

Cool!

Comment 22

[[e-mail] (:bhearsum)]

Comment on attachment 546875 [details] [diff] [review]
buildbot-config changes

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

Comment 23

[[e-mail] (:bhearsum)]

Comment on attachment 546874 [details] [diff] [review]
Using in-tree mozconfigs

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

Comment 24

[Chris AtLee [:catlee]]

(In reply to comment #20)
> Comment on attachment 546873 [details] [diff] [review] [review]
> mozconfigs in the tree!
> 
> >+. $topsrcdir/configs/mozilla2/win32/include/choose-make-flags
> 
> Eh?

Good catch, fixed in my copy. I'm going to leave choose-make-flags in win32, so win64 builds will do
. topsrcdir/browser/config/mozconfigs/win32/choose-make-flags

Comment 25

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

Comment on attachment 546873 [details] [diff] [review]
mozconfigs in the tree!

>diff --git a/browser/config/mozconfigs/linux32/codecoverage b/browser/config/mozconfigs/linux32/codecoverage
>diff --git a/browser/config/mozconfigs/linux64/codecoverage b/browser/config/mozconfigs/linux64/codecoverage

These won't be used yet, since the CodeCoverageFactory is derived from UnittestBuildFactory. So either don't forget to check for mozconfig changes when updating the factories, or leave these new files out if you don't think it's going to happen for a while.

>diff --git a/browser/config/mozconfigs/linux32/l10n-mozconfig b/browser/config/mozconfigs/linux32/l10n-mozconfig
>+ac_add_options --enable-update-channel=beta

This file is only used for releases IIRC, and I agree with your comment about needing to update the repack scripts. You've left in this hard-coded channel reference in the meantime ?

>diff --git a/browser/config/mozconfigs/linux32/xulrunner b/browser/config/mozconfigs/linux32/xulrunner

Please remove these xulrunner configs in browser/.

>diff --git a/browser/config/mozconfigs/macosx64/shark b/browser/config/mozconfigs/macosx64/shark

This one can go now the config is in macosx-universal/.

>diff --git a/mobile/config/mozconfigs/android/nightly b/mobile/config/mozconfigs/android/nightly
>+ac_add_options --enable-update-channel=nightly

Why isn't this one ${MOZ_UPDATE_CHANNEL} ? I double checked that MOZ_UPDATE_CHANNEL is set in call to 'make -f client.mk' for the Android nightly on m-c.

>diff --git a/mobile/config/mozconfigs/linux-desktop/l10n-mozconfig b/mobile/config/mozconfigs/linux-desktop/l10n-mozconfig

Presumably not used until repack scripts get the treatment. See above.

r+ with duplicated configs removed and a plan for dealing with anything not using MercurialBuildFactory/NightlyBuildFactory.

Deployment note - as these changes get merged from m-c to other development branches we'll have to make sure any custom changes are preserved. Eg enabling mac a11y in the a11y branch.

Comment 26

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

Comment on attachment 546874 [details] [diff] [review]
Using in-tree mozconfigs

>diff --git a/process/release.py b/process/release.py
>                 env = builder_env.copy()
>                 env.update(pf['env'])
>+                if 'update_channel' in branchConfig:
>+                    env['MOZ_UPDATE_CHANNEL'] = branchConfig['update_channel']

This might not be necessary here, we seem to repack nightlies without ever calling configure with a update channel argument. But if it is then it should be done for the N parallel builders as well as the standalone repacks. I suggest moving the env setup to the top of the loop |if platform in releaseConfig['l10nPlatforms']:| and using it for both, rather than creating the env twice. Need to update create-release-repacks.py so that it uses the right mozconfig too. 

r+ with that fixed.

Comment 27

[Aki Sasaki (not active)]

Bear just landed some ndk5-related android mozconfig changes in bug 657723; sorry for the bitrot.

Could we get those carried over?

Comment 28

[Chris AtLee [:catlee]]

Attachment: refreshed mozconfigs

Nick, I think I've addressed all your comments.

Changes from the last patch:
- Use ${MOZ_UPDATE_CHANNEL} in l10n-mozconfig
- Adding --enable-js-diagnostics to nigtlies
- Removing xulrunner mozconfigs from browser/
- Using arm-linux-androideabi for android builds, and new ndk

Comment 29

[(not currently active) Ted Mielczarek]

Comment on attachment 553177 [details] [diff] [review]
refreshed mozconfigs

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

I'm not actually going to read these all again, so rs=me

Comment 30

[Chris AtLee [:catlee]]

Attachment: Using in-tree mozconfigs

Comment 31

[Matheus Kerschbaum]

(In reply to Chris AtLee [:catlee] from comment #28)
> Created attachment 553177 [details] [diff] [review]
> refreshed mozconfigs

Some of the build options in this patch are redundant (or useless):

--enable-ipc isn't necessary (bug 639754).

--enable-libxul isn't necessary (bug 648911).

--disable-javaxpcom does nothing now (bug 648593).

Comment 32

[Chris AtLee [:catlee]]

Attachment: Using in-tree mozconfigs

Comment 33

[Chris AtLee [:catlee]]

Attachment: buildbot-config changes

we need to remove any include lines from the mozconfigs since the fallback code will only download a single file.

luckily we don't need to switch make flags based on vm/hardware since we've turned off all the vms.

I believe this patch and the buildbotcustom patch can land as they are. Once they're landed and deployed, we can land the mozconfigs patch into mozilla-central itself.

Comment 34

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

Comment on attachment 553177 [details] [diff] [review]
refreshed mozconfigs

Clearing review. I'm happy to take a look at a refreshed patch at the point we're ready to land.

Comment 35

[Armen [:armenzg]]

Merged to production and reconfigured.

Comment 36

[Chris AtLee [:catlee]]

generateReleaseBranchObjects needs to be updated

Comment 37

[Chris AtLee [:catlee]]

Attachment: final(?) mozconfigs for mozilla-central

Comment 38

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

Comment on attachment 559128 [details] [diff] [review]
final(?) mozconfigs for mozilla-central

>diff --git a/xulrunner/config/mozconfigs/linux32/xulrunner-qt b/xulrunner/config/mozconfigs/linux32/xulrunner-qt

The factory is expecting to find this at browser/config/mozconfigs/linux32/xulrunner-qt, because config.py has
 'src_xulrunner_mozconfig': 'browser/config/mozconfigs/linux32/xulrunner-qt'

Apart from that it looks fine for mozilla-central. But have you looked at what happens as these merge around to project and release branches ? 

eg from bug 677773, which is supposed to not migrate to Aurora/Beta/Release
+# Nightlies only since this has a cost in performance
+ac_add_options --enable-js-diagnostics

# from bug 667577
+export MOZ_TELEMETRY_REPORTING=1

Comment 39

[Chris AtLee [:catlee]]

Attachment: fix path for xulrunner on linuxqt

Comment 40

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

Attachment: Diff of mozconfigs

A longer list of issues that will crop up on branches:

* --enable-js-diagnostics needs to not make it from central to aurora (merge doc)
* 'export MOZ_TELEMETRY_REPORTING=1' is getting added to branches (eg e10s), should check with taras if that muddies the waters for him
* shadow-central builds will end up on channel=default, currently they're getting updated to m-c builds on nightly. Similarly anything without update_channel defined (excludes any PROJECT). feature or bug ? Similarly lots of project branches will use nightly-<branch> instead of nightly, but we're not expecting to serve them updates anyway, so that's just FYI 
* mozilla-aurora/beta: I'm assuming all the Android keychain differences are valid, but we'll have to do the branding changes at repo merge time
* in the shark config s/nightly// in this comment
 # Need this to prevent name conflicts with the normal nightly build packages
* mozilla-release - mac - we'll be adding --enable-accessibility for debug, which is consistent with bug 524775 but kinda strange. I wonder if we should revisit that and remove it on the merge to Aurora
* 'WINNT 5.2 Mobile Desktop electrolysis build' will get a --disable-webm, but it's probably just be out of sync
* branches using the generic configs (eg try, places, twigs) will lose support for mozconfig-extra[-<platform>]. Would be worth adding that to the blog post (and look for wiki docs) if that's deprecated
* accessibility folks will need to re-add --enable-accessibility for their mac configs

I haven't looked at try here, but we definitely should.

Comment 41

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

Comment on attachment 559128 [details] [diff] [review]
final(?) mozconfigs for mozilla-central

r+, but of course you'll need to merge the changes from jhford's non-PGO builds, and deal with the questions about telemetry and so on from the previous comment.

Comment 42

[Chris AtLee [:catlee]]

Attachment: Use in-tree mozconfigs for win64 too

Comment 43

[Chris AtLee [:catlee]]

Comment on attachment 559128 [details] [diff] [review]
final(?) mozconfigs for mozilla-central

https://hg.mozilla.org/mozilla-central/rev/51d989ece4c5

Comment 44

[Chris AtLee [:catlee]]

Still todo:

* Maemo 5 GTK,QT builds still not using in-tree mozconfigs
* Release builds

Comment 45

[Jim Mathies [:jimm]]

(In reply to Nick Thomas [:nthomas] from comment #40)
> * branches using the generic configs (eg try, places, twigs) will lose
> support for mozconfig-extra[-<platform>]. Would be worth adding that to the
> blog post (and look for wiki docs) if that's deprecated

This mentions the platform specific option, however on try server the generic mozconfig-extra no longer works. Are we planning to bring this option back at some point for try builds?

If not we should strip this from the try docs:
https://wiki.mozilla.org/Build:TryServer

Comment 46

[Rafael Ávila de Espíndola (:espindola) (not reading bugmail)]

> This mentions the platform specific option, however on try server the
> generic mozconfig-extra no longer works. Are we planning to bring this
> option back at some point for try builds?

You can just edit the mozconfig file in try push, no? It is just another file in the tree :-)
 
> If not we should strip this from the try docs:
> https://wiki.mozilla.org/Build:TryServer

Comment 47

[Justin Lebar (not reading bugmail)]

> You can just edit the mozconfig file in try push, no? It is just another file in the tree :-)

But if you want to apply your changes to all platforms, you need to edit all the mozconfigs.  The problem is that there's no "*generic* mozconfig-extra".

Comment 48

[Rafael Ávila de Espíndola (:espindola) (not reading bugmail)]

> But if you want to apply your changes to all platforms, you need to edit all
> the mozconfigs.  The problem is that there's no "*generic* mozconfig-extra".

I see. Maybe we could change the mozconfigs to start by including a mozconfig.common, even if mozconfig.common is normally empty? Doing it at the start (instead of at the end like the old mozconfig-extra) makes it easier to set CC and CXX.

Comment 49

[Chris AtLee [:catlee]]

Attachment: patch to release.py to use mozconfigs as specified by release config

Comment 50

[Chris AtLee [:catlee]]

Attachment: [untested] set mozconfigs in release config

Comment 51

[Rail Aliiev [:rail]]

I tested the patches in stagin and they worked well. I applied the changes to mozilla/staging_release* files.

Comment 52

[Chris AtLee [:catlee]]

Attachment: set mozconfigs in release config

Comment 53

[Chris AtLee [:catlee]]

Attachment: mozilla-beta mozconfigs for mobile

Comment 54

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

Comment on attachment 585732 [details] [diff] [review]
mozilla-beta mozconfigs for mobile

>diff --git a/mobile/config/mozconfigs/android/release b/mobile/config/mozconfigs/android/release
>+# Build Fennec
>+ac_add_options --enable-application=mobile/android

>+ac_add_options --with-branding=mobile/android/branding/beta

The mobile/android directory doesn't exist on m-b yet. The 10.0b3 android build used this for the mozconfig
  buildbot-configs/mozilla2/linux-android/mozilla-beta/release/mozconfig
which is missing the "/android".

As a cross check I also looked at the diff between m-b/mobile/config/mozconfigs/android/{nightly,release}. The nightly one also as just mobile in it. 

>diff --git a/mobile/config/mozconfigs/linux-desktop/release b/mobile/config/mozconfigs/linux-desktop/release
>+CC=/tools/gcc-4.3.3/installed/bin/gcc
>+CXX=/tools/gcc-4.3.3/installed/bin/g++

The nightly config is using gcc 4.5, so our buildbot-configs release config is out of sync ?

>diff --git a/mobile/config/mozconfigs/macosx-desktop/release b/mobile/config/mozconfigs/macosx-desktop/release
>diff --git a/mobile/config/mozconfigs/win32-desktop/release b/mobile/config/mozconfigs/win32-desktop/release

There are some differences here too. Bet Aki knows what is going on.

Comment 55

[Chris AtLee [:catlee]]

Attachment: mozilla-beta mozconfigs for mobile

Comment 56

[Aki Sasaki (not active)]

Comment on attachment 588860 [details] [diff] [review]
mozilla-beta mozconfigs for mobile

These look the same as the ones in mozilla2/, so r=me.
However, once we merge Aurora into Beta, we'll need a different set of mozconfigs... for android and android-xul, at least.

Comment 57

[Chris AtLee [:catlee]]

(In reply to Aki Sasaki [:aki] from comment #56)
> Comment on attachment 588860 [details] [diff] [review]
> mozilla-beta mozconfigs for mobile
> 
> These look the same as the ones in mozilla2/, so r=me.
> However, once we merge Aurora into Beta, we'll need a different set of
> mozconfigs... for android and android-xul, at least.

I'd like to land corresponding changes on aurora and trunk before the merge day. We will need to update buildbot-configs to point to the new mozconfigs at that point, however.

Comment 58

[Chris AtLee [:catlee]]

Comment on attachment 588860 [details] [diff] [review]
mozilla-beta mozconfigs for mobile

[Approval Request Comment]
Regression caused by (bug #): 
User impact if declined: 
Testing completed (on m-c, etc.): 
Risk to taking this patch (and alternatives if risky):

Comment 59

[Alex Keybl [:akeybl]]

Comment on attachment 588860 [details] [diff] [review]
mozilla-beta mozconfigs for mobile

[Triage Comment]
Approving these build changes.

Comment 60

[Chris AtLee [:catlee]]

Attachment: mobile mozconfigs for aurora

Comment 61

[Aki Sasaki (not active)]

Comment on attachment 592115 [details] [diff] [review]
mobile mozconfigs for aurora

The release mozconfigs seem to have a bit different from the beta release mozconfigs in mozilla2/; is this intentional?

I'd guess that you want these to be the same or similar so we can merge into mozilla-beta seamlessly.

The l10n-mozconfigs look the same as the aurora *nightly* l10n-mozconfigs.  How will we deal with release l10n-mozconfigs?

Removing the mobile desktop mozconfigs is cool, as long as we turn off the builds/repacks as well.

deathduck:~/src/mozconfigs/mozilla-aurora [11:02:55] (default)
559$ diff mobile/xul/config/mozconfigs/android/release ../buildbot-configs/mozilla2/android-xul/mozilla-beta/release/mozconfig 
2c2,3
< mk_add_options MOZ_MAKE_FLAGS=-j4
---
> ac_add_options --disable-debug
> ac_add_options --enable-optimize
5,6c6
< ac_add_options --enable-application=mobile
< ac_add_options --disable-elf-hack
---
> ac_add_options --enable-application=mobile/xul
17c17,19
< ac_add_options --enable-update-channel=${MOZ_UPDATE_CHANNEL}
---
> ac_add_options --enable-updater
> ac_add_options --enable-update-channel=beta
> ac_add_options --enable-debug-symbols="-gdwarf-2"
21a24
> ac_add_options --enable-official-branding
deathduck:~/src/mozconfigs/mozilla-aurora [11:05:18] (default)
560$ diff mobile/android/config/mozconfigs/android/release ../buildbot-configs/mozilla2/android/mozilla-beta/release/mozconfig 
2c2,3
< mk_add_options MOZ_MAKE_FLAGS=-j4
---
> ac_add_options --disable-debug
> ac_add_options --enable-optimize
16c17,19
< ac_add_options --enable-update-channel=${MOZ_UPDATE_CHANNEL}
---
> ac_add_options --enable-updater
> ac_add_options --enable-update-channel=beta
> ac_add_options --enable-debug-symbols="-gdwarf-2"
20a24
> ac_add_options --enable-official-branding

Comment 62

[Chris AtLee [:catlee]]

Attachment: mobile mozconfigs for aurora

Comment 63

[Aki Sasaki (not active)]

Comment on attachment 592228 [details] [diff] [review]
mobile mozconfigs for aurora

I'm a little worried about the android --disable-elf-hack ... is that needed?

Comment 64

[Serge Gautherie (:sgautherie)]

(In reply to Rafael Ávila de Espíndola (:espindola) from comment #48)
> Maybe we could change the mozconfigs to start by including a
> mozconfig.common, even if mozconfig.common is normally empty? Doing it at
> the start (instead of at the end like the old mozconfig-extra) makes it
> easier to set CC and CXX.

What about this painful regression?
For example, there is
/browser/config/mozconfig
but it is not included by
/browser/config/mozconfigs/*/*

Comment 65

[[e-mail] (:bhearsum)]

(In reply to Serge Gautherie (:sgautherie) from comment #64)
> (In reply to Rafael Ávila de Espíndola (:espindola) from comment #48)
> > Maybe we could change the mozconfigs to start by including a
> > mozconfig.common, even if mozconfig.common is normally empty? Doing it at
> > the start (instead of at the end like the old mozconfig-extra) makes it
> > easier to set CC and CXX.
> 
> What about this painful regression?
> For example, there is
> /browser/config/mozconfig
> but it is not included by
> /browser/config/mozconfigs/*/*

How is that a regression? Build machines have never used browser/config/mozconfig, and browser/config/mozconfigs is not used by anything but build machines as far as I know.

Comment 66

[Serge Gautherie (:sgautherie)]

(In reply to Ben Hearsum [:bhearsum] from comment #65)
> How is that a regression? Build machines have never used
> browser/config/mozconfig, and browser/config/mozconfigs is not used by
> anything but build machines as far as I know.

The regression is what was previously commented on: see 'mozconfig-extra'.
The /browser example was a hint at a possible solution: see "mozconfig.common".

Comment 67

[Robert Kaiser]

1) There was no regression, the files were just moved from out of the tree into the tree, without any change to them (AFAIK).

2) /browser/config/mozconfig has been deprecated for ages and it was even removed either for real or announced to be, and only kept in because it broke people and it's cheap to keep in there, but it's discouraged to being used. The target is to need as few options as possible to build the default configuration and therefore not need such a file.

Comment 68

[Serge Gautherie (:sgautherie)]

(In reply to Robert Kaiser (:[e-mail]) from comment #67)

> 1) There was no regression, the files were just moved from out of the tree
> into the tree, without any change to them (AFAIK).

I'm not complaining about the files (content).
The regression is the lost Try feature!

> 2) /browser/config/mozconfig has been deprecated for ages and it was even
> removed either for real or announced to be

Afaict, that file hasn't been removed, nor does it warn it's deprecated.

Comment 69

[Randell Jesup [:jesup] (needinfo me)]

I got caught out on this because of bug 737044 - this wasn't documented on the project branch page, so I was pounding my head trying to figure out why my attempts to add "touch configure.in" to mozconfig-extra was failing (due to a bug in the gyp->Makefile converter it doesn't remake the makefiles when a gyp file changes, and until that's fixed I need to force configure to run on alder).

Please make sure the documentation is correct, and if /mozconfig is deprecated, please make that obvious to people.

It's annoying (and IMHO error-prone) to be editing all the separate, in-tree mozconfigs since there's no common place to do it anymore (especially for try runs).  But that's just my opinion...

Comment 70

[Chris AtLee [:catlee]]

I think we're all done with this bug.

jesup: there's no reason why the in-tree mozconfigs couldn't be modified to look for a common include file. if that's something that interests you, please file a bug (w/ a patch is even better!)

Comment 71

[Serge Gautherie (:sgautherie)]

(In reply to Serge Gautherie (:sgautherie) from comment #64)
> (In reply to Rafael Ávila de Espíndola (:espindola) from comment #48)
> > Maybe we could change the mozconfigs to start by including a
> > mozconfig.common, even if mozconfig.common is normally empty? Doing it at
> > the start (instead of at the end like the old mozconfig-extra) makes it
> > easier to set CC and CXX.
> 
> What about this painful regression?

I filed bug 738612.