Bug 11308 – New (and better) linux/gdk build system.

• Status: RESOLVED
• Resolution: WONTFIX
• Component: New Bugs

[Krzysztof Kowalczyk]

New (and better) linux/gdk build system.

[Krzysztof Kowalczyk]

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).

[Krzysztof Kowalczyk]

Created attachment 11105 [details]
release gdk makefile

Release gdk makefile generated by the script.

[Krzysztof Kowalczyk]

Created attachment 11106 [details]
debug gdk makefile

debug gdk makefile generated by the script

[Krzysztof Kowalczyk]

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.

[Mark Rowe (bdash)]

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.

[Anders Carlsson]

Comment on attachment 11104 [details]
script for generatking gdk makefile

Based on Mark's comments I'm marking these patches r-

[Anders Carlsson]

Comment on attachment 11105 [details]
release gdk makefile

Based on Mark's comments I'm marking these patches r-

[Anders Carlsson]

Comment on attachment 11106 [details]
debug gdk makefile

Based on Mark's comments I'm marking these patches r-

[Holger Freyther]

(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.

[Holger Freyther]

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(-)

[Mark Rowe (bdash)]

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.

[Mark Rowe (bdash)]

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.

[Mark Rowe (bdash)]

Sigh, FIXED != WONTFIX.  Reopening to close correctly.