Back when I filed this bug, $appname-$version was already useless, but
there actually were multiple supported versions (e.g. 3.5/3.6). So it
made sense to have e.g. firefox-3.5 and firefox-3.6, but not
firefox-3.5.12 and firefox-3.5.13.
Fast forward 10 years, and we change "major" versions every 6 to 8
weeks, have multiple chemspills every other week, and installing to
firefox-57.0, firefox-57.0.1, firefox-57.0.2, firefox-57.0.3 doesn't
make any kind of sense. Even firefox-56, firefox-57 is pretty much
useless.
There /kind/ of was some usefulness to the version in the SDK
directories, but those are gone.
I'm pretty sure no downstream is actually using versioned directories
anyways.
At this point, it seems better to just use the application name, without
the version. A case could be made about ESR, but that would be better
handled with a separate application name (e.g. firefox-esr).
--HG--
extra : rebase_source : 333e10ea1316714bf0008ec772b35093edfc45ff
Some of the variants are multi-platforms, and having
--enable-stdcxx-compat in their definition will break when the option is
moved over to python configure.
While here, prepare for --enable-stdcxx-compat actually doing something
(it currently doesn't), by adding an exception for it in
check_vanilla_allocations.py.
--HG--
extra : rebase_source : ee1647421542209cf0137db703c4f7e7f06cbc91
This has the virtue of not executing python three times during configure
just to read the same value of milestone.txt and munge it. We can also
remove milestone.py as a happy side effect, so all the milestone
computations can be done in init.configure.
We only had this "for flexibility with other platforms", but given that
we set it to the same thing for all platforms, and nobody has tried to
change that, this flexibility isn't actually needed.
Bug 1256642 introduced magic at the emitter level to determine whether a
binary contains C++ sources and should be linked with the C compiler or
the C++ compiler.
Unfortunately, the Binary() moz.build template always adds C++ OS
libraries on Android (through STLPORT_LIBS), and C++ libraries on Linux
(stdc++compat).
The latter only ends up forcing every Binary() to be linked with the C++
linker, which is unfortunate, but doesn't cause much problems. The
former, however, involving OS libraries, the magic from bug 1256642
doesn't kick in, so we end up trying to link C++ OS libraries with the C
linker. Which ends up failing, because the libraries in STLPORT_LIBS
require -lm, which, while it's added by the C++ compiler when linking,
is not when the linkage is driven by the C compiler.
Because the fallible library, linked to all GeckoBinary()s is a C++
library, we still ended up linking with the C++ compiler on Android, so
this wasn't actually causing any problem... until I tried to remove that
fallible library in bug 1423803.
Anyways, the core problem is that moz.build evaluation is happening too
early to know whether any C++ sources are being linked together, so
there is no way the Binary() template can do the right thing. So this
change moves the logic to the emitter.
This also changes the type of STLPORT_LIBS to a list.
--HG--
extra : rebase_source : a70ddf7a132f94dc10e7e1db94ae80fb8d7a269f
Back when mozalloc was a separate library, the xpcom glue code could not
use the infallible allocator API. But since bug 868814, that's not the
case anymore, so we can safely include mozalloc.h when XPCOM_GLUE is
set.
--HG--
extra : rebase_source : a8fbf8dc7020765d7287e2eb7ceaf41c99be8b18
This accounts for LOCAL_INCLUDES in the moz.build files, as well as the
default INCLUDES specified in config.mk that are used for host
compilation. Since some of the HOST_CFLAGS were also used for linking,
those flags are split off into HOST_C{XX}_LDFLAGS so that
the linker-only flags can be placed in those variables.
MozReview-Commit-ID: J1LxIZVeFJ
--HG--
extra : rebase_source : ed7293604e5428e3124f1ecfb2b706e087436b72
These flags were added way back in bug 59454 to both the compiling and
linking rules for HOST_SIMPLE_PROGRAMS. However, the INCLUDES aren't
actually needed when linking so we can safely remove them.
MozReview-Commit-ID: 8QywO7tGPpU
--HG--
extra : rebase_source : 34870adcf73b459771413e52bc84c6c63669d0f9
Both SFLAGS and ASFLAGS are used to compile assembly, but SFLAGS include
DEFINES and LOCAL_INCLUDES whereas ASFLAGS do not. It seems easiest to
just separate them into two different ComputedFlags values so that the
backend can distinguish between the two types.
MozReview-Commit-ID: Bkm3621ImJG
--HG--
extra : rebase_source : 420204e37d591512f700d77b780939d20c2feeb0
These have been replaced by stl-headers.mozbuild and
system-headers.mozbuild
MozReview-Commit-ID: EpPasSzgiJk
--HG--
extra : source : 86302df0b38a05ce8f6f830e324631a42c1c643e
The make-system-wrappers.py invocation is largely identical to
make-stl-wrappers.py, though this script generates wrappers for both the
STL headers and every other system header that can be used.
Note that the nsprpub script didn't create multiple layers of
subdirectories properly, so for example the 'ia64/sys/inline.h' wrapper
is now generated properly. Additionally, MOZ_SYSTEM_ICU define was
incorrectly using '#ifdef' instead of '#if ... == 1', which causes those
unicode headers to have wrappers when they shouldn't. These will show up
as differences when comparing the Makefile output to the moz.build
output.
MozReview-Commit-ID: KvQAawfzXao
--HG--
extra : source : 5a967cc85e28e63c283a81e2c76444a76dfbd266
This is fairly straightforward to represent as a GENERATED_FILES, though
we have to take some care to construct the outputs tuple correctly. This
script needs to run during export, and unfortunately none of the STL
headers have proper file extensions, so the 'new' header is
special-cased in the recursive make backend to serve as a marker for
running it in the correct tier.
We can't remove the stl-headers file yet because it is still used for
the system header generation.
MozReview-Commit-ID: 3tQTOY0LAsQ
--HG--
extra : source : 828d43ec1b16edaac69c42f15561f26e209051f1
These don't actually install correctly, because 'private' is already a
system wrapper. Neither of these files are included anywhere, so there's
no harm in removing them.
MozReview-Commit-ID: 1IAFMZDvKDV
--HG--
extra : source : 8d770908a5b9a3421294c93f8a34a14265674e9b
This is no longer used in the tree, and the $ will get eaten somewhere
along the way on the path from moz.build to the python invocation by
make despite being shell_quoted.
MozReview-Commit-ID: 5mwWQYDn8Nf
--HG--
extra : source : ffe9aed0944f57e329ee279f5b14266d5c4069a2
These have been replaced by stl-headers.mozbuild and
system-headers.mozbuild
MozReview-Commit-ID: EpPasSzgiJk
--HG--
extra : rebase_source : 33bc7a5a8de794f882bd1438ac800da2150a2ce6
The make-system-wrappers.py invocation is largely identical to
make-stl-wrappers.py, though this script generates wrappers for both the
STL headers and every other system header that can be used.
Note that the nsprpub script didn't create multiple layers of
subdirectories properly, so for example the 'ia64/sys/inline.h' wrapper
is now generated properly. Additionally, MOZ_SYSTEM_ICU define was
incorrectly using '#ifdef' instead of '#if ... == 1', which causes those
unicode headers to have wrappers when they shouldn't. These will show up
as differences when comparing the Makefile output to the moz.build
output.
MozReview-Commit-ID: KvQAawfzXao
--HG--
extra : rebase_source : 758e325c6ec192d83fcfa10f8c878ba2629e45a3
This is fairly straightforward to represent as a GENERATED_FILES, though
we have to take some care to construct the outputs tuple correctly. This
script needs to run during export, and unfortunately none of the STL
headers have proper file extensions, so the 'new' header is
special-cased in the recursive make backend to serve as a marker for
running it in the correct tier.
We can't remove the stl-headers file yet because it is still used for
the system header generation.
MozReview-Commit-ID: 3tQTOY0LAsQ
--HG--
extra : rebase_source : bd9f00e45a7bce4daaa0e1c16e22b28536658e37
These don't actually install correctly, because 'private' is already a
system wrapper. Neither of these files are included anywhere, so there's
no harm in removing them.
MozReview-Commit-ID: 1IAFMZDvKDV
--HG--
extra : rebase_source : 6e153324d2add32a179d07020270db96e7ec6dd0
This is no longer used in the tree, and the $ will get eaten somewhere
along the way on the path from moz.build to the python invocation by
make despite being shell_quoted.
MozReview-Commit-ID: 5mwWQYDn8Nf
--HG--
extra : rebase_source : f2289f5f5e15529475cac6cba3fc675592c111f2
Mike Hommey
David Major
Ting-Yu Chou
Nathan Froyd
Andreea Pavel
Sylvestre Ledru
Mike Shal
Dragana Damjanovic
Alfredo.Yang
Brindusan Cristian
André Bargull
Chris Manchester
Ryan VanderMeulen
Phil Ringnalda
Ted Mielczarek
Sebastian Hengst
Jonathan Watt
Narcis Beleuzu
Randall Barker
Jon Coppeard