Von: "lode leroy"

some hints and remarks for building gimp-2.3.1+ from cvs

ftruncate is not present in my version of mingw, so I changed it to make it compile.

Maybe this should be autodetected by configure as HAVE_WIN32_FTRUNCATE
or maybe glib should provide g_ftruncate to wrap the platform-specific implementation...

There has been some confusion about this in glib and mingw. We shouldn't change anything without talking to the glib developers.

the autodetection of python on MSYS is not too good: the "\"es need to be replaced with "/"es, so I added this to

We took care of this in the GIMP build environment, but fixing it on the Python level is better, of course - especially as paths with forward slashes are valid at the Windows API level as well.

Michael

On Tue, Jun 28, 2005 at 11:31:48AM +0200, lode leroy wrote:

The native windows version of Python has it's headers in C:\Python24\include and not in C:\Python24\include\python24, so I changed the pythondev m4 macro as follows:

diff -u -r1.1 pythondev.m4 --- m4macros/pythondev.m4 24 Jun 2005 21:17:57 -0000 1.1 +++ m4macros/pythondev.m4 28 Jun 2005 09:19:09 -0000 @@ -10,7 +10,7 @@
dnl deduce PYTHON_INCLUDES
py_prefix=`$PYTHON -c "import sys; print sys.prefix"` py_exec_prefix=`$PYTHON -c "import sys; print sys.exec_prefix"` -PYTHON_INCLUDES="-I${py_prefix}/include/python${PYTHON_VERSION}" +PYTHON_INCLUDES="-I${py_prefix}/include/python${PYTHON_VERSION} -I${py_prefix}/include"
if test "$py_prefix" != "$py_exec_prefix"; then PYTHON_INCLUDES="$PYTHON_INCLUDES -I${py_exec_prefix}/include/python${PYTHON_VERSION}" fi

Blinding doing this isn't correct, especially if python is in /usr. Looks like we'll have to special case windows here.

the WMF plugin uses freetype2, but freetype2 likes to have "ft2build.h" included...

diff -u -r1.52 wmf.c --- plug-ins/common/wmf.c 4 Mar 2005 15:12:28 -0000 1.52 +++ plug-ins/common/wmf.c 28 Jun 2005 09:19:09 -0000 @@ -23,6 +23,8 @@

#include "config.h"

+#include "ft2build.h" +
#include
#include

Your libwmf library is too old. Upgrade.

the autodetection of python on MSYS is not too good: the "\"es need to be replaced with "/"es, so I added this to

Where did it screw up? You sure you are using a CVS snapshot with all the relevant changes? The ChangeLog should have:

2005-06-26 Manish Singh

* plug-ins/pygimp/Makefile.am: actually define pygimpdir in terms of pygimpbase.

C:\Python24\lib\site-packages\site-customize.py

import sys import os
import re
if os.environ.get("MSYSTEM") == "MINGW32": os.sep='/'
os.pathsep='/'
sys.prefix = re.sub('\\\\',os.sep,sys.prefix) sys.exec_prefix = re.sub('\\\\',os.sep,sys.exec_prefix)

Changing stuff outside of gimp should be considered last resort.

which is still not perfect: I modified python.m4 to replace "\"es by "/"es:

