James Michael DuPont writes: > Hopefully we can get all the cool gnome apps running under windows
Correct me if I am wrong, but doesn't it go like this: GNOME is intended to provide on Unix some of the (high-level) features in Windows, that on Windows are implemented with stuff like COM and OLE (I am really not an expert in this issues, so bear with me if I babble). It does this using CORBA at the low level. Why would one then need to port GNOME as such to Windows? It wouldn't interoperate with native Windows applications anyway, i.e. you could not include some object that interfaces through COM/OLE/whatever in a GNOME container that uses CORBA, or vice versa. Or is it just eye candy you are after ;-) > The problem is with the resource compiler : > gmodule-win32res.lo and > gobject-win32res.lo are dependant on the command : > ../build/win32/lt-compile-resource gmodule.rc gmodule-win32res.lo > which complains that : > Using zero as build number That is just an informational message, not a warning or error. > gmodule-win32res.lo: file not recognized: File format not recognized The .lo file that the lt-compile-resource script produces is a "libtool object file", which actually is a small text file that contains some assignment lines. (Read lt-compile-resource, it's a relatively simple shell script.) At least .lo files are small text files on my setup (on Windows, not cross-compilation). Maybe with cross-compilation from Unix, .lo files are actually symbolic links to the real .o files? Or just .o files with another name? If so, you need to modify the lt-compile-resource script to just do a symlink or rename instead of creating the small text file. Or you can drop the resource file stuff from the makefiles, it's not essential for the DLLs. Why is this resource crap needed at all, you might ask? I want to include version resources in the GLib etc DLLs. (I.e. what you see in Explorer if you right-click a DLL and select Properties:Version.) It's just a hack that has evolved over time. Without feedback, I haven't bothered to try to improve it. As the compile-resource script says: # This is just my ([EMAIL PROTECTED]) idea, if somebody comes up with a # better way to generate version number resources, don't hesitate to # suggest. Please do try. The essential feature the (lt-)compile-resource script provides to me is that after a "make clean", the resource file gets recompiled with a bumped build number. (This happens only if the build number "stamp" file is present, which it is supposed to be only on the "official packager's" machine, so that new releases of "official" DLLs can be recognized from increasing version number resources. Of course, "official" is a silly word to use without offices or officers.) --tml _______________________________________________ Dia-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/dia-list
