Skip to content
Snippets Groups Projects
  1. Sep 15, 2009
    • yaar@chromium.org's avatar
      Force inclusion of build/common.gypi for all chromium gyp files. · 21642abd
      yaar@chromium.org authored
      Why: Simpler build code. If everybody includes it, it should be included automatically.
      Why now: The webkit chromium builds need it be specified, since can't default to build/common.gypi.
      
      What was done:
      1. build/common.gypi's contents were moved to a new file build/gyp_chromium.gypi
      2. tools/gyp/gyp_chromium was moved to build/gyp_chromium and made to automatically include build/gyp_chromium.gypi.
      3. lots of gyp files were fixed to not refer to build/common.gypi any more.
      4. o3d which also builds independently of chrome, was fixed to have a gyp_o3d that includes gyp_chromium.gypi too.
      5. build/common.gypi was left empty, because there are some external projects that still refer to it.
      
      Things that are left to do after this patch is in:
      1. The following external files (in other repositories) need to stop include common.gypi
        ./third_party/hunspell/hunspell.gyp
        ./third_party/icu/icu.gyp
        ./v8/tools/gyp/v8.gyp
      2. Once nobody refers to common.gypi anymore, delete common.gypi
         -or-
         Delete gyp_chromium.gypi and move its content back to common.gypi
      
      Tested on mac, win and linux. On win, got a few unit tests errors on chrome bookmarks, which should not be related. I'm running again with clobber to verify.
      
      Review URL: http://codereview.chromium.org/206006
      
      git-svn-id: svn://svn.chromium.org/chrome/trunk/src@26302 0039d316-1c4b-4281-b951-d872f2087c98
      21642abd
  2. Sep 10, 2009
  3. May 29, 2009
  4. May 28, 2009
  5. May 27, 2009
  6. Mar 12, 2009
  7. Mar 11, 2009
  8. Mar 05, 2009
  9. Dec 31, 2008
  10. Dec 30, 2008
  11. Dec 16, 2008
  12. Dec 04, 2008
  13. Nov 22, 2008
  14. Sep 25, 2008
    • maruel@google.com's avatar
      Wow, it's been a while since we cleaned EOL. · de8d2667
      maruel@google.com authored
      Ran dos2unix on *.cc, *.h, *.py and SCons*.*
      Ran for /R /D %a in (*.*) do @if exist %a\.svn\. svn pset svn:eol-style LF %a\*.cc
      Ran for /R /D %a in (*.*) do @if exist %a\.svn\. svn pset svn:eol-style LF %a\*.h
      Ran for /R /D %a in (*.*) do @if exist %a\.svn\. svn pset svn:eol-style LF %a\*.py
      Ran for /R /D %a in (*.*) do @if exist %a\.svn\. svn pset svn:eol-style LF %a\SCons*.*
      
      
      
      git-svn-id: svn://svn.chromium.org/chrome/trunk/src@2611 0039d316-1c4b-4281-b951-d872f2087c98
      de8d2667
  15. Sep 14, 2008
    • maruel@google.com's avatar
      Provide necessary constructors in StackAllocator and PrivateHookAllocator to... · 1456372b
      maruel@google.com authored
      Provide necessary constructors in StackAllocator and PrivateHookAllocator to permit release mode building in VC++2008 SP1. The current allocators do not conform with the C++ spec for allocators, and unlike previous versions, VC++2008 requires conformant allocators.
      
      The reason that the allocators are not conformant is that any allocator, say, template<typename T> struct Alloc; must have a constructor of the following form:
      template<typename U> Alloc(const Alloc<U>& other)
      to allow construction of an Alloc<T> from an Alloc<U>.  The constructors cannot be explicit, because they're (essentially) copy constructors, and so are not called explicitly.
      
      StackAllocator has no converting copy constructor at all, and PrivateHookAllocator's is declared explicit, preventing it from being usable.
      
      Without the StackAllocator constructor, StackVectors fail (due to the std::vector member, base\stack_container.h(216)).
      
      Patch by Peter Bright <drpizza@quiscalusmexicanus.org>.
      
      
      git-svn-id: svn://svn.chromium.org/chrome/trunk/src@2175 0039d316-1c4b-4281-b951-d872f2087c98
      1456372b
  16. Aug 24, 2008
  17. Aug 09, 2008
  18. Jul 27, 2008
Loading