[prev in list] [next in list] [prev in thread] [next in thread]
List: webkit-dev
Subject: Re: [webkit-dev] Proposal for a new way to handle porting #ifdefs
From: Maciej Stachowiak <mjs () apple ! com>
Date: 2009-05-25 5:08:17
Message-ID: 7D5BD5C5-7DB5-41F5-BF54-15B8526DF4C6 () apple ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On May 24, 2009, at 9:28 PM, Peter Kasting wrote:
> On Sun, May 24, 2009 at 12:19 AM, Maciej Stachowiak <mjs@apple.com>
> wrote:
> On May 23, 2009, at 9:38 AM, David Kilzer wrote:
>> There are essentially two options here:
>>
>> 1. Add #if/#endif guards to entire source files, but include every
>> file in every build system.
>>
>> 2. Make each build system smart enough to exclude source files that
>> implement a feature, thus pushing the policy decision down (up?)
>> into the build system (which is where most of the decisions are
>> made today anyway).
>
>
> I know there is a potential compile time tradeoff, but in some ways
> it would be nicer if all build systems built the same set of files,
> and we ifdef'd the contents. That would put the policy decisions all
> in one place (the port header).
>
> It seems like build systems will already differ insofar as they
> include various explicitly platform-specific files
> ("foo_bar_gtk.cc") so differing more doesn't seem to hurt much.
We could actually avoid that by having all ports include FooBar.cpp in
the build, and that file conditionally #includes the appropriate port-
specific implementation.
> My bias is always against #ifdefs so I feel more like David Kilzer
> does -- option #2 feels a lot cleaner to me.
ifdefs can be messy, but at least the conditional logic becomes
explicit in the code, instead of being buried in various build
systems. I think the the only serious downside is the potential to
increase compile time.
> On the other hand my experience is much more with Chromium ports
> instead of WebKit ports so my opinion should probably be discounted :)
I don't think it should be discounted. It might be helpful to clarify
why you think ifdefs are a bad solution.
Regards,
Maciej
[Attachment #5 (text/html)]
<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; \
-webkit-line-break: after-white-space; "><br><div><div>On May 24, 2009, at 9:28 PM, \
Peter Kasting wrote:</div><br class="Apple-interchange-newline"><blockquote \
type="cite"><div class="gmail_quote">On Sun, May 24, 2009 at 12:19 AM, Maciej \
Stachowiak <span dir="ltr"><<a \
href="mailto:mjs@apple.com">mjs@apple.com</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex;"> <div style="word-wrap:break-word"><div \
class="im"><div><div>On May 23, 2009, at 9:38 AM, David Kilzer \
wrote:</div><blockquote type="cite"><span \
style="border-collapse:separate;color:rgb(0, 0, \
0);font-family:verdana;font-size:13px;font-style:normal;font-variant:normal;font-weigh \
t:normal;letter-spacing:normal;line-height:normal;text-align:auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div> \
<div style="font-family:verdana, helvetica, \
sans-serif;font-size:10pt;margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px"><div \
style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px">There are \
essentially two options here:</div> <div \
style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px"><br></div><div \
style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px">1. Add \
#if/#endif guards to entire source files, but include every file in every build \
system.</div> <div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px"><br></div><div \
style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px">2. Make \
each build system smart enough to exclude source files that implement a feature, thus \
pushing the policy decision down (up?) into the build system (which is where \
most of the decisions are made today anyway).</div> \
</div></div></span></blockquote></div><div><br></div></div><div>I know there is a \
potential compile time tradeoff, but in some ways it would be nicer if all build \
systems built the same set of files, and we ifdef'd the contents. That would put the \
policy decisions all in one place (the port header).</div> \
</div></blockquote><div><br></div><div>It seems like build systems will already \
differ insofar as they include various explicitly platform-specific files \
("foo_bar_gtk.cc") so differing more doesn't seem to hurt \
much.</div></div></blockquote><div><br></div><div>We could actually avoid that by \
having all ports include FooBar.cpp in the build, and that file conditionally \
#includes the appropriate port-specific implementation.</div><br><blockquote \
type="cite"><div class="gmail_quote"> <div><span class="Apple-style-span" \
style="-webkit-text-stroke-width: -1; ">My bias is always against #ifdefs so I feel \
more like David Kilzer does -- option #2 feels a lot cleaner to me. \
</span></div></div></blockquote><div><br></div><div>ifdefs can be messy, but at least \
the conditional logic becomes explicit in the code, instead of being buried in \
various build systems. I think the the only serious downside is the potential to \
increase compile time.</div><div><br></div><blockquote type="cite"><div \
class="gmail_quote"><div><span class="Apple-style-span" \
style="-webkit-text-stroke-width: -1; ">On the other hand my experience is much more \
with Chromium ports instead of WebKit ports so my opinion should probably be \
discounted :)</span></div></div></blockquote><br></div><div>I don't think it should \
be discounted. It might be helpful to clarify why you think ifdefs are a bad \
solution.</div><div><br></div><div>Regards,</div><div>Maciej</div><div><br></div></body></html>
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic