[Webkit-unassigned] [Bug 64923] [EFL] Defines header files will be publicly installed explicitly.

Sun Jul 24 23:56:24 PDT 2011

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

--- Comment #9 from Kangil Han <kangil.han at samsung.com>  2011-07-24 23:56:24 PST ---
Dear Raphael,

Here are my answers.

1. Creating 'private' directory and moving files contain internal API seem good to me. However, I think this suggestion is improving my patch not a substitution. One my small concern about your idea is that there are no ports using 'private' directory. For example, GTK port locates '*private*' header files together with others.

2. I believe 'white-list' way is better than 'black-list'.
At initial time, I only concentrated on removing 'ewk_util.h' file from installation.
But, some of my colleagues suggested me to change a way to define open header list from 'black-list' to 'white-list' while internal code-review. I agreed with them because I thought 'white-list' way would reduce mistakes from developers especially newly joined people. This is because newly created header file without addressing in cmake won't affect system. As you mentioned, internal header files would be created more frequently and as a result, developers would not be irritated from inserting one line in cmake file. This is also an additional benefit from this patch.

3. You are right. 'EWebKit.h' is the file that developers, who want to implement stuff by using EWebkit, should know about. However, Including header correctly to 'EWebKit.h' should be precondition of my patch. Rather, my patch will remove internally used header files from installation. As you said, developers would read 'EWebKit.h' in most cases but I think installing internal header files to the system is not nice.

I hope this helps your understanding.

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