Mike, I'm curious as to what benefits you see from inventing your own build system, written in JavaScript, that are not available with existing 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?
Cheers, Mark Rowe > 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 <[EMAIL PROTECTED]> 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 >> > _______________________________________________ > webkit-dev mailing list > webkit-dev@opendarwin.org > http://www.opendarwin.org/mailman/listinfo/webkit-dev > _______________________________________________ webkit-dev mailing list webkit-dev@opendarwin.org http://www.opendarwin.org/mailman/listinfo/webkit-dev
