[cairo] Re[4]: Cairographics on win32

[Tor Lillqvist]

I wrote:
 > > Surely it is next to impossible to create a ready-to-use makefile
 > > for nmake for the libraries with more complex dependencies.

Hans Breuer writes:
 > Why do you think GLib is in any way special? 

Because it's at the bottom of the dependency chain of what people
usually want to build themselves (the prebuilt binaries for
gettext-runtime and libiconv seem to work fine).

 > Pango adds nothing.

Well, Pango adds a dependency on the usp10.h header, if one wants to
build a properly working Pango on Win32, so one might need to download
the Platform SDK to get that.

 > Atk adds nothing. Gdk-pixbuf adds at least libpng and thus
 > zlib. Gdk adds wintab. Gtk adds noting anymore. [1]

Yes. But my "libraries with more complex dependencies" referred to
things like libgnomeui, which depends directly (if you believe the
configure.in) on libgnome-2.0, libgnomecanvas-2.0, libbonoboui-2.0,
gtk+-2.0, gconf-2.0, pango, libglade-2.0 and gnome-vfs-2.0, and
indirectly then also on all the gtk+-2.0 dependencies, ORBit2,
libxml-2, libIDL. At least.

 > Constantly failing with auto*tools is - for me - a bigger pain. 

Well, yes, I certainly see your point. Maybe I'm just lucky when I
have managed to get the autofoo/libtool toolchain working with
relatively little pain on my XP box.

 > And debugging via printf instead of with an integrated GUI doubly
 > so.

printfs aren't for debugging, but for producing logs that you can
investigate in a text editor scrolling back and forth, looking at
different locations in the log in parallel in different editor
windows, etc. Interactive debugging is another thing, and of course
also very useful. Although gdb has it quirks, it's bearable. But
interactive debugging is not useful for the same purpose as well
thought out debugging printouts collected into a log file.

 > Having to maintain a complete parallel build environment sure isn't ideal.
 > But ignoring the contributions (and needs) of developers coming from the 
 > windoze site isn't either.

I was not suggesting ignoring contributions. (Or was I? If so, ignore it...)

 > > (But then, cairo has relatively few dependencies, so for cairo a
 > > separate manually written nmake makefile probably might make sense.)

 > Really? For PS you need zlib. For PNG add libpng. For PDF there is
 > the whole freetype/fontconfig stack required (at the moment). And
 > last but not least the not optional libpixman dependency.

OK, so "relatively few" was exaggerating on the low side... (Er,
what's the opposite of exaggerate?)

Anyway, I guess we agree that for MSVC, something better than project
files or nmakefiles would be ideal. Be it then cmake or scons (neither
of which I have even looked at yet). Heck, if there existed such a
build system that was as elegant (heh) as autofoo, I would probably
prefer to use Visual C, too. 

Let's list requirements for such a build system. Please add to this list...

- Should be Open Source

- Ideally, should be multi-platform, Unix/Windows/MacOS, so that at
least some Unix folks would start switching over, and it would gain
support and momentum that way, and not only the people targetting
Win32 would have to maintain the configuration files.

- Should support parallel installations of different versions of
headers, libraries and runtimes for the same packages. For instance my
box has separate installed trees of GTK+ 2.4 and its dependencies,
GTK+ 2.6, and HEAD, plus separate directories for each version of a
package I build for distribution, and by switching PATH,
PKG_CONFIG_PATH and ACLOCAL_FLAGS (using small shell functions) I can
build using any of them.

- Ideally, should at least semi-automatically be able to import
Makefile.am files. Hmm, this is maybe asking too much...

--tml