Generate Your Projects, or GYP, was designed around Chromium's needs.
Maintaining distinct project files for different build environments
and different platforms put a great burden on our team, and was never
intended to be a long-term solution. We really wanted to have a
single canonical
Kevin Ollivier wrote:
I'd be interested to know what limitations you guys ran into when trying to
use SCons for this sort of thing.
The SCons input language is too free-form to be easily shoehorned
into things like Xcode and Visual Studio projects.
SCons is flexible enough that mapping its
Brent Fulgham wrote:
The thing that worries me about this latest push to add GYP is that
there was much Google enthusiasm for the SCons stuff six months or so
ago, and SCons stuff started landing in the tree, and now that's all
been tossed away (apparently for performance reasons).
Do we
This sounds like a good experiment to me too. I don't know much about
jam (I've generally avoided it in Xcode) but I'd be happy to provide
GYP-side support.
Mark
Jeremy Orlow wrote:
I'm adding a bunch of the GYP experts to this thread and re-naming it for
sanity's sake. :-)
On Wed, Jul 15,
Peter Kasting wrote:
Note that you don't always want native (at least I think you don't). For
example, in Chromium we've ended up marking .cc/.h files, as well as .sh
files, as LF. .sln/.vcproj are CRLF (although I'm less sure what the issue
there is... it seems like native had some subtle
'kittens,
Would it be possible to get a copy of
libWebKitSystemInterfaceLeopard.a (from WebKit/WebKitLibraries) with
all of its symbols marked private extern? Or, if nobody actually
needs these symbols to be exported so globally, can the version that's
currently checked in be replaced with one
Darin Adler wrote:
I don’t remember if anyone answered you.
You're the first, but thanks for the response.
A simple way to transform the library into one with private extern would be
to use ld and -r, -exported_symbol or -exported_symbols_list, and
-keep_private_externs to make all the
Darin Adler wrote:
Probably not. But even though this is easy it could be a long time until
someone gets the free time to make and test this simple change. I was trying
to offer you the power to do this on your own schedule, but I see that
you’ve already tried it.
Given your story, it does
Tony brought me in to comment on what impact this might have on the
Chromium Mac build. It shouldn’t have any impact. Any use of the
compiler-defined macros is fine.
In Chrome code, we usually use MAC_OS_X_VERSION_MAX_ALLOWED and
MAC_OS_X_VERSION_MIN_REQUIRED from AvailabilityMacros.h, along with
Mark Rowe wrote:
TN2064 appears to have been last modified in 2003, so it predates the
existence of Availability.h.
Well, that’s about as long as I’ve been writing SDK- and
deployment-target-aware code…
Availability.h was introduced with the iOS SDK in order to support
availability macros
We just discovered (via a rollout on bug 91103) that there’s a bug
with __MAC_OS_X_VERSION_MAX_ALLOWED in the version of the 10.5 SDK as
present in Xcode 3.2.6. This may be the last version of the 10.5 SDK ever
released (I haven’t checked all of the early Xcode 4 releases). Chromium
uses this SDK
Mark Rowe wrote:
It'd be complicated to do this more widely since the AvailabilityMacros.h
version of the macros are defined even when building for iOS. We'd need to
review all of the uses to ensure that they were handled correctly. Given
that I think it'd be better to just use this as a
GYP was written in Python to address point (b). Python was already part of
the baseline requirements on all platforms, so we already had Python
available everywhere we needed it. There are no dependencies on external
binaries, and no compiled code needs to be checked in anywhere or
maintained as
Stachowiak wrote:
On Feb 4, 2013, at 10:46 AM, Mark Mentovai m...@chromium.org wrote:
GYP was written in Python to address point (b). Python was already
part of
the baseline requirements on all platforms, so we already had Python
available everywhere we needed it. There are no dependencies
or
test on the bot or something else. Used as we’re using it, GYP basically is
simple JSON, except the rules about commas are looser and # introduces
comments.
On Tue, Feb 5, 2013 at 2:47 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Tue, Feb 5, 2013 at 6:09 AM, Mark Mentovai m...@chromium.org wrote
interpreter. If this is the only
thing standing between a project and its adopting GYP, then it’s a really
easy one to get over.
On Tue, Feb 5, 2013 at 3:59 PM, Maciej Stachowiak m...@apple.com wrote:
On Feb 5, 2013, at 6:09 AM, Mark Mentovai m...@chromium.org wrote:
The parser
16 matches
Mail list logo
