use a mozconfig and objdir for l10n repack builds

RESOLVED FIXED

Status

Release Engineering
General
P4
normal
RESOLVED FIXED
9 years ago
4 years ago

People

(Reporter: Pike, Assigned: bhearsum)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [l10n])

(Reporter)

Description

9 years ago
We should move over to use a mozconfig for l10n repacks, too. That would take away all the autoconf steps in favour of a make -f client.mk configure.

We'd need to jump in with steps to download and move the mozconfig itself, though.

Might make the builds easier to reproduce locally, too.

Interesting question is whether we should add the --with-l10n-base option to mozconfig. I'd kinda rather not.
(Reporter)

Updated

9 years ago
Whiteboard: [l10n]
(Assignee)

Comment 1

9 years ago
Coop says this one is futureable.
Component: Release Engineering → Release Engineering: Future

Updated

8 years ago
Blocks: 484957
I attempted using a mozconfig for Maemo repacks.
I run a |make distclean|, then the |make -f client.mk configure| gives me this:

...
configure: warning: Recreating autoconf.mk with updated nspr-config output
configuring in js/src
running /bin/sh /builds/scratchbox/users/cltbld/home/cltbld/build/maemo-trunk-l10n/mozilla-central/js/src/configure  --disable-javaxpcom --with-arm-kuser --enable-application=xulrunner --enable-tests --prefix=/usr/local --libdir=/usr/local --enable-threadsafe --with-nspr-cflags='-I/builds/scratchbox/users/cltbld/home/cltbld/build/maemo-trunk-l10n/mozilla-central/objdir/xulrunner/dist/include/nspr' --with-nspr-libs='-L/builds/scratchbox/users/cltbld/home/cltbld/build/maemo-trunk-l10n/mozilla-central/objdir/xulrunner/dist/lib -lplds4 -lplc4 -lnspr4 -lpthread -ldl' --with-dist-dir=../../dist --includedir=/builds/scratchbox/users/cltbld/home/cltbld/build/maemo-trunk-l10n/mozilla-central/objdir/xulrunner/dist/include --bindir=/builds/scratchbox/users/cltbld/home/cltbld/build/maemo-trunk-l10n/mozilla-central/objdir/xulrunner/dist/bin --libdir=/builds/scratchbox/users/cltbld/home/cltbld/build/maemo-trunk-l10n/mozilla-central/objdir/xulrunner/dist/lib --with-sync-build-files=/builds/scratchbox/users/cltbld/home/cltbld/build/maemo-trunk-l10n/mozilla-central --enable-jemalloc --cache-file=../.././config.cache --srcdir=/builds/scratchbox/users/cltbld/home/cltbld/build/maemo-trunk-l10n/mozilla-central/js/src
loading cache ../.././config.cache
checking host system type... i686-pc-linux-gnu
checking target system type... i686-pc-linux-gnu
checking build system type... i686-pc-linux-gnu
checking for gawk... (cached) gawk
***
*   Your source tree contains these files:
*         /builds/scratchbox/users/cltbld/home/cltbld/build/maemo-trunk-l10n/mozilla-central/js/src/Makefile
*         /builds/scratchbox/users/cltbld/home/cltbld/build/maemo-trunk-l10n/mozilla-central/js/src/config/autoconf.mk
*   This indicates that you previously built in the source tree.
*   A source tree build can confuse the separate objdir build.
*
*   To clean up the source tree:
*     1. cd /builds/scratchbox/users/cltbld/home/cltbld/build/maemo-trunk-l10n/mozilla-central/js/src
*     2. gmake distclean
***
configure: error: /builds/scratchbox/users/cltbld/home/cltbld/build/maemo-trunk-l10n/mozilla-central/js/src/configure failed for js/src
*** Fix above errors and then restart with               "make -f client.mk build"
make[1]: *** [configure] Error 1
make[1]: Leaving directory `/builds/scratchbox/users/cltbld/home/cltbld/build/maemo-trunk-l10n/mozilla-central'
make: *** [configure] Error 2

The first pass at configuring is fine with the first distclean; the second dies because of the files that the first pass creates.

This tells me we need to use an objdir if we use a mozconfig.
I'm abandoning this since that seems like a much larger task.
Summary: use a mozconfig for l10n repack builds → use a mozconfig and objdir for l10n repack builds
Ok, amendment to comment 2:

If I copy the .mozconfig into the tree, then keep the other config steps (not make -f client.mk config, but autoconf/autoconf_js_src/configure/make config) then the configure step picks up the options from the mozconfig.

Updated

8 years ago
Depends on: 533665

Updated

8 years ago
Blocks: 537287

Updated

8 years ago
Duplicate of this bug: 518359

Updated

8 years ago
Status: NEW → ASSIGNED
Component: Release Engineering: Future → Release Engineering
Priority: -- → P2

Updated

8 years ago
Assignee: nobody → armenzg

Updated

8 years ago
Priority: P2 → P3

Comment 5

8 years ago
I will try to pick this up in a couple of weeks.
Assignee: armenzg → nobody
Status: ASSIGNED → NEW
Priority: P3 → P4
Assignee: nobody → aki
Duplicate of this bug: 484957
I was able to get this running while working on bug 525327.

1) copy in mozconfig
2) make -f client.mk configure in mozilla-central/
3) make in mozilla-central/objdir/config
4) make wget-en-US in mozilla-central/objdir/mobile/locales/ (or browser/locales/ probably)
5) get the installer/deb (true for maemo; not sure for desktop)
6) make unpack in mozilla-central/objdir/mobile/locales/
7) make in mozilla-central/objdir/mobile/branding/nightly/ <-- this should probably be fixed. otherwise i need to use mozilla-central/mobile/branding/official/ for releases
8) update repository revisions after make ident
9) run compare-locales as normal, BUT:

all l10n.ini's are hardcoded to not be under an objdir.  We should probably create l10n.ini.in's which replace depth/source-depth on configure.

If we don't change that, then compare-locales needs to be run in the sourcedir.  And we also have to worry about changing the mergedir relative paths for when we're in objdir and not in objdir, or use absolute paths for mergedir.
Not sure if step 7 is needed in a non-multilocale repack.
(Reporter)

Comment 9

7 years ago
mergedir should be an absolute path, really. And the l10n.ini's are source-based. It's really irrelevant where you run it, it just needs to point to the right l10n.ini path, and to the right l10n-merge dir.
(Reporter)

Comment 10

7 years ago
Bug 578563 makes obj dir the default now, though that shouldn't break us right now as we're calling configure explicitly.
(Assignee)

Updated

7 years ago
Assignee: aki → bhearsum
(Assignee)

Comment 11

7 years ago
(It's likely that I'll be doing this as part of 608004).
(Assignee)

Updated

7 years ago
Depends on: 608004
(Assignee)

Comment 12

7 years ago
Now fixed as a result of 608004
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.