1692516 - GNUmakefile for Downstreams -- GNU make front-end for building SeaMonkey and locales on Linux/UNIX distros

Status: ASSIGNED

(SeaMonkey :: Build Config, enhancement)

Description

[Dmitry Butskoy (:buc)]

In short:

Since the version 2.53.6, the longterm widespread "make -f client.mk" no longer suitable.

You can either switch to the official method -- the ./mach command, or use the new top-level makefile, proposing here.

Additionally, this new makefile provides an easy "out-of-the-box" way for building all the locales at once and installing them properly.

Comment 1

[Dmitry Butskoy (:buc)]

As you already know, the version 2.53.6 have changed the layout of the source. Now the old top directory has become "comm" subdir, and the former "mozilla" subdir has become the top. The same time the old Suite's client.mk is gone, and now the former mozilla/client.mk appeared at the top.

It is another "client.mk", mostly intended for the internal use when building Firefox. You can still run with it once, but any calls now lead to rebuild the entire system from the beginning. Thus, "make -f client.mk install" appears impossible, as well as incremental run when debugging.

There is a small patch that temporarily fixes the issue, but a much better solution would be to switch to a full-fledged makefile that provides the standard build targets accepted by most distributions.

In the context of Linux/UNIX usage, the official Mozilla's ./mach command can be interpreted just as a front-end on top of GNU make system, and GNU make actually does all the underlying work. The proposed makefile, as an alternate front-end, just do all "directly", and use ./mach internally when it is needed only (configure stage).

The new makefile is named "GNUmakefile", and should be placed in the top directory (instead of an already present stub with the same name). The name GNUmakefile is chosen since it is provided by GNU make as a special one with the highest priority over traditional [Mm]akefile, and it doesn't interfere with anything else in the existing code.

Comment 2

[Dmitry Butskoy (:buc)]

The usage is as always. (For more details just read the file).

For build use

make

If you want to separate config stage, use "make configure" and then "make", but normally it is done automatically.

After the build, you can optionally:

make locales

to provide all the shipped locales (will appear in a form of langpack extensions).
If irc and/or calendar was built, they will be prepared properly too.
(See below for more details about locales target).

For install, use

make install DESTDIR=where_you_want_to_install

For clarity, some comparison with the other build methods (assume "-jN" is the option for parallel builds, ie. "-j4" for 4-cpu system):

Build stage:

client.mk:       make -f client.mk build MOZ_MAKE_FLAGS=-jN
mach:            ./mach build -jN
GNUmakefile:     make -jN

Install stage:

client.mk:       DESTDIR=where... make -f client.mk install
mach:            DESTDIR=where... make -C $OBJDIR... install
GNUmakefile:     make install DESTDIR=where...

Thus it is possible now to use proper macros in distro build scripts (if any).

Comment 3

[Dmitry Butskoy (:buc)]

The usage of make locales:

By default all available locales will be used. You can change it by overriding SHIPPED_LOCALES variable on the command line.

The target "locales" performs all the needed work. It depends on "locales-all" and "repacks". First builds all needed langpacks, second checks whether irc and/or calendar extensions are built and prepares them by required additional locales.

Some internal targets might be useful too, fe. "make locale-LANG" to create one (or several) langpack separately.

For example, to build all with fr and it only, use:

  make locales SHIPPED_LOCALES="fr it"

to create just ru langpack:

  make locale-ru

Use "clear-locales" and "clear-repacks" for clearing.
 

   NOTE! NOTE! NOTE!

Do NOT use parallel builds (-jN) for locale targets!

