| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
The master bazelrc is now defined by preprocessor macro at (Bazel's) compile time. The default is still /etc/bazel.bazelrc for most platforms, but windows now has a %ProgramData% relative default value as well. Users wishing to change this default when building Bazel for a new platform should edit BAZEL_SYSTEM_BAZELRC_PATH in src/main/cpp/BUILD.
Part of https://github.com/bazelbuild/bazel/issues/4502, relevant to the duplicate issue #4809.
TESTED: default settings were tested manually, since they cannot be tested in a sandbox
RELNOTES: Windows default system bazelrc is read from the user's ProgramData if present.
PiperOrigin-RevId: 201423446
|
| |
|
|
|
|
|
|
|
|
|
| |
Leave functions that make file accesses in the file library, and general blaze utilities in the blaze_util file, but move the functions that boil down to string manipulation and path formatting to their own file. (With the exception of getCWD, since absolute path syntax is relevant here.)
Doing this largely to consolidate all Windows path control into a single place, so that it's easier to notice inconsistencies. For instance, ConvertPath currently makes Windows paths absolute, but not Posix paths, and MakeAbsolute relies on this behavior. In addition, JoinPath assumes Posix path syntax, which leads to some odd looking paths. These will be fixed in a followup change.
(Found these issues while working on #4502, trying to fix the windows-specific system bazelrc.)
RELNOTES: None.
PiperOrigin-RevId: 199368226
|
| |
|
|
|
|
|
| |
In preparation for https://github.com/bazelbuild/bazel/issues/4502, make OptionProcessor::GetRcFiles contain the logic for both the user bazelrcs and the master bazelrcs.
RELNOTES: None
PiperOrigin-RevId: 193521683
|
| |
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 184865343
|
| |
|
|
|
|
|
|
| |
This makes way more sense than using the name of the *parent* directory of the workspace.
Closes #4253 - thanks @akira-baruah for suggesting this change and making it happen!
PiperOrigin-RevId: 184147456
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
When looking up the .bazelrc file in the workspace or the home directory,
construct its name using the built-in product name instead of hardcoding
the name in the WorkspaceLayout class.
This removes an additional hardcoded value and changes the code to do the
right thing based on the product name.
--
PiperOrigin-RevId: 145077783
MOS_MIGRATED_REVID=145077783
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The new methods (CanReadFile, CanExecuteFile,
CanAccessDirectory) are a lot easier to implement
on Windows than a generic CanAccess. On POSIX
these methods are just a wrapper around the now
static-visible CanAccess().
See https://github.com/bazelbuild/bazel/issues/2107
--
PiperOrigin-RevId: 144176710
MOS_MIGRATED_REVID=144176710
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use/implement utility methods to join paths, check
if they are the root directory or are absolute,
etc. Doing so (instead of say checking if a path
starts with "/") allows for correct behavior on
Windows.
See https://github.com/bazelbuild/bazel/issues/2107
--
PiperOrigin-RevId: 142446027
MOS_MIGRATED_REVID=142446027
|
| |
|
|
|
|
| |
--
PiperOrigin-RevId: 141483567
MOS_MIGRATED_REVID=141483567
|
| |
|
|
|
|
|
|
|
|
|
|
| |
of the startup options.
This allows us to do the following:
- Avoid using the product name when reporting startup option parsing errors.
- Passing --bazelrc as a command argument throws an error (fix for issue #1659).
--
PiperOrigin-RevId: 141445030
MOS_MIGRATED_REVID=141445030
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change:
- starts using blaze_util::CanAccess and
blaze_util::PathExists instead of access(2)
- implements and starts using blaze_util::GetCwd
instead of getcwd(2)
- implements and starts using
blaze_util::ChangeDirectory instead of chdir(2)
- adds tests for the new wrapper methods
--
MOS_MIGRATED_REVID=138750297
|
| |
|
|
|
|
|
|
|
|
|
| |
* remove "using std::" declarations from header files
* add missing "std::" to some string declarations at some header files
* add "using std::string;" to some source files where necessary
--
Change-Id: Ib64f62b5add499d6171fa922227194ac992fa542
Reviewed-on: https://bazel-review.googlesource.com/#/c/6630/
MOS_MIGRATED_REVID=136355671
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The access() check in the do-while loop is basically doing the same thing
that the InWorkspace() function provides. So lets just call that function
instead. It also has the effect of making the code easier to read and
understand.
--
Change-Id: I02495775a9c9aa262396261824359538ca650e36
Reviewed-on: https://bazel-review.googlesource.com/#/c/6230
MOS_MIGRATED_REVID=134509465
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The result value of GetOutputRoot does not depend on the startup
options: it only depends on the environment and/or the hardcoded values
for Bazel and Blaze. Therefore, put it in the WorkspaceLayout module
just as we did for all other similar functions.
The fact that GetOutputRoot was part of BlazeStartupOptions was the root
cause behind the rollback of commit 4a45d92130a6b1306a3840d006df165b8040a6cf: in particular, that CL
silently added a virtual call to the GetOutputRoot method from the
constructor of the superclass, and this invokes undefined behavior
because the class has not yet been fully constructed. This caused Blaze
to have incorrect values for the output_root. By moving the function
out, we'll be able to roll that CL forward as it originally was.
As part of this change, add unit tests for the value of output_root
under various scenarios. These would have caught the discrepancy
introduced by that CL.
--
MOS_MIGRATED_REVID=133056251
|
|
|
This change introduces a new workspace_layout module that collects all
the static methods previously contained in the BlazeStartupOptions
class. These methods are not part of the options so it doesn't make
sense for them to be there.
--
MOS_MIGRATED_REVID=131576959
|
ccalvarin
ajmichael
philwo
Julio Merino
Laszlo Csomor
Luis Fernando Pino Duque
Thiago Farina