New (and better) linux/gdk build system.
Created attachment 11104 [details] script for generatking gdk makefile This is a script that generates gdk/linux makefile in top-level directory. Script should probably go under WebKitTools\Scripts\gen-gdk-makefile.py Generated makefiles are Makefile.gdk.rel and Makefile.gdk.dbg (names and directory are easily changeable in the script).
Created attachment 11105 [details] release gdk makefile Release gdk makefile generated by the script.
Created attachment 11106 [details] debug gdk makefile debug gdk makefile generated by the script
What are advantages of this Makefile over bakefiles: * builds both debug and release targets, in separate directories; other targets easy to add * no dependency on bakefiles, just python, for generating the makefiles * makefile generated by bakefile causes unnecessary rebuilds (i.e. make after make should do nothing, but it rebuilds some jsc files) * one, non-recursive makefile (for some it might be disadvantage) Disadvantages: * doesn't build shared library but a standalone exe. Can be fixed in the future if there's need. * doesn't generate wx/win makefiles, but... win is maintained by hand anyway, there is no wx work at all, so the point is moot Why not cmake? I would love to see cmake-based build for Gdk as well, but I don't know cmake and writing this generator seemed simpler and faster (for me) than learning about cmake. This is the script I'm using for building gdk and I plan on maintaining it in the future.
I'd like to see us go straight to CMake for Gdk rather than using yet another build system that needs to be kept in sync with other platforms. I started working on moving the Gdk port over to CMake last week, but unfortunately my machine with that work on it has been in the shop since then. I should be able to complete this work within a day or two of getting it back. I would much rather that we hold off on changing the build system until we can move directly to CMake.
Comment on attachment 11104 [details] script for generatking gdk makefile Based on Mark's comments I'm marking these patches r-
Comment on attachment 11105 [details] release gdk makefile Based on Mark's comments I'm marking these patches r-
Comment on attachment 11106 [details] debug gdk makefile Based on Mark's comments I'm marking these patches r-
(In reply to comment #5) > I'd like to see us go straight to CMake for Gdk rather than using yet another > build system that needs to be kept in sync with other platforms. Is cmake still the preferred option? In that case I would finish up my work and submit patches.
Created attachment 13880 [details] WorkInProgress to revive CMake and to allow non Qt platforms Is that the way to go for building Gdk? Or what is the current plan? CMakeLists.txt | 20 +++ ChangeLog | 9 + WebCore/CMakeLists.txt | 259 +++++++++++++++++++++++++++++++------------------ WebCore/ChangeLog | 9 + 4 files changed, 199 insertions(+), 98 deletions(-)
I'm not sure what the best approach is now. It seems as though the Qt port has moved from using CMake to preferring QMake. The last I heard the CMake-based Qt build no longer worked. That said, the Gdk "Bakefile" build system was very cumbersome when I last used it, both in terms of compiling with it and in terms of making changes in configuration. If CMake simplifies this then it can only be a good thing.
Given that the Qt port no longer uses CMake, I don't see any value in moving the Gdk port over to it when the Bakefile-based system is holding up reasonably, and has recently been picked up by the wxWidgets port in the wx-port-alpha branch. I think improvements to the existing build system would be preferable at this stage to a wholesale replacement. Based on this, I'm going to close this bug as WONTFIX. If we decide a different build system would be preferable at some stage in the future, we can handle that via discussion on the mailing list and a new bug report.
Sigh, FIXED != WONTFIX. Reopening to close correctly.