(Whereas the code is ready for it, the underlying Mozilla's "make langpack-..." uses the same working filenames for different languages, which makes impossible the parallel run).

Make sure you specify "--with-l10n-base=...l10n_source..." in your .mozconfig .

The "all-in-one" package should set the boolean preference "intl.locale.matchOS" on, to properly choose locale at runtime (according to "LC_ALL, LANG, LC_MESSAGES" environment). You can put it in a file like "defaults/pref/all-locales.js" under the install tree (note "all-" prefix), or add it to one already provided by you.

Comment 4

[Dmitry Butskoy (:buc)]

Attachment: seamonkey-2.53.6-GNUmakefile

The patch, for version 2.53.6 and up.

Place it as GNUmakefile in the top src dir (instead of the existing stub).

Hint: "make", optionally "make locales", then "make install DESTDIR=/var/tmp/where/needed" . The first make allows parallel build (-j option).

Any feedback appreciated, either here or any other way.

Comment 5

[Landry Breuil (:gaston)]

Fwiw i didnt have much to change in my packaging glue for seamonkey on OpenBSD with the update to 2.53.6, i just replaced --enable-application=suite by --enable-application=comm/suite (cf https://cgit.rhaalovely.net/seamonkey/commit/?id=4bbe0a9607e2c40a5e775b408af7457cfdabba15).

other than that, we still use the ../xxx/configure (which generates a working Makefile in objdir) && make && make install (with DESTDIR set) steps from a given objdir, and that works fine.

Comment 6

[Dmitry Butskoy (:buc)]

The file attached certainly works with 2.53.7 (and so on) too.

Since the transition from "distribution/extensions" to just "extensions" are finished in 2.53.7, a little bit cleaner version is here. But the changes are negligible.

Comment 7

[Tristan Miller]

I've been a SeaMonkey packager for openSUSE since 2020, and inherited a fairly complex packaging infrastructure (various shell scripts plus an RPM spec) file that had been gradually built up since 1999, when SeaMonkey was the Mozilla Application Suite. As detailed in Bug 1682424 Comment 23, this infrastructure stopped working for me with the release of SeaMonkey 2.53.6b1, but addressing this problem was stymied by the lack of correct and complete documentation for checking out and building the sources (see Bug 1684460) and (later, once I pieced together the necessary information) the time required for me to learn the new method and to convert my existing packaging infrastructure. OpenSUSE therefore remained stuck on SeaMonkey 2.53.5.1 until today, when I was able to integrate Dmitry's GNU Makefile over the course of a few hours (most of which was just waiting to see if the builds would complete successfully). Thanks also to the documentation he sent by e-mail, the process was fairly straightforward. This seems to have saved me a lot of time in getting things up and running again. Integrating this GNU Makefile into SeaMonkey might help other packagers in similar situations.

Comment 8

[Dmitry Butskoy (:buc)]

Attachment: seamonkey-2.53.7-GNUmakefile-new

New way to build langpacks, following the upcoming upstream changes.

Now chatzilla and calendar localization data are included into the main common langpack. This allows to properly separate languages into a subpackages and/or handle them by the distro's package management.

Some optimization performed (as before), including avoid of an extra manifest recursion and placing the key files uncompressed in the beginning of the archive.

This file is intended both for 2.53.7 and later versions.

Note, that first attachment 9202905 [details] should stop work since 2.53.8 (unless you build locales at all or build chatzilla and calendar).

Comment 9

[Dmitry Butskoy (:buc)]

Attachment: seamonkey-2.53.15-GNUmakefile

New version, with removing some obsoleted stuff and fixed handling of Latam Spanish.

Works with any SM version since 2.53.7 .

Comment 10

[Frank-Rainer Grahl (:frg)]

Just a heads up that 2.53.16 will switch to webext language packs. I am not sure if we will be able to turn off the python 2 lights then too but on the way.

Comment 11

[Dmitry Butskoy (:buc)]

Attachment: seamonkey-2.53.16-GNUmakefile

Reflects changes in the new way of packing langpacks in SeaMonkey >= 2.53.16 (switched to webextensions).

Comment 12

[Dmitry Butskoy (:buc)]

Attachment: seamonkey-2.53.19-GNUmakefile

Since 2.53.19, distros must explicitly set everywhere global environment variable MACH_USE_SYSTEM_PYTHON=1 . The new version of GNUmakefile does this automatically.

Compatible with previous versions starting from 2.53.16.

Comment 13

[Dmitry Butskoy (:buc)]

Attachment: seamonkey-2.53.20-GNUmakefile

Since 2.53.20, yet another mandatory environment variable MOZBUILD_STATE_PATH must be set (pointing to an empty and unused directory, otherwise it will be created as ~/.mozbuild), plus a fix for post-configure stamping (objdir's CLOBBER file creation for the separate configure stage as before).

Compatible with previous versions starting from 2.53.16.