Hi,

Tor Lillqvist writes:

and also libgimpbase/gimpwin32-io.h

That probably should be added to libgimbase/Makefile.am's EXTRA_DIST? The EXTRA_HEADERS macro doesn't seem to be used for anything in the generated Makefile?

I don't think EXTRA_HEADERS is a valid automake macro at all.

I am not sure about the purpose of libgimpbase/gimpwin32-io.h. Is it used only in the GIMP source tree or is it supposed to be installed so external plug-ins can use it as well? Anyway, it should certainly be added to libgimpbase_1_3_la_SOURCES.

Tor, will you take care of this? Can you remove the empty EXTRA_HEADERS line from libgimpmodule/Makefile.am while you are on it?

Sven

At 22:51 03.11.03 +0000, Tor Lillqvist wrote:

(Redirected to gimp-developer)

Is there any special reason that (almost?) all win32-specific stuff seems to be missing from release tarballs

No. The reason is nobody has tried to build for Win32 from a tarball, so nobody has noticed... or at least not reported her problems.

If anyone else out there does try to build The Gimp 1.3.x with msvc please ask for help here before silently dropping it again ;-)

(the same thing seemed to be the case with 1.3.21 already). The build directory is missing,

Hmm, how are you building GIMP? Does a mingw build really use the build directory?

If you are using MSVC, I guess the real question is, is there any chance that we will be able to claim supporting a MSVC build "out of the box" with a straight face?

Probably not, at least not until the issues outlined in

http://lists.xcf.berkeley.edu/lists/gimp-developer/2003-May/008589.html

are resolved. Though I still have plans to extend Pango to allow 'render to bitmap' and 'get glyph outlines' at least with two backends (win32 and FT2), there seems to be noone else interested. And currently I don't have enough spare time to put any of it to patches not to be accepted anyway ...

The stuff in the build directory is almost unmaintained, and requires manual intervention on the builder's system. Is manual editing needed for the makefile.msc files?

Only if there are files added or removed, so usually not that much when getting stable again ...

Anyway,
doesn't the makefile.msc files refer to ../glib/build, not a build directory in the GIMP source directory?

Right, I stil feel some 'build' configuration directory is enough, as outlined in glib/readme.win32.

(I.e., they require you to
have the glib (what version?) sources parallel to GIMP sources)

I'm almost always using recent cvs, but the same requirements as on *nix should be fine. That is the 2.2 series you are distributing should do it.

(If the GIMP's build directory is to be included in tarballs, it should be added to the top Makefile.am.)

It isn't as noted above, so please don't.

Thanks, Hans
-------- Hans "at" Breuer "dot" Org ----------- Tell me what you need, and I'll tell you how to get along without it. -- Dilbert

At 06:37 17.11.03 +0000, Tor Lillqvist wrote:

I wrote:

If you are using MSVC, I guess the real question is, is there any chance that we will be able to claim supporting a MSVC build "out of the box" with a straight face?

Hans Breuer writes:

Probably not, at least not until the issues outlined in

http://lists.xcf.berkeley.edu/lists/gimp-developer/2003-May/008589.html

The first issue there is about building fontconfig. Why assume somebody building *GIMP* with MSVC would want to build *everything* it depends on, too?

Where did I do this assumption ? Though on the other hand I think it'll help, cause usually The Gimp's usage of the Gimp Toolkit and Pango does trigger some bugs in the toolkit, which were not noticed until than or are long time known but simply not fixed.

For debugging purpose with msvc it helps a lot to build a debug enabled version of gtk+, pango and glib - i.e. :

nmake -f makefile.msc DEBUG=1

thus linking with msvcrtd.dll. But if one does not want to use the M$ debugger, sure it's fine to not build dependencies.

Though in that case why not (simply) use the mingw build ?

Though I still have plans to extend Pango to allow 'render to bitmap' and 'get glyph outlines' at least with two backends (win32 and FT2), there seems to be noone else interested.

Well, at least for me the issue is that I haven't investigated deeply enough of this to understand your point...

What issue : Wanting a common api for almost basic font stuff doable with different backends, to get backend independent application source ?
Wanting only one font configuration, or even font backend per application ?
Or trying to avoid the additional FT2/fontconfig dependency at all ?

almost unmaintained, and requires manual intervention on the builder's system. Is manual editing needed for the makefile.msc files?

Only if there are files added or removed, so usually not that much when getting stable again ...

But surely the current stuff in module.defs, for instance, which requires you to have the various dependency *sources* unpacked as siblings to your GIMP source directory, is not a good idea?

It depends. AFAIK one can as well install only your 'developer packages' at the configured places with some small adaptions in modules.defs. But I never tested it cause I'm building everything from source - usually from cvs ...

The build/win32 stuff should be changed to use pkg-config and *installed* developer packages of glib, gtk etc.

Why not throw in all the auto* tools to make the configure step take the same time as the compile step ? But serious: as everyone can easily see we have very different approaches how building The Gimp should work. I'd say to the benefit of giving choices. But it probably does not matter much cause we both appear to do it almost on our own.

If there is somebody else interested in compiling The Gimp under windoze please throw in your opinion. Or even better some concrete problems which stopped you from providing patches ;-).

Thanks, Hans
-------- Hans "at" Breuer "dot" Org ----------- Tell me what you need, and I'll tell you how to get along without it. -- Dilbert

On Tue, 2003-11-25 at 17:22, Tor Lillqvist wrote:

Tor Lillqvist writes:
> Then the "&build" should be removed from gimp's line in > CVSROOT/modules . Will this have some odd consequences, or can it be > done right away?

Anyone object? It might be that people will have to re-get gimp from CVS if "&build" is removed from gimp's line in CVSROOT/modules. (At least, I remember that when it was added some years ago, that was necessary.) Is this a big deal?

You don't have to do that. In your local copy, you can just remove the build/ subdirectory and edit the gimp/CVS/Entries file and remove the line that says "D/build///". There is no need to extract the whole tree again.

[These CVS survival tips brought to you by somebody on a slow dial-up connection. :-) ]

Cheers,
Malcolm