These version checks were only used with --enable-stdcxx-compat,
which as far as I can tell no UXP application has ever relied on.
The only use case seems to have been building with clang against an
old version of GCC's libc that predates C++11, let alone C++17.
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>
Switch to using "create" instead of "makehybrid" when creating the disk image.
This fixes bogus extended attributes which interfere with the code signature.
Finally add any -bin or dylibs in the Resources folder since --deep skips that folder.
Added --with-macbundle-idenity configure option to set a codesign identity.
If no identity is set or cross-compiling from Linux no codesigning will be
done. Currently doing a full deep bundle v2 sign, instead of limited v1.
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.
I use this for quickly rebuilding and preprocessing the JS/XUL/CSS assets them without the need to recompile the IDL interfaces and other unnecessary items.
This change modifies the mozdebug module to include a special case for Visual Studio when looking for its path.
This also removes the workaround implemented in dcb027a718 which can break debugging in certain installations of Visual Studio 2015.
Newer MSVC was failing to find the devenv executable for ./mach run --debug
This isn't the prettiest solution, but at least it's better than just relying
on a hardcoded path.
The Python script here claims it can handle any Bourne-compatible shell, but the detection logic here really only works with GNU Bash. Not that there are that many Bourne-compatible shell implementations to compare against...
To make a long story short, there's an old flag called NSDISTMODE that
was never added to old-configure so it could be passed down through the
build system to all the places it needs to go nowadays if used in your
.mozconfig, but which still sort of works when set as an environment
variable. If you leave it unset, it uses relative symlinks. However, it
has two other modes. One of them is "copy" and the other is
"absolute_symlink." Copy simply copies the files into the directory, and
absolute_symlink attempts to use absolute symlinks instead of relative
ones.
I've been wondering for a while now if there was a way to make the
shared library files in `dist/bin` that we use `./mach run` against
*not* be relative symlinks, and this seems to be that elusive technique.
It seems to be a part of the institutional memory that was all but lost
shortly after Netscape went under. You mostly see a few references to it
in NSS, NSPR, and the Makefiles in the `config` directory. And also
there is one reference in a Makefile in the application directory, which
seems to explains why application executables themselves usually aren't
symlinks:
/platform/libs/nspr/src/pr/src/md/unix/Makefile.in#76
/platform/libs/nss/src/coreconf/UNIX.mk#34
/palemoon/app/Makefile.in#30
/platform/config/config.mk#396
My patch essentially revives NSDISTMODE and makes it work as intended
again, more or less. Some parts of the work are loosely inspired by this
bug that was never finished upstream, showing that Mozilla only
rediscovered it earlier this year while trying to disable symlinks in
dist/bin for WSL, as far as I can tell.
https://bugzilla.mozilla.org/show_bug.cgi?id=1699855
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
Basilisk-Dev
nia
Sergey Fedorov
FranklinDM
Moonchild
Matheus Marinho
Jeremy Andrews
Brian Smith
Martok
Matt A. Tobin
Olivier Certner
wolfbeast