This is a heads up, and a call for feedback:
Barring a really compelling reason to the contrary, we're going to go ahead
and make SCons the official build system on Windows next week.
A key goal here is to get out of the current holding pattern. Trying to
keep the SCons build-on-the-side current
SCons build of chrome on Windows has (somewhat) recovered from the webkit
merge. This means you should be able to test the SCons-generated Visual
Studio files with something that actually builds chrome.exe and the various
test executables.
There are still test failures, which usualy indicate some
Hi Erik--
It depends on what you really want. SCons does have all of the
dependencies, but it doesn't keep the #include tree.
Tangible example: if foo.c #includes inc.h, and inc.h also #includes
both a.h and b.h, the resulting dependency list actually looks like:
foo.o: foo.c inc.h a.h b.h
The Linux build is ready to convert from Hammer to gyp.
I'm planning to close the tree for the conversion late some night, mainly to
coordinate the buildbot pieces with the other CLs (and to avoid interference
with other work, and vice versa, if things need rolling back). If closing
the tree to
Linux gyp conversion isn't happening tonight--stymied by an execution
problem preventing building libwebcore.a on the buildbot slaves (but not on
desktop systems).
I've reverted the initial buildbot changes and will re-open the tree shortly
once things have cycled green.
As you were,
Down to a handful of test failures that show up just on the buildbots. --SK
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
Heads up:
I'd like to take the buildbot off line tonight, ~22:00 PDT, to add size
tracking to the release builders. It should not be down long. Let me know
if that would interfere with any plans you have.
Thanks,
--SK
--~--~-~--~~~---~--~~
Chromium
The perf dashboard now tracks byte sizes of (some) key built targets.
Scroll to the bottom of the dashboard for the thumbnails.
This is primitive, but provides a place to start adding more sophisticated
tracking. Let me know what you'd like to see.
Right now, it just tracks the size of various
The gyp build can generate shared libraries on Linux (as of r14166).
You can set up to use shared libraries by setting the GYP_DEFINES variable
as follows:
$ export GYP_DEFINES='library=shared_library'
$ gclient runhooks --force
If it's not set when you run gclient, it will silently generate
Brad Nelson is planning to close the tree some time tomorrow night (Tuesday
28 April) to land the conversion of webkit to gyp-based build.
To get out from under playing constant catch-up with the rapidly-moving code
base, it's possible that we'll leave the tree converted even if there are a
small
Heads up: I'm gearing up to close the tree tonight for another attempt at
converting the webkit build to gyp, closure starting some time between 20:00
and 22:00 PDT. If this would be a serious imposition, let me know.
I'm still working on a few last issues. If I run into another serious
[sent this earlier, but from the wrong address...]
I'm going ahead with the attempted webkit conversion tonight. ETA to close
the tree ~20:30 PDT. --SK
On Thu, May 7, 2009 at 11:02 AM, Steven Knight s...@chromium.org wrote:
Heads up: I'm gearing up to close the tree tonight for another
We're getting closer to the final (?) conversion of chrome.sln on Windows to
GYP. While that work's getting finished, we want to make sure how we want
everyone to use GYP is adequately documented.
This will be structured as a set of how-to examples for the common tasks
that cover, say, 90% of
Announcement from the Do as I say, not as I do dept.:
.gyp and .gypi files should have their svn:eol-style property set to LF
(like most other files in our tree). I'm just fixing a bunch that I've
checked in without that.
If (like me) you've gotten used to having subversion configured to set
I've landed (finally) a change that takes urlmon.lib out of
activex_shim.lib. If you update and build, Visual Studio won't
automatically rebuild activex_shim.lib, which means it will still have
the urlmon.lib symbols in it. This may lead to errors like those
appended below when your build tries
Heads up, again, dept.:
In the next in an ongoing series of attempts to convert chrome.exe to gyp,
I'm going to (try to) land two changes now that you should be aware of:
1) convert the 'app' target in the chrome.gyp file to being named 'chrome'.2)
actually convert the 'chrome_exe' project to
, or whatever the right
combination of commands is. If you see Python stack traces from gyp
accompanied by complaints about looking up a Dir as a File, make sure the
tools/gyp subdirectory is at r521.
--SK
On Wed, Jun 17, 2009 at 9:25 PM, Steven Knight s...@chromium.org wrote:
Heads up
I'll add the dependencies I was complaining about :)
John just came by with some questions, so in the interests of sharing
information more widely, here's the executive summary for adding
dependencies you notice missing:
- There's no distinction in gyp between build-time and run-time
warns that every other project in chrome.sln must be
built before running (not true!). Is there a difference in build vs.
runtime dependencies?
Andrew
On Thu, Jun 18, 2009 at 3:25 PM, Steven Knight s...@chromium.org wrote:
All--
When you notice missing dependencies, pleased add them
+1 to what Tony (and Evan and others) have said. The stated goal *is* to
convert the official builds to Make, but we need to get the Make generator
(gyp backend) on par with the other generators.
Gyp now has a test infrastructure that we're using to characterize the
various generator behaviors,
Of interest to GYP developers (or anyone else who may need to roll the GYP
revision in DEPS):
The FYI (experimental) buildbot master now has a set of of canary slaves
that build Chromium with the latest tip-of-tree GYP on Linux/Mac/Win (and
run unit_tests and a few others, just for a sanity
Heads up for those using the GYP make generator: the GYP update last night
included a patch from mattm to add dependencies to the generated Makefiles
to run gyp to auto-regenerate the Makefiles if the .gyp file(s) change. You
should now be able to make changes to the .gyp configuration and
For Make, I don't see any reason off the top of my head why that shouldn't
work.
For SCons, seems like no one's ever had the itch to add CXXFLAGS (and
CCFLAGS) to the scons_import_variables list in build/common.gypi. LGTM if
you're so inclined to add it.
--SK
On Tue, Sep 22, 2009 at 1:32
The variable name is actually just 'library'. The default is set in
build/common.gypi. You can either change the default variable right in
build/common.gypi or set the environment variable
GYP_DEFINES=library=shared_library to get a shared library build.
(I have it modified locally in one of my
Our existing unit tests for file_util::CopyDirectory() do not test its
behavior when the destination directory already exists. The following CL:
http://codereview.chromium.org/271060/show
which adds unit tests for already-existing destination directories, shows
that Windows and POSIX behave
Yeah, that's about it. It's definitely time to make this switch. After the
gyp tests for make are green, it just needs someone with the right buidlbot
knowledge + time to work out the details.
(Last time I did a comparison of the make vs. scons build output there were
still some differences in
The current perf dashboard is getting long and unwieldy. I've put up a new
page which packs the same thumbnail graphs into a matrix:
http://build.chromium.org/buildbot/perf/dashboard/perf.html
Rows are the various perf tests we run, columns are the different build
slaves. It compresses the
, Steven Knight s...@chromium.org
wrote:
The current perf dashboard is getting long and unwieldy. I've put up
a
new
page which packs the same thumbnail graphs into a matrix:
http://build.chromium.org/buildbot/perf/dashboard/perf.html
Rows are the various perf tests we run, columns
Let me know if you notice any problems or have any suggestions for making
this more useful.
My lone suggestion is that page-load-time isn't accurate for all rows --
for example, the SunSpider row is measuring a benchmark number. It would be
nice to have a more accurate description, which
I just submitted r33208, which changes the locations of the memory
allocation code that used to be all in third_party\tcmalloc.
Executive summary: the new layout means you should (after updating) make
any memory allocation changes in the following locations:
base\allocator: mbelshe's shim
30 matches
Mail list logo
