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.
Matt A. Tobin
athenian200
JustOff
wolfbeast
trav90
janekptacijarabaci
NTD
trav90
roytam1