[Webkit-unassigned] [Bug 37945] CMake buildsystem

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Apr 27 11:49:31 PDT 2010


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





--- Comment #3 from Patrick R. Gansterer <paroga at paroga.com>  2010-04-27 11:49:31 PST ---
(In reply to comment #2)
> 1) Are you sure you need to list the headers in addition to the source files?
> On the build system we've made for the EFL port, we didn't include them and it
> worked like a charm.
The reason is to get them into the Visual Studio files. It will work without
them too, but it is usual to have the headers in the vcproj files.

> 2) Wouldn't it be nice to split the platform specifics into
> CMakeListsPlatform.txt? This way the main CMakeLists.txt wont't get polluted,
> with the drawback of having more files to touch in the event of certain changes
> (but it'll be easier than today since it is still only one build system
> format).
Since I have not done the WebCore and WebKit part by now, I don't know the
exact requirements there to do a _clean_ an universal solution.
It is possible to split the files, but it is very unusal in the CMake world.

> 3) Auto-detecting the platform is nice, but we need to come up with a better
> way to determine which build will be made (e.g. one might have both GTK+ and Qt
> libraries and won't be able to build the Qt port -- unless the main
> CMakeLists.txt file is edited). Perhaps a WEBKIT_PORT variable to be passed
> passed to cmake?
That's the reason why I move all platform decisions into the root
CMakeLists.txt. I'd like to implement a possibility to switch to a specific
port/backend via a CMake option. (auto dedection can only be the default
option).

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



More information about the webkit-unassigned mailing list