Re: [Gimp-developer] Re: Gimp 1.3.22

2003-11-25 Thread Tor Lillqvist
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

2003-11-25 Thread Malcolm Tredinnick
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

2003-11-19 Thread Hans Breuer
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

2003-11-16 Thread Tor Lillqvist
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

2003-11-04 Thread Sven Neumann
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


Re: [Gimp-developer] Re: Gimp 1.3.22

2003-11-04 Thread Tor Lillqvist
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


[Gimp-developer] Re: Gimp 1.3.22

2003-11-03 Thread Tor Lillqvist
(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.

  (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? 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? Anyway,
doesn't the makefile.msc files refer to ../glib/build, not a build
directory in the GIMP source directory? (I.e., they require you to
have the glib (what version?) sources parallel to GIMP sources)

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

  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?

--tml


___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer