Hi Krzysztof, On Oct 15, 2006, at 4:32 PM, Krzysztof Kowalczyk 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.

About the only issue I'm aware of is the DerivedSources issue, which happens because Bakefile doesn't have a way to specify a 'true' pre- build step using GNU make. To be honest, I ended up moving the "DerivedSources" target out of my Unix/Mac makefiles, and instead created a build-wxwebkit script that runs regenerates the makefiles, runs DerivedSources.make, moves JS headers, etc. and then builds once the environment is fully prepped. Such a script is of course generally useful as a tool for automating the entire build process, so it doesn't seem to me a big issue to do things this way. Outside of the "pre-build step" issue, though, I've found it works very well for me, and I think the problems you're seeing are mostly with how the Makefiles, and supporting scripts, have been designed. Particularly the 'unnecessary rebuilds', more on that below.

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

We can, of course, do this for Bakefile too. Just create an option for specifying build target, like make TARGET=debug, and then set the build dirs to something like build-$TARGET.

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

I did some digging, and the problem (at least, that I see) is not Bakefile, it's WebCore/move-js-headers.sh. For more info, see here: http://bugs.webkit.org/show_bug.cgi?id=11322 The important thing to remember about Bakefile is that it generates standard GNU makefiles. So, if you find it re-building targets you don't think it should be, you can always run make -d and then grep for "Must remake" to find out which targets make thinks are outdated. Once you've found that, the lines above it should indicate which dependency caused the rebuild to occur. Once you know the dependency, you just need to figure out what incorrectly changed it's modification time, etc. and stop that from happening. I'm fairly confident you can totally remove any unnecessary target re-builds using that approach. Bakefiles, like anything else, can have 'bugs' in them.

* one, non-recursive makefile (for some it might be disadvantage; supposedly recursive makefile should be considered harmful)

What do you mean by recursive makefiles?

* 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

Well, it's true that there hasn't been for the past couple months or so, but that's partly because wxWidgets/wxPython is being included in Leopard and we've been trying to polish it as much as possible before the final build used for Leopard is decided, and also partially because I wasn't sure how I wanted to proceed on the port, in terms of simply wrapping the CG/Cairo ports or writing a wx backend. However, I'm seeing some increased interest in the wx port outside of myself ;-), and we've recently seen the addition of a wx wrapper for CG/GDI+/Cairo (on Mac/Win/Linux respectively), so that's starting to renew interest in the idea of a wx backend. I did actually spend most of yesterday trying to get the sources back up to speed, and I'm getting close to having patches for the compilation issues I found ready. So it's not a moot point for me, and in fact, although I'm working on Mac right now, the results of running update-file-lists.py suggest to me the Win port makefiles are out of sync with TOT as well. Of course, the reason this happens is that all source file changes must be made in three places (now four, actually, or five if you count CMake), which IMHO is getting very burdensome and inefficient. This is one area where wxWidgets is much nicer, as all build system changes only need to be made once. I will admit that, unfortunately, it appears the Bakefile maintainer is swamped with other projects and deadlines, and so the project is not being improved at a regular pace. But outside of the DerivedSources issue, which was fairly easy to work around, I haven't had any problems and Bakefile is of course being used almost daily on the wxWidgets project. Furthermore, when I look at CMakeLists.txt and the Bakefiles, I find the Bakefiles much more readable than CMake scripts, and in my experience that often translates into simpler maintenance. Anyway, I just wanted to clear these matters up. I know that Bakefile has it's issues, but I'm not totally sure the issues are really specific to Bakefile at all, or even if other systems provide better solutions out of the box. All I know is that Bakefiles + my build script gives me very efficient rebuilds, and wx is absolutely huge and certainly requires a great deal of efficiency over 3 platforms and multiple compilers, so I think Bakefile can certainly be used as an effective solution to this issue of maintaining cross-platform makefiles. Regards, Kevin

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