The setting to ensure that there is a newline at the end of files when they
are saved is very annoying. Besides adding unnecessary and unexpected cruft
to diffs, some parts of the codebase (some of the reftest directories for
example) have a policy of NOT having a newline at the end of their files.
MozReview-Commit-ID: IjIYxDsKS13
This makes us write the code formatter settings into the workspace settings
directory instead of the project settings directory. This is preferable
since when users make settings changes they are more likely to work with the
workspace settings, so we should put them there. Putting them there also
fixes a bug whereby the calls to _write_noindex/_remove_noindex would
overwrite the formatter settings file shortly after it had been created.
To get the formatter to show up in the UI we also need to set the formatter
settings as a one line pref value in the CDT UI settings. This duplication
is what Eclipse does when a new formatter is manually added, and it's
necessary to get the formatter working correctly.
MozReview-Commit-ID: KP4w0VbNCF7
For some reason, Windows builders are setup in a way that prevents a
task from purging the toolchain cache of old files. Until that is
figured out and fixed, all the error message related to that achieves is
confuse people because the treeherder Failure Classification tab shows
them first. Practically speaking, the error doesn't prevent anything
from working properly. The worst that can happen is disk space running
out because of the toolchain cache being filled up, which would lead to
actual errors.
As the error happens on very many windows build, that leads to a lot of
errors being bucketed on bug 1391811, while they may well be varying
unrelated issues.
It also leads to people thinking their try builds fail because of that,
when they aren't (e.g. bug 1408212).
--HG--
extra : rebase_source : e25fc99db8e0920cfa238d0f78f15c78e140e3ec
This is just one flavor of the "reftets" suite, so we need to add a distinct
scheduling component for it.
MozReview-Commit-ID: AtKuvuUCk1l
--HG--
extra : rebase_source : 3f316f0293e8d1245fc6e891bbcd044586ab6c06
This was simply oversight before. I ran into this using the
taskcluster-proxy /bewit interface, which returns a URL of the form
https://domain.net/short/path/to.file?bewit="several thousand
characters", which leads to an IOError due to the long path. Let's
assume that such query strings and fragments are transient; we should
drop these parts of the fetched URLs when writing to disk.
MozReview-Commit-ID: FMJHMp7a3rA
--HG--
extra : rebase_source : da701e7d5250f59f39e4b6262952a08d0068e9ac
By using the PartialConfigEnvironment, the clients of buildconfig will
depend on config.statusd/ files instead of config.status directly.
Clients can access substs and defines using buildconfig.substs['FOO'] or
buildconfig.defines['BAR'], and then collect file-level dependencies for
make using buildconfig.get_dependencies(). All GENERATED_FILES rules
already make use of this because file_generate.py automatically includes
these dependencies (along with all python modules loaded).
As a result of this commit, re-running configure will no longer cause
the world to be rebuilt. Although config.status is updated, no build
steps use config.status directly and instead depend on values in
config.statusd/, which are written with FileAvoidWrite. Since those
files are not official targets according to the make backend, make won't
try to continually rebuild the backend when those files are out of date.
And since they are FileAvoidWrite, make will only re-run dependent steps
if the actual configure value has changed.
As a result of using JSON to load data from the config.statusd
directory, substs can be unicode (instead of a bare string type).
generate_certdata.py converts the subst manually to a string so the
value can be exported to the environment without issue on Windows.
Additionally, patching the buildconfig.substs dict no longer works, so
the unit-symbolstore.py test was modified to patch the underlying
buildconfig.substs._dict instead.
The other files that needed to be modified make use of all the defines
for the preprocessor. Those that are used during 'mach build' now use
buildconfig.defines['ALLDEFINES'], which maps to a special
FileAvoidWrite file generated for the PartialConfigEnvironment.
MozReview-Commit-ID: 2pJ4s3TVeS8
--HG--
extra : rebase_source : d6bb0208483f9f043e7be1b36907ca13243985f8
This removes the dependency on config.status for CONFIGURE_DEFINE_FILES.
Instead, each file depends on the specific configure values that it
uses.
MozReview-Commit-ID: H4oLmJei1KR
--HG--
extra : rebase_source : 287498e8c336d24b1c95d29caf97e5febb56063b
The config.statusd directory is created alongside config.status, which
contains the same information but is split across many files instead of
all in a single file. This allows the build system to track dependencies
on individual configure values.
MozReview-Commit-ID: 2DbwKCJuNSX
--HG--
extra : rebase_source : 8b6257fd9c75cff3e4b6513d69048c0e3fdda5f4
There's currently a function for getting added files (A) and modified files
(M). We'll also eventually need the ability to get deleted files (D) and any
combination of the above, e.g (AM). Rather than creating a new function for
each possible case, let's have a single function where you can pass in which
modifiers you are interested in. With this patch, if you want all modified and
added files, you can do:
get_changed_files('AM')
By default 'ADM' is used.
This also adds a 'mode' option for git. This allows consumers to return staged
files, unstaged files or both. The default ('unstaged') keeps the current
behaviour in tact.
MozReview-Commit-ID: 9IA1bxaJS80
--HG--
extra : rebase_source : 160f650220ca9a35b4b116bc9fa13f28d84419fa
Technically this turns on gnu++14. I encountered a few errors when using c++14:
1) _USE_MATH_DEFINES needed to be defined for MinGW
2) MinGW did not define _finite under c++14
3) MinGW's float.h did not define Microsoft specific float functions under c++14
All of these were because c++14 defines _STRICT_ANSI_ which MinGW obeys and
avoids defining certain functions. The first two could be patched around, but
the third was a blocker, so we switched to gnu++14
MozReview-Commit-ID: 6Y7gEQgApYp
--HG--
extra : rebase_source : dabbd40c049c36e780b585e0bef0a8e25887d089
Unfortunately this also needs to be kept in Makefile.in to handle
other consumers of INCLUDES while we transition them.
MozReview-Commit-ID: 9OYlu6Jv1XZ
--HG--
extra : rebase_source : 719200501a93e836a03a64b5e1cd950a8f2e696a