I'm intrested but can you do this write the generator in javascript. We can have a bootstrap GnuMakefile to build the javascript interpeter. My plan eventually was to use WebKit to build webkit so we would use the javascript interpeter and the dom support to build itself. So once you have a set of GnuMakefile does not matter where they come from we would use javascript/xml for the build. Initially you could just convert the python to javascript. 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 debugger. Ability to do a build from a web browser. Distributed builds using http. Lots of good stuff long term. In the javascript source code JavaScriptGlue there is a main driver for js. Maybe on of the javascript developers could explain how to set up a command line driver for js. So that was my plan ... So if your willing to use javascript instead of python I'm very intrested. Mike On 10/15/06, Krzysztof Kowalczyk <kkowalczyk@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 cmake and doing it my way seemed simpler and faster (for me) than learning about cmake.
What is it?
http://bugs.webkit.org/show_bug.cgi?id=11308
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 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; 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)
Disadvantages: * doesn't build shared library but a standalone exe. Can be fixed in the future if there's a 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
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@opendarwin.org http://www.opendarwin.org/mailman/listinfo/webkit-dev