[webkit-dev] New build system for gdk/linux

[Mark Rowe]

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 <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
>> 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 at opendarwin.org
>> http://www.opendarwin.org/mailman/listinfo/webkit-dev
>>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at opendarwin.org
> http://www.opendarwin.org/mailman/listinfo/webkit-dev
>