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

[Mike Emmel]

On 10/16/06, Mark Rowe <mark at bdash.net.nz> wrote:
> 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
>

Well first your making the assumption its just a automated build system.
And traditionally that has been the case the ui and the build system
have been separated from each other.

By building on top of webkit you gain the ability to have both a
automated system and one you can you visual tools for.

Probably the biggest advantage of visual tools is they allow you to
look at code based on some aspect or based on the task your
preforming. Thus the tool would know all the files required for
building and allow you to browse the build files such as make files
and scripts. And of course it knows generated sources etc. I don't
think your arguing against being able to visualize a project.

For example one of my biggest problems is when someone has a build
failure they send you a snippet of output and you have to guess. If
the build including generated files was visual then its trivial to
send the build config and easy to view and compare. Also if the build
system was viewable then its trivial to have examples and a tutorial
on a web site.

Plus a ui especially a web like one makes it easy to describe the
project to interested people.

Making building a project form source simple and visual for newcomers
and even non programmers would open open source code up to a far
broader range of early adaptors then you have currently.

This alone is a huge reason to develop a build system that makes it
easy to create visual interfaces.

One of the big reasons I'm even working on webkit is that it provides
the foundation required to build software that allows both command
line or procedural interaction and a rich visualization framework.
This has never been readily available before. Build tools are just one
of the places  you could create a new kind of software.

Another examples is all the unix file manipulation tools with webkit
the command line versions and  ui interfaces for thems could easily
work from a common core code base think busybox on sterioids with a
nice ui interfaces.
Right now for file manipulation ui's you have the system file viewer a
generally brain dead file choosed and custom ui's. All of this can be
unified and integrated and also be accessible from the command line
and both command line tools and the ui can have right personlization
and customization abilities.
And finally since the ui is xml exporting it to a remote viewer is trivial.

In short its a new type of software that allows you to present a
command line interfaces visual interfaces and even act as a service if
needed.

Another example the unix pipe super useful until you start dealing
with complex output. By switching to xml based out put and exporting
javasript interfaces for the tools you can finally create something
that has the both the simple elegance of the unix pipe and the power
to process complex output without creating hacked semi parsers. The
sender and reciever can both export CSS styling and xml language
capabilites to allow the sender to convert the output to the desired
format. A terminal would then simply be a browser window similar to
lynx. And ui tools can finally be assembled just like shell scripts
from component parts.

The heart of unix is scripting and the pipe command Webkit offers a
route to create a better unix that also supports ui interaction
intrinsicly so I'm pretty excited about where it could end up.



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