[CMake] Fix some CMake warnings

[Rob Buis]

CMake 2.8.5 reports warnings like this:

Manually-specified variables were not used by the project:

    ENABLE_LINK_PRERENDER

[Rob Buis]

Created attachment 150805 [details]
Patch

[Raphael Kubo da Costa (:rakuco)]

Comment on attachment 150805 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=150805&action=review

> ChangeLog:3
> +        [BlackBerry] Fix some CMake warnings

Shouldn't this rather have [CMake] instead of [BlackBerry] in the title? Other ports which use CMake have the same warnings.

[Rob Buis]

Hi Raphael,

(In reply to comment #2)
> (From update of attachment 150805 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=150805&action=review
> 
> > ChangeLog:3
> > +        [BlackBerry] Fix some CMake warnings
> 
> Shouldn't this rather have [CMake] instead of [BlackBerry] in the title? Other ports which use CMake have the same warnings.

Yes, you are right, sorry! Do you feel like reviewing?

[Raphael Kubo da Costa (:rakuco)]

Looks fine to me(In reply to comment #3)
> Do you feel like reviewing?

You probably also need to add the new flags to Source/cmakeconfig.h.cmake. I don't have reviewer superpowers, though :-(

[Rob Buis]

Created attachment 150845 [details]
Patch

[Rob Buis]

Hi Raphael,

(In reply to comment #4)
> Looks fine to me(In reply to comment #3)
> > Do you feel like reviewing?
>
> You probably also need to add the new flags to Source/cmakeconfig.h.cmake. I don't have reviewer superpowers, though :-(

Thanks! I am not complete sure if our port needs the cmakeconfig.h.cmake addtion, but I did update it in my latest patch.

[Raphael Kubo da Costa (:rakuco)]

(In reply to comment #6)
> I am not complete sure if our port needs the cmakeconfig.h.cmake addtion, but I did update it in my latest patch.

It might not need it now due to the features being disabled by default, but all CMake-based ports use that for the ENABLE() and USE() macros to work, otherwise the macro definitions will never be set.

Shouldn't you set the WTF_* entries in cmakeconfig.h.cmake as well?

[Rob Buis]

(In reply to comment #7)
> (In reply to comment #6)
> > I am not complete sure if our port needs the cmakeconfig.h.cmake addtion, but I did update it in my latest patch.
> 
> It might not need it now due to the features being disabled by default, but all CMake-based ports use that for the ENABLE() and USE() macros to work, otherwise the macro definitions will never be set.

Ok.

> Shouldn't you set the WTF_* entries in cmakeconfig.h.cmake as well?

You are right, however I do not see our port using these two in the near future. If you think your port will, I can add them?

[Raphael Kubo da Costa (:rakuco)]

(In reply to comment #8)
> > Shouldn't you set the WTF_* entries in cmakeconfig.h.cmake as well?
> 
> You are right, however I do not see our port using these two in the near future. If you think your port will, I can add them?

Right now it's mostly to make the patch consistent (otherwise even though the CMake warnings are fixed the other half of adding something to WebKitFeatures.cmake will not have been done).

[Rob Buis]

Created attachment 150943 [details]
Patch

[Daniel Bates]

Comment on attachment 150943 [details]
Patch

r=me

[Rob Buis]

Committed r121914: <http://trac.webkit.org/changeset/121914>