[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:       Peter Kasting <pkasting () google ! com>
Date:       2009-05-25 4:28:52
Message-ID: d62cf1d10905242128h51c7bf12u494b411ab9336a6a () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


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.

My bias is always against #ifdefs so I feel more like David Kilzer does --
option #2 feels a lot cleaner to me.  On the other hand my experience is
much more with Chromium ports instead of WebKit ports so my opinion should
probably be discounted :)

PK

[Attachment #5 (text/html)]

<div class="gmail_quote">On Sun, May 24, 2009 at 12:19 AM, Maciej Stachowiak <span \
dir="ltr">&lt;<a href="mailto:mjs@apple.com">mjs@apple.com</a>&gt;</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&#39;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 \
(&quot;foo_bar_gtk.cc&quot;) so differing more doesn&#39;t seem to hurt much.</div> \
<div><br></div><div>My bias is always against #ifdefs so I feel more like David \
Kilzer does -- option #2 feels a lot cleaner to me.  On the other hand my experience \
is much more with Chromium ports instead of WebKit ports so my opinion should \
probably be discounted :)</div> <div><br></div><div>PK </div></div>



_______________________________________________
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]