[am_cv_python_pythondir=`$PYTHON -c "from distutils import sysconfig; print
sysconfig.get_python_lib(0,0,prefix='$PYTHON_PREFIX').replace('\\','/')" 2>/dev/
null ||

Why is this needed at all? gimp doesn't use $pythondir anywhere.

-Yosh

On 6/28/05, Manish Singh wrote:

Changing stuff outside of gimp should be considered last resort.

which is still not perfect: I modified python.m4 to replace "\"es by "/"es:

[am_cv_python_pythondir=`$PYTHON -c "from distutils import sysconfig; print
sysconfig.get_python_lib(0,0,prefix='$PYTHON_PREFIX').replace('\\','/')" 2>/dev/
null ||

Why is this needed at all? gimp doesn't use $pythondir anywhere.

-Yosh _______________________________________________ Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

I don't know, but maybe this has something to do with python-fu or whatever it is [scripting in The GIMP with Python, as opposed to e.g. Perl or Script-Fu]. IIRC, some info about Python-Fu building on Win32 just came through the gimp-devel list, so... *shrugs*

On Tue, Jun 28, 2005 at 12:40:37PM -0400, michael chang wrote:

On 6/28/05, Manish Singh wrote:

Changing stuff outside of gimp should be considered last resort.

which is still not perfect: I modified python.m4 to replace "\"es by "/"es:

[am_cv_python_pythondir=`$PYTHON -c "from distutils import sysconfig; print
sysconfig.get_python_lib(0,0,prefix='$PYTHON_PREFIX').replace('\\','/')" 2>/dev/
null ||

Why is this needed at all? gimp doesn't use $pythondir anywhere.

I don't know, but maybe this has something to do with python-fu or whatever it is [scripting in The GIMP with Python, as opposed to e.g. Perl or Script-Fu]. IIRC, some info about Python-Fu building on Win32 just came through the gimp-devel list, so... *shrugs*

Uh, that's what this thread is about, pygimp on Win32.

The point being, $pythondir isn't used by the pygimp build stuff at all, so changing the above automake stuff won't actually do anything.

-Yosh

On Wed, Jun 29, 2005 at 09:02:54AM +0200, lode leroy wrote:

the autodetection of python on MSYS is not too good: the "\"es need to be replaced with "/"es, so I added this to

Where did it screw up? You sure you are using a CVS snapshot with all the relevant changes? The ChangeLog should have:

MSYS (especially sh.exe) needs / instead of \ in the paths. Printing paths from python (in pythondev.m4 and /usr/share/aclocal-1.9/python.m4)

Yes, and the configure script should take care of this. This is why I asked for confirmation that you have all the stuff needed for this to work (which you did not answer).

C:\Python24\lib\site-packages\site-customize.py

Changing stuff outside of gimp should be considered last resort.

I do not see an alternative: /usr/share/aclocal-1.9/python.m4 is not part of gimp,
but is used via aclocal...

Except the stuff you changed isn't used in the build...

which is still not perfect: I modified python.m4 to replace "\"es by

"/"es:

[am_cv_python_pythondir=`$PYTHON -c "from distutils import sysconfig;

print

sysconfig.get_python_lib(0,0,prefix='$PYTHON_PREFIX').replace('\\','/')" 2>/dev/> null ||

Why is this needed at all? gimp doesn't use $pythondir anywhere.

this particular test is used to detect the LDFLAGS to link pygimp against libpython

But $pythondir isn't used in LDFLAGS. $PYLINK_LIBS is used, and the backslash to forward slash transformation is performed on this.

If you're having to make changes to these files, it sounds like you're not using current enough sources.

-Yosh

lode leroy writes:
> ftruncate is not present in my version of mingw, so I changed it to make it > compile.

Why don't you upgrade to a more recent version then? (Or have they dropped their inline ftruncate() implementation in unistd.h from bleeding-edge versions?)

--tml

On 7/5/05, Tor Lillqvist wrote:

lode leroy writes:
> ftruncate is not present in my version of mingw, so I changed it to make it > compile.

Why don't you upgrade to a more recent version then? (Or have they dropped their inline ftruncate() implementation in unistd.h from bleeding-edge versions?)

MinGW/MSYS comes in about 20 or so different packages, which can be confusing to install. Did you install everything binary from MSYS/MinGW? If not, then we might have to go figure out which MinGW/MSYS components are prequesites to installing The GIMP.

michael chang writes:
> MinGW/MSYS comes in about 20 or so different packages, which can be > confusing to install.

Umm, isn't it more like half a dozen? From memory: gcc, binutils, gdb, w32api, msys, maybe the msysDTK (or whatever it was called, the package that contains the auto* support stuff if one needs that).

> Did you install everything binary from MSYS/MinGW?

Only the parts I needed. Not the Fortran or Objective C compilers, for instance.

--tml

Von: "lode leroy"

Looking at cvs.sf.net, ftruncate is still defined in unistd.h, but it was added after the release I was using.

Well, they provide updates as well - and installing them is recommended :)

BTW, does anyone know what exactly the MinGwPORT stuff is about? Is it the start of a package management system?

HTH, Michael

Michael Schumacher writes:
> BTW, does anyone know what exactly the MinGwPORT stuff is about? Is > it the start of a package management system?

As far as I have been able to figure out, it's a way to package a patch and pre- and post-build scripts to automate building something from a pristine source tarball. No version or dependency tracking or database of what's installed and where etc is involved, AFAICS. No binary distribution packaging either. So it's not a package management system. (Or maybe it's an early start of a such, although why invent yet another format instead of trying to port dpkg or rpm seems odd.)

--tml