Generating OS-appropriate mapfiles from a provided SYMBOL_FILE is
apparently required to work with newer ffvpx. Nothing else in our
codebase actually seemed to require it. Also seems to reduce the amount
of console spam I see relating to symbol visibility during the build
process, and I think it even makes libxul.so link a bit faster.
Signed-off-by: athenian200 <athenian200@outlook.com>
I'm not sure about what they had in mind when they first wrote this, but this is completely unnecessary. The base name is the file name. This part will break building with `mach faster` once partial filenames with wildcards are included in the package manifest, which became the case when we began supporting the newer MSVC runtime.
This also aligns FasterMake with how RecursiveMake treats wildcard copy directives.
They fixed this in bug 1416465, but it included a conditional that will almost always be true and kept this incorrect joining of the path and base name in the destination path. Since the value for the base name is either empty or contains a partial file name, that conditional effectively does nothing.
Make essential Tauthon's builtins and modules available in sandboxes, without
disrupting building with Python 2.7.
1. Allow new builtins and modules. "__build_class__" is for
building... new-style classes (to handle the new metaclass syntax imported from
3.x). "_oserror" is necessary because of internal changes to raise errors
deriving from OSError (which are reported as IOError if not caught).
2. Look for modules and packages in the right places.
This was tested on FreeBSD, and should work out of the box on Linux.
* So far this seems to only affect Macintosh builds but other unix builds may be affected. Windows doesn't seem to be.
* This maintains consistency with other one-off file invocations and backwards compatibility with older comm setups
* The langpack is not generated via the package target but IS for mozpackage target using old behavior
* Add mach command to specifically generate the langpack when needed without the rest of the packaging routine (mach langpack)
* This adds what will eventually be a rewritten packaging routine while maintaining backwards compatibility with the original mozilla routine
* Changes the build target and installer makefile to use the alternative packaging
* Adds build target to specifically invoke the original mozilla routine
* Update mach commands accordingly
https://www.tachytelic.net/2019/01/grep-recursively/
During testing, I tried simply replacing grep with ggrep, which was non-portable but worked fine. Using an environment variable with os.getenv set to 'g' also worked, but the problem with that approach is that you have to set it manually and some times the script will mess up if you don't explictly define it to an empty string for platforms that don't need it.
Setting TOOLCHAIN_PREFIX to 'g' seemed to solve all of my problems except this one, and it appears to be the only non-portable use of GNU grep in the whole tree. To understand what I tried to do here, let me present with you with two commands that yield the same output on my machine:
find . -name '*.xul' | xargs grep -E "#include"
ggrep -E -r "#include" --include="*.xul" .
I just tried to make the Python script follow the logic of those two commands, though I'm not sure how well I succeeded since I got no errors. I visualized everything this way:
ggrep -E -r "<strings>" --include="<filesuffixes>" <path>
find <path> -name '<filesuffixes>' | xargs grep -E "<strings>"
And arranged it all accordingly to the best of my ability, though I should point out that Python is not my strong suit.
This is mostly ifdefs, but as you can see, Solaris is actually a lot like Linux. They're both more SysV than BSD at core, and most of the differences have more to do with Solaris not using glibc than anything else.
I still need to audit a lot of these changes and understand why they're needed and what the alternative approaches are. After this patch, most of the core functionality needed to build Solaris is here.
https://bugzilla.mozilla.org/show_bug.cgi?id=1360571
Solaris uses ksh as the default shell, and furthermore bash doesn't seem to support the 'local' keyword feature when invoked as sh on OpenIndiana. We could just change the script to use bash (it is an option even on Solaris), but this fix is available and Mozilla has been using it since Firefox 55 with no issues on any other platforms. It was specfically done this way to avoid any need to change existing mozconfig files, so I feel confident saying the change is totally benign and if anything the way it is now is technically a POSIX compliance issue inherited from Mozilla that we'll hit if we ever try to compile this on any Unix platform where bash isn't sh.
The mozconfig output parsing code already (mostly) handles shell quoted strings, because that's what `set` outputs. By quoting environment variable values, we avoid a bunch of problems with "weird" values.
- `--enable-official-branding` implies `MC_OFFICIAL` (no need to specifically set it)
- `--enable-official-vendor` can be used to set `MC_OFFICIAL` on builds without `--enable-official-branding` that should still be considered official release versions.
- `MC_OFFICIAL` implies `--enable-release`, meaning `DEVELOPER_OPTIONS` isn't set
- `MC_OFFICIAL` makes `nsXULAppInfo.getIsOfficial` return `true`
- `MC_OFFICIAL` makes `AppConstants.MOZILLA_OFFICIAL` (for compatibility in extensions) and `AppConstants.MC_OFFICIAL` return `true`
- Optional, for the time being: `MOZILLA_OFFICIAL` is still present in some places in case someone wants to build a Mozilla-alike official application and has the rights and necessary keys to use Mozilla-official third-party services. This must always be combined with `MC_OFFICIAL` to have a sane combination of defines. This may be removed in the future.
Sergey Fedorov
FranklinDM
athenian200
Matheus Marinho
Brian Smith
Moonchild
Olivier Certner
Matt A. Tobin
wolfbeast
JustOff
wolfbeast
trav90
NTD