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.
