[Webkit-unassigned] [Bug 57535] Fix compilation on Solaris 10 with Sun Studio 12, missing definition for time_t

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=57535





--- Comment #24 from Ben Taylor <bentaylor.solx86 at gmail.com>  2011-04-10 14:12:05 PST ---
(In reply to comment #23)
> (In reply to comment #22) 
> > so including a "config.h" file which includes a pile of stuff is preferable to a surgical include with wtf/Platform.h?  Whatever.  I'll test your method and if it works, great, and I can be done with this patch and this disagreement.
> 
> Note including config.h in the cpp's not the header file.

I'm assuming (other than the style issues) that you meant that I should be able to replace <wtf/Platform.h> and expect that <sys/time.h> would be included on SOLARIS systems only.  (Which is exactly what I've done on my
local base for compile testing) 

> "All implementation files must #include "config.h" first. Header files should never include "config.h"." -- http://www.webkit.org/coding/coding-style.html

indirect includes are always bad..

> Really the include of wtf/Platform.h is working around a problem in a cpp file. No header should have to include wtf/Platform.h The only thing I don't know is if we make exceptions in some odd cases but I'm not aware of them.

oh, I'm starting to see where you're going here.  So any cpp file that includes those three patched includes, would require the config.h, if they don't. I bet this patch now explodes with the number of files now required to be modified.  

> fwiw, I'm trying to help you. I'll admit that my note about sorting headers was off. At that point I wasn't looking at the patch. Only looking at and reacting to the notes about check-webkit-style giving false positives and a quick glance showed me this wasn't true.

Consider that running check-webkit-style against the files I'm working on,
and having it spit out a bunch of errors prior to modification, and then be told you're not doing it the right way.  Seems a bit hypocritical. But I can also see that the style engine may have come later and other files may still have style issues that won't be fixed, just for style issues.   I'm ok with that.  Just confusing..

> if you feel that I'm not being helpful, I'm willing to go away and not touch this bug anymore.

I'm happy for reviews, just having a hard time trying to get this patch into shape given all the "constraints".

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.