| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
BUG=none
TEST=none
R=binji
Review URL: https://chromiumcodereview.appspot.com/9271061
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@119535 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
| |
Options2 is a copy of the resources for and implementation of chrome://settings that will be pared down significantly for UberPage (see bug).
BUG=100885
TEST=none
R=csilv
Review URL: http://codereview.chromium.org/8895023
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@114462 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 11079a4772dacf7865c3d650b7aa911242bb782e.
Revert "Fix build after code changed from underneath."
This reverts commit 93b43a2cd246c85ee6159a70223966f5efe2af86.
Revert "Moar build fix."
This reverts commit bf84b5766d5d05466da641685a1f554786598310.
Revert "Fix the fix."
This reverts commit 4aecf275ac5c7163483f48ffa2abcfa1481ffd53.
R=csilv@chromium.org
BUG=
TEST=
Review URL: http://codereview.chromium.org/8937011
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@114276 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
| |
Options2 is a copy of the resources for and implementation of chrome://settings that will be pared down significantly for UberPage (see bug).
BUG=100885
TEST=none
R=csilv
Review URL: http://codereview.chromium.org/8895023
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@114267 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
BUG=none
TEST=none
R=csilv
Review URL: http://codereview.chromium.org/8895023
TBR=jhawkins@chromium.org
Review URL: http://codereview.chromium.org/8930012
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@114239 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
| |
BUG=none
TEST=none
R=csilv
Review URL: http://codereview.chromium.org/8895023
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@114236 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Using the initializer list construct = {0} allows the object to be linker initialized.
Modify the LazyInstance class design to make it a pod aggregate type that can be linker initialized this way. Also combines the instance and state members, in line with the Singleton<> class design.
Introduces a new LAZY_INSTANCE_INITIALIZER macro specifically for using to init all lazy instances + modify all existing callsites to use it. (Old code would no longer compile)
BUG=94925
TEST=existing tests pass. http://build.chromium.org/f/chromium/perf/linux-release/sizes/report.html?history=150&header=chrome-si&graph=chrome-si&rev=-1 should step downward.
TBR=jam@chromium.org,rvargas@chromium.org,darin@chromium.org,ben@chromium.org,apatrick@chromium.org,akalin@chromium.org
Review URL: http://codereview.chromium.org/8491043
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@110076 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
| |
Implemented file related features
BUG=None
TEST=None
Review URL: http://codereview.chromium.org/7184032
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@89914 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
| |
http://codereview.chromium.org/6688056/ ), r=me.
BUG=58409
TEST=none
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@80063 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
| |
debug of broken contracts
BUG=58409
Review URL: http://codereview.chromium.org/6690002
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@77977 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
| |
the base namespace. Fix several files including lock.h unnecessarily.
BUG=none
TEST=none
Original review=http://codereview.chromium.org/6142009/
Patch by leviw@chromium.org
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@72106 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This enforces that the Singleton<T> pattern can only be used within classes which want singleton-ness.
As part of this CL I have also fixed up files which got missed in my previous CLs to use a GetInstance() method and use Singleton<T> from the source file.
There are a small number of places where I have also switched to LazyInstance as that was more appropriate for types used in a single source file.
BUG=65298
TEST=all existing tests should continue to pass.
Review URL: http://codereview.chromium.org/5682008
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@69107 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
singleton type. This enforces that the Singleton<T> pattern can only be used within classes which want singleton-ness.
As part of this CL I have also fixed up files which got missed in my previous CLs to use a GetInstance() method and use Singleton<T> from the source file.
There are a small number of places where I have also switched to LazyInstance as that was more appropriate for types used in a single source file.
BUG=65298
TEST=all existing tests should continue to pass.
Review URL: http://codereview.chromium.org/5682008
TBR=satish@chromium.org
Review URL: http://codereview.chromium.org/5721005
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@68936 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This enforces that the Singleton<T> pattern can only be used within classes which want singleton-ness.
As part of this CL I have also fixed up files which got missed in my previous CLs to use a GetInstance() method and use Singleton<T> from the source file.
There are a small number of places where I have also switched to LazyInstance as that was more appropriate for types used in a single source file.
BUG=65298
TEST=all existing tests should continue to pass.
Review URL: http://codereview.chromium.org/5682008
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@68932 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
| |
This just required fixing the remaining callers.
BUG=24672
Review URL: http://codereview.chromium.org/5356008
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67783 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
directory handling
[Checking to see if this build failures on Windows.] [[Nope. Failure was a
flake.]]
Previously we had a bunch of logic in profile_impl.cc that computed
where the cache directory lives. This change relocates it to
chrome_paths.cc.
Some background on cache directories.
There are two possible places to store cache files:
1) in the user data directory
2) in an OS-specific user cache directory
On Windows, we always pick (1). On Mac and Linux, we currently use
(2) in some circumstances. This patch changes both Mac and Linux to
have the same behavior with respect to (2).
The Mac/Linux shared behavior is that if the profile directory
is in the standard location for profiles, we put the cache files
into a matching directory name in the standard system cache directory
(e.g. on Linux if you're using ~/.config/google-chrome, your cache
ends up in ~/.cache/google-chrome; on Mac, the directories are
~/Library/Application Support versus ~/Library/Caches). If your user
data directory is not in the standard location, we use behavior (1).
The semantic changes of this patch should be:
- On Mac, previously we checked whether the (2) directory had some
particular subdirectories already when picking which one to use.
This was removed; which directory is used is solely a question of
whether the profile directory is in the standard location.
I think the previous behavior was unpredictable.
- On Linux, previously we only used behavior (2) if you hadn't changed
your user-data-directory at all. Now, to match Mac, as long as
your user-data-dir is in the standard place, you use the system
cache dir. So e.g. using ~/.config/foobar puts your cache in
~/.cache/foobar.
- On Linux, previously the default cache would end up as directories
under ~/.cache/google-chrome/; now it ends up as directories under
~/.cache/google-chrome/Default/.
(In all instances above, on Linux we continue to obey $XDG_CACHE_HOME.)
BUG=59824
TEST=New test ChromePaths.UserCacheDir
Review URL: http://codereview.chromium.org/5123004
TBR=evan@chromium.org
Review URL: http://codereview.chromium.org/5344003
TBR=viettrungluu@chromium.org
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67202 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
[Checking to see if this build failures on Windows.]
Previously we had a bunch of logic in profile_impl.cc that computed
where the cache directory lives. This change relocates it to
chrome_paths.cc.
Some background on cache directories.
There are two possible places to store cache files:
1) in the user data directory
2) in an OS-specific user cache directory
On Windows, we always pick (1). On Mac and Linux, we currently use
(2) in some circumstances. This patch changes both Mac and Linux to
have the same behavior with respect to (2).
The Mac/Linux shared behavior is that if the profile directory
is in the standard location for profiles, we put the cache files
into a matching directory name in the standard system cache directory
(e.g. on Linux if you're using ~/.config/google-chrome, your cache
ends up in ~/.cache/google-chrome; on Mac, the directories are
~/Library/Application Support versus ~/Library/Caches). If your user
data directory is not in the standard location, we use behavior (1).
The semantic changes of this patch should be:
- On Mac, previously we checked whether the (2) directory had some
particular subdirectories already when picking which one to use.
This was removed; which directory is used is solely a question of
whether the profile directory is in the standard location.
I think the previous behavior was unpredictable.
- On Linux, previously we only used behavior (2) if you hadn't changed
your user-data-directory at all. Now, to match Mac, as long as
your user-data-dir is in the standard place, you use the system
cache dir. So e.g. using ~/.config/foobar puts your cache in
~/.cache/foobar.
- On Linux, previously the default cache would end up as directories
under ~/.cache/google-chrome/; now it ends up as directories under
~/.cache/google-chrome/Default/.
(In all instances above, on Linux we continue to obey $XDG_CACHE_HOME.)
BUG=59824
TEST=New test ChromePaths.UserCacheDir
Review URL: http://codereview.chromium.org/5123004
TBR=evan@chromium.org
Review URL: http://codereview.chromium.org/5344003
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67201 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we had a bunch of logic in profile_impl.cc that computed
where the cache directory lives. This change relocates it to
chrome_paths.cc.
Some background on cache directories.
There are two possible places to store cache files:
1) in the user data directory
2) in an OS-specific user cache directory
On Windows, we always pick (1). On Mac and Linux, we currently use
(2) in some circumstances. This patch changes both Mac and Linux to
have the same behavior with respect to (2).
The Mac/Linux shared behavior is that if the profile directory
is in the standard location for profiles, we put the cache files
into a matching directory name in the standard system cache directory
(e.g. on Linux if you're using ~/.config/google-chrome, your cache
ends up in ~/.cache/google-chrome; on Mac, the directories are
~/Library/Application Support versus ~/Library/Caches). If your user
data directory is not in the standard location, we use behavior (1).
The semantic changes of this patch should be:
- On Mac, previously we checked whether the (2) directory had some
particular subdirectories already when picking which one to use.
This was removed; which directory is used is solely a question of
whether the profile directory is in the standard location.
I think the previous behavior was unpredictable.
- On Linux, previously we only used behavior (2) if you hadn't changed
your user-data-directory at all. Now, to match Mac, as long as
your user-data-dir is in the standard place, you use the system
cache dir. So e.g. using ~/.config/foobar puts your cache in
~/.cache/foobar.
- On Linux, previously the default cache would end up as directories
under ~/.cache/google-chrome/; now it ends up as directories under
~/.cache/google-chrome/Default/.
(In all instances above, on Linux we continue to obey $XDG_CACHE_HOME.)
BUG=59824
TEST=New test ChromePaths.UserCacheDir
Review URL: http://codereview.chromium.org/5123004
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67191 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
| |
This reverts commit r67160, test failures.
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67171 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we had a bunch of logic in profile_impl.cc that computed
where the cache directory lives. This change relocates it to
chrome_paths.cc.
Some background on cache directories.
There are two possible places to store cache files:
1) in the user data directory
2) in an OS-specific user cache directory
On Windows, we always pick (1). On Mac and Linux, we currently use
(2) in some circumstances. This patch changes both Mac and Linux to
have the same behavior with respect to (2).
The Mac/Linux shared behavior is that if the profile directory
is in the standard location for profiles, we put the cache files
into a matching directory name in the standard system cache directory
(e.g. on Linux if you're using ~/.config/google-chrome, your cache
ends up in ~/.cache/google-chrome; on Mac, the directories are
~/Library/Application Support versus ~/Library/Caches). If your user
data directory is not in the standard location, we use behavior (1).
The semantic changes of this patch should be:
- On Mac, previously we checked whether the (2) directory had some
particular subdirectories already when picking which one to use.
This was removed; which directory is used is solely a question of
whether the profile directory is in the standard location.
I think the previous behavior was unpredictable.
- On Linux, previously we only used behavior (2) if you hadn't changed
your user-data-directory at all. Now, to match Mac, as long as
your user-data-dir is in the standard place, you use the system
cache dir. So e.g. using ~/.config/foobar puts your cache in
~/.cache/foobar.
- On Linux, previously the default cache would end up as directories
under ~/.cache/google-chrome/; now it ends up as directories under
~/.cache/google-chrome/Default/.
(In all instances above, on Linux we continue to obey $XDG_CACHE_HOME.)
BUG=59824
TEST=New test ChromePaths.UserCacheDir
Review URL: http://codereview.chromium.org/5123004
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67160 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This regressed in r59021. I think I can fix it in a cleaner way
with some refactoring, but for now since I want to cherry-pick this
onto older branches let's revert some of r59021 to fix this in
the simplest way possible.
BUG=59824
TEST=manual (will write a test in my followup that refactors it)
Review URL: http://codereview.chromium.org/4911002
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@66066 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This makes PathService clear its cache after overriding a path.
We have many paths depending on each other, so this is necessary
to avoid inconsistencies.
TEST=ui_tests in Release mode
BUG=49838
Review URL: http://codereview.chromium.org/2805100
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@59021 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ui_test.
This makes PathService clear its cache after overriding a path.
We have many paths depending on each other, so this is necessary
to avoid inconsistencies.
TEST=ui_tests in Release mode
BUG=49838
Review URL: http://codereview.chromium.org/2805100
TBR=phajdan.jr@chromium.org
Review URL: http://codereview.chromium.org/3169031
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@56778 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This makes PathService clear its cache after overriding a path.
We have many paths depending on each other, so this is necessary
to avoid inconsistencies.
TEST=ui_tests in Release mode
BUG=49838
Review URL: http://codereview.chromium.org/2805100
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@56738 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This makes uses of StringPrintf and friends use the base namespace and include
stringprintf.h explicitly. This also removes a bunch of unnecessary string_util
includes (which exposed a few other errors like people forgetting to include
<vector>.
TEST=it compiles
BUG=none
Review URL: http://codereview.chromium.org/3119022
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@56446 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ui_test.
This makes PathService clear its cache after overriding a path.
We have many paths depending on each other, so this is necessary
to avoid inconsistencies.
Added a comment that PathService::Override should not be called
by production code.
TEST=ui_tests in Release mode
BUG=49838
Review URL: http://codereview.chromium.org/2805100
TBR=phajdan.jr@chromium.org
Review URL: http://codereview.chromium.org/3107001
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@55468 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This makes PathService clear its cache after overriding a path.
We have many paths depending on each other, so this is necessary
to avoid inconsistencies.
Added a comment that PathService::Override should not be called
by production code.
TEST=ui_tests in Release mode
BUG=49838
Review URL: http://codereview.chromium.org/2805100
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@55450 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
| |
We had the same code in three headers, and an "if FREEBSD" in a
_linux.cc file.
Review URL: http://codereview.chromium.org/414063
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@32722 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
| |
BUG=24355
TEST=NONE
Review URL: http://codereview.chromium.org/337054
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@30284 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
| |
I tried fixing all the Windows code but there's a *ton* of it.
This change will at least prevent people from adding new code that
uses the deprecated version (as that won't compile on Lin/Mac).
BUG=24672
Review URL: http://codereview.chromium.org/293013
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@29472 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
| |
PathService method, also avoids the conflict with the the windows function.
BUG=None
TEST=None
Review URL: http://codereview.chromium.org/196072
Patch from thiago.farina@gmail.com.
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@26351 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
See http://codereview.chromium.org/183025
Removes the deprecated version of PathService::Override that uses std::wstring
and fix the callers.
BUG=None
TEST=None
Review URL: http://codereview.chromium.org/185007
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@25185 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
| |
This was causing the browser tests to create browser tests instead of a renderer processes.
Also the SSL tests now pass on Linux and have been enabled.
BUG=None
TEST=Run the browser tests on Linux.
Review URL: http://codereview.chromium.org/146057
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19257 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, --user-data-dir called PathService::Override which called
AbsolutePath. On POSIX, this calls realpath and fails if the given
path doesn't actually exist.
We need to do this on Windows because we change the current directory
in order to load plugins (at least). However, on POSIX we shouldn't
ever change cwd.
So, on POSIX, don't try to make the user-data-dir absolute.
TEST=On POSIX, start chrome with --user-data-dir=/tmp/xyz (where xyz is a directory which doesn't exist). Once running, check that /tmp/xyz exists and contains the expected files.
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@14679 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
| |
TBR=tony
Review URL: http://codereview.chromium.org/87066
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@14154 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
| |
Review URL: http://codereview.chromium.org/67271
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@14152 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
| |
const per style compliance).
Preliminary work to enforce new PRESUBMIT.py rules:
- <=80 cols
- no trailing whitespaces
- svn:eol-style=LF
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10791 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
| |
platform specify its own downloads directory.
On mac this is unimplemented. On windows it remains the user document directory + "\Downloads\", and on linux we attempt to follow their XDG setting, but fall back to ~/Downloads if they have an unsafe value in their XDG setting.
Review URL: http://codereview.chromium.org/28167
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10669 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
| |
Review URL: http://codereview.chromium.org/11252
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@5679 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
| |
- Add some transition APIs.
- Start migrating some code to transition APIs.
Review URL: http://codereview.chromium.org/8825
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@4254 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
| |
before skipping it. Also update a couple instances and comments to reflect current behaviour (see also http://codereview.chromium.org/1681).
Review URL: http://codereview.chromium.org/1709
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@2060 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
| |
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1287 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
| |
started noticing the leak that had existed in this data structure all along. Now we clean up the heap objects correctly.
BUG=1334485
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1088 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
| |
data file, we need some of PathService, which brings along with it a bunch of other needed functions. So here are a bunch of stubs, along with another file's worth of passing tests. (Based on a patch from Dean.)
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@921 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
| |
minor, I created a new CL rather than reverting the old one.
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@722 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
| |
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@650 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
| |
* add file_util_posix.cc to mac port (NOTE: untested on linux)
* a bit of cleanup in path_service.cc related to this
* a few more cleanups to file_util.cc to make it build for mac
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@589 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
| |
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@533 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
| |
dependencies in path_service.cc.
One questionable decision here was to put GetCurrentDirectory and SetCurrentDirectory into file_util_win.cc. I could have kept the logic in path_service.cc with #ifdefs or I could have split up path_service.cc into path_service_win.cc, etc.
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@436 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
| |
Review URL: http://chrome-reviews.prom.corp.google.com/1107
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@435 0039d316-1c4b-4281-b951-d872f2087c98
|