[webkit-dev] New build system for gdk/linux
opendarwin.org at bdash.net.nz
Mon Oct 16 19:36:37 PDT 2006
I'm curious as to what benefits you see from inventing your own build
systems. I don't see why it would be desirable to have "UI wizards" to an
automated build system, nor why a fully-featured debugger would be useful
in such a system. Can you elaborate on why any of these things are a good
direction for the Gdk build system to take?
> My plan eventually was to use WebKit to build webkit so we would use
> So once you have a set of GnuMakefile does not matter where they come
> So that was my plan the nice thing would be that you would have a
> natural way to add UI wizards etc to the build tool and you get the js
> Ability to do a build from a web browser. Distributed builds using http.
> Lots of good stuff long term.
> up a command line driver for js.
> of python I'm very intrested.
> On 10/15/06, Krzysztof Kowalczyk <kkowalczyk at gmail.com> wrote:
>> This e-mail is to let interested people know about my new build system
>> for gdk/linux and "sell" it so that hopefully it get integrated into
>> official tree.
>> Why new build system?
>> I wasn't happy with what bakefiles generate (mostly the unnecessary
>> recompile with gneerated makefile and the fact that there's only one
>> target and not standard release/debug build). I also plan on trying to
>> build a minimal version of gdk/linux (e.g. without xslt or xpath
>> support) and I felt that bakefiles won't let me experiment easily.
>> Why not fix bakefiles?
>> Bakefiles seem like a good idea but badly implemented and the project
>> is almost dead. It seemed faster to do it my way than learn enough
>> about bakefiles to fix the things that annoy me.
>> Why not cmake?
>> I would love to see cmake-based build for Gdk as well, but I don't know
>> and doing it my way seemed simpler and faster (for me) than learning
>> about cmake.
>> What is it?
>> It's a simple python script that generates 2 Makefiles: release and
>> debug for gdk/linux, which I call Makefile.gdk.rel and
>> Makefile.gdk.dbg. I think it makes sense to keep both the script and
>> generated makefiles in the repository to make it easier for people to
>> compile gdk/linux version out-of-the-box. Makefiles don't change that
>> often so re-generating them is not a big deal.
>> I kept the nice tricks I've learned from bakefile-based makefiles.
>> I realize it's unusual to have a makefile per target - usually it's
>> done with one makefile with condititional code. One makefile saves dev
>> time if a makefile is being written by hand, but it doesn't matter in
>> case of a makefile generated by a script. Having separate makefiles
>> makes it easier to debug them because more things are spelled out.
>> What are advantages of this Makefile over bakefiles:
>> * builds both debug and release targets, in separate directories; other
>> easy to add
>> * no dependency on bakefiles, just python, for generating the makefiles
>> * makefile generated by bakefile causes unnecessary rebuilds (i.e. make
>> make should do nothing, but it rebuilds some jsc files)
>> * one, non-recursive makefile (for some it might be disadvantage;
>> supposedly recursive makefile should be considered harmful)
>> * meta-description is much shorter (my script uses dir + list of
>> exceptions to specify files for the makefile while bakefiles/cmake
>> requires listing every file explicitely)
>> * doesn't build shared library but a standalone exe. Can be fixed in the
>> if there's a need.
>> * doesn't generate wx/win makefiles, but... win is maintained by hand
>> there is no wx work at all, so the point is moot
>> Adding this build system to the tree doesn't mean that bakefiles have
>> to go - as long as there are people maintaining those system, there's
>> no harm in having more than one. I use this makefile for my builds and
>> I plan on maintaining it in the future.
>> -- kjk
>> As a sidenote, I don't understand why most makefile generators
>> (bakefile and cmake) require listing every file to build. My little
>> script uses directory + list of exceptions (files *not* to compile)
>> which makes for a dramatically more compact description of targets.
>> webkit-dev mailing list
>> webkit-dev at opendarwin.org
> webkit-dev mailing list
> webkit-dev at opendarwin.org
More information about the webkit-dev