Re: [Gimp-developer] Re: Gimp 1.3.22
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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Gimp 1.3.22
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? --tml ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Gimp 1.3.22
At 06:37 17.11.03 +, 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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Gimp 1.3.22
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? > 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... > >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? The build/win32 stuff should be changed to use pkg-config and *installed* developer packages of glib, gtk etc. And that's not only for the glib/gtk/etc sources. For instance, module.defs has the line: INTL = $(TOP)/gettext-0.10.40/intl even if the prebuilt binary Win32 distributions of glib etc haven't used gettext-0.10.40 for ages. The latest gettext-runtime distribution for Win32 from FSF is what should be used. Yes, I know that using pkg-config in a nmake makefile is not straightforward (due to the lack of backticks in the Win32 "shells"), but it can be done through some hackery involving building indirect command line option files, and/or building temporary .bat files at nmake time. Whenever I look at the stuff in build/win32 I get so depressed and feel that it should be junked altogether... > >(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. 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? (It probably should be removed from gtk+'s CVSROOT/modules line as well.) --tml ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Gimp 1.3.22
At 22:51 03.11.03 +, 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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Gimp 1.3.22
Sven Neumann writes: > 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? I assume it is to be used only in the source tree. > Anyway, it should certainly be added to libgimpbase_1_3_la_SOURCES. > Can you remove the empty EXTRA_HEADERS line from > libgimpmodule/Makefile.am while you are on it? Sure, done. --tml ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Gimp 1.3.22
Hi, Tor Lillqvist <[EMAIL PROTECTED]> 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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
