Re: EXTERNAL: Re: win32 installer?

From: Dieter Verfaillie <dieterv optionexplicit be>
To: Damon Register <damon w register lmco com>
Cc: gtk-devel-list gnome org
Subject: Re: EXTERNAL: Re: win32 installer?
Date: Tue, 17 Jul 2012 22:14:36 +0200

On 17/07/2012 13:14, Damon Register wrote:

On 7/16/2012 3:25 PM, Dieter Verfaillie wrote:

https://github.com/dieterv/gobject-introspection/commits/windows

Thanks.  I downloaded last night.  I hope you don't mind me asking
but I guess I don't totally understand what I read at the site.
Is this a complete snapshot of the gobject-introspection project
with your changes


Yes, it's a branch (in git) in a forked repository (the original
repository lives on git.gnome.org). You can get at it from a
windows machine using http://code.google.com/p/msysgit/

> or does this only represent the files that are
> changed.

I'm sure it's possible to extract those with some arcane git
incantation...

I tried building this windows version from you and got a fail saying
that gtk-doc.mak was missing.  I thought that perhaps the windows
bundle includes only files that are different so I copied all the
missing ones from the latest release (is this a correct assumtion?)


This can be worked around by either
http://www.go-evolution.org/Building_Evolution_on_Windows#Fake_gtk-doc
or maybe http://git.gnome.org/browse/gtk-doc-stub/

I've also attached the script I've been using to build g-i binaries.
Maybe it contains some tidbits of information that might help you...

autoreconf and configure seemed to work ok but make failed with this
output
e/glib-2.0/gobject/glib-types.h gir/glib-2.0.c g-ir-scanner g-ir-compiler.exe --output GLib-2.0.gir
  >  g-ir-scanner.args
    GISCAN GLib-2.0.gir
make[2]: *** [GLib-2.0.gir] Error 5

and a Python crash


Sorry, not enough information in there to tell what went wrong...

Which is used to produce the experimental GTK+ bundle (including
g-i and pygobject for Python 2.7) on:
http://optionexplicit.be/projects/gnome-windows/GTK+3/

I will have to try this.

Installers are for end user product (GIMP, Gedit, Inkscape, etc)
but not for libraries and components used to build such end user
products. An installer for some sort of an SDK however would a

I understand your point but I have to admit that the gtkmm installer
that I have used in the past was very handy.  I suppose all that is
really needed is to copy those libraries and components to a chosen
directory and maybe setup a few environment variables?

come to think of it, isn't that (SDK) what we normally think of
when talking installers?


I've seen requests for a shared GTK+ installation, which would be
insane, given the myriad of incompatible code generated by
different "mingw" gcc distributions out there. Let alone the horrors
of ApplicationX installing an "updated GTK+", breaking ApplicationY...
That last one is also why we'll never have .msm windows installer
merge modules distributed on gtk.org/ftp.gnome.org btw...

So, it doesn't hurt being specific ;)

Even a folder of files with some instruction
for setting environment variables would be great.


There is no (and there should never be any) need to abuse
environment variables, unless you rely on PATH for some
binary to be able to find libgtk and friends, which would
be a bug with the way said binary is installed imho. Things
get harder with language bindings though (ie integrating with
python.org's win32 interpreter installations, which doesn't
follow the unix-ish folder hierarchy used by the GTK bundle,
meaning python.exe lives in "/"and libgtk and friends in "/bin")

That leaves just a folder, which is exactly what the bundle is

and always has been (for example:http://ftp.gnome.org/pub/gnome/binaries/win32/gtk+/2.24/)


An SDK, in my mind, adds all the tools, sources, patches, scripts,
etc used to build that bundle (or to be correct, the packages making
up the bundle) and a way for application writers to integrate with
that system (so they don't have to reinvent the wheel). Versions of
tools would be set in stone for a given branch (let's say gcc 4.6 for
whatever packages are considered part of GNOME 3.4 and it's maintenance
releases, 4.7 for GNOME 3.6 etc). Not limited to gcc off course, but
*everything*. Application writer integrating with this system would
be able to generate their own "bundle" (think glade, gedit, whatever)
which can then be used to build real installers (using WiX,
NSIS, InnoSetup, whatever).

Doing all this is the only way we can guarantee end users (of the
SDK) in the distant future will be able to patch say a 3 year old
GTK+ branch when nobody is left around to maintain it, provided said
user can get at a sufficiently old windows version (let's not pretend
current mingw build envs will just work on future windows versions,
see what happened when vista got released for example)...

mvg,
Dieter

#!/bin/sh


PATH=".:/usr/local/bin:/mingw/bin:/bin:/c/WINDOWS/system32:/c/WINDOWS:/c/WINDOWS/System32/Wbem"
PYTHON_DIR="/c/bin/Python27"
CHECKOUT_DIR="/c/dev/gnome.org/gnome-windows/checkout"

MOD="gobject-introspection"
VER="1.33.0"
REV="git"
ARCH="win32"
THIS="${MOD}-${VER}-${REV}-${ARCH}"

ROOT_DIR="${CHECKOUT_DIR}/${MOD}/git"
SRC_DIR="${ROOT_DIR}/src"
BUILD_DIR="${ROOT_DIR}/build"
DIST_DIR="${ROOT_DIR}/dist"


(
set -x
date --rfc-3339=seconds


################################################################################
### Configure environment
################################################################################
LANG="C"
LINGUAS="nl fr"
ACLOCAL_FLAGS=""
PKG_CONFIG_PATH="/dummy"
XDG_DATA_DIRS="/dummy"

DEPS="zlib-1.2.5-2 gettext-runtime-0.18.1.1-2 gettext-tools-0.18.1.1-2 pkg-config-0.26-1 freetype-2.4.4-1 fontconfig-2.8.0-2 libpng-1.4.3-1 cairo-1.10.2-1"

for D in ${DEPS}; do
    PATH="${CHECKOUT_DIR}/legacynativebuilds/devel/dist/win32/${D}/bin:${PATH}"
    [ -d "${CHECKOUT_DIR}/legacynativebuilds/devel/dist/win32/${D}/lib/pkgconfig" ] && PKG_CONFIG_PATH="${CHECKOUT_DIR}/legacynativebuilds/devel/dist/win32/$D/lib/pkgconfig:${PKG_CONFIG_PATH}"
    [ -d "${CHECKOUT_DIR}/legacynativebuilds/devel/dist/win32/${D}/share/aclocal" ] && ACLOCAL_FLAGS="-I ${CHECKOUT_DIR}/legacynativebuilds/devel/dist/win32/$D/share/aclocal ${ACLOCAL_FLAGS}"
    [ -d "${CHECKOUT_DIR}/legacynativebuilds/devel/dist/win32/${D}/share" ] && XDG_DATA_DIRS="${CHECKOUT_DIR}/legacynativebuilds/devel/dist/win32/$D/share:${XDG_DATA_DIRS}"
done

# python
PATH="${PYTHON_DIR}:${PATH}"
PYTHON_VERSION=`${PYTHON_DIR}/python  -c "import platform; v = platform.python_version_tuple(); print(v[0] + v[1])"`

# libffi
PATH="${CHECKOUT_DIR}/libffi/libffi-3.0.11-1-win32/dist/bin:${PATH}"
PKG_CONFIG_PATH="${CHECKOUT_DIR}/libffi/libffi-3.0.11-1-win32/dist/lib/pkgconfig:${PKG_CONFIG_PATH}"

# glib
PATH="${CHECKOUT_DIR}/glib/git/dist/bin:${PATH}"
PKG_CONFIG_PATH="${CHECKOUT_DIR}/glib/git/dist/lib/pkgconfig:${PKG_CONFIG_PATH}"

export PATH
export LANG
export LINGUAS
export ACLOCAL_FLAGS
export PKG_CONFIG_PATH
export XDG_DATA_DIRS


################################################################################
### Prepare build and dist directory
################################################################################
mkdir -p "${BUILD_DIR}" &&
mkdir -p "${DIST_DIR}" &&


################################################################################
### Patch sources
################################################################################
#cd "${SRC_DIR}" &&


################################################################################
### Configure sources
################################################################################
cd "${BUILD_DIR}" &&

lt_cv_deplibs_check_method='pass_all' \
lt_cv_sys_max_cmd_len='32768' \
CC='gcc -mthreads' \
CFLAGS="-O0 -fno-inline -fno-omit-frame-pointer -g3 -Wall -march=i686 -mms-bitfields" \
CPPFLAGS="-I${CHECKOUT_DIR}/legacynativebuilds/devel/dist/win32/gettext-runtime-0.18.1.1-2/include \
-I${CHECKOUT_DIR}/legacynativebuilds/devel/dist/win32/zlib-1.2.5-2/include" \
LDFLAGS="-L${CHECKOUT_DIR}/legacynativebuilds/devel/dist/win32/gettext-runtime-0.18.1.1-2/lib \
-L${CHECKOUT_DIR}/legacynativebuilds/devel/dist/win32/zlib-1.2.5-2/lib \
-Wl,--enable-auto-image-base" \
PYTHON_INCLUDES="-I${PYTHON_DIR}/include/" \
PYTHON_LIBS="-L${PYTHON_DIR}/libs/ -lpython${PYTHON_VERSION}" \
PYTHON_LIB_LOC="${PYTHON_DIR}/libs/" \
"${SRC_DIR}/configure" \
    --disable-gtk-doc \
    --disable-silent-rules \
    --disable-static \
    --prefix="${DIST_DIR}" &&


################################################################################
### Make
################################################################################
cd "${BUILD_DIR}" &&

# We are passing --enable-auto-image-base on to ld, so relinking doesn't
# make much sense here. See:
#   - http://lists.gnu.org/archive/html/libtool/2002-09/msg00082.html
#   - http://lists.gnu.org/archive/html/libtool/2002-09/msg00094.html
#   - http://lists.gnu.org/archive/html/libtool/2002-09/msg00097.html
sed -e 's/need_relink=yes/need_relink=no/' <libtool >libtool.temp &&
mv libtool.temp libtool &&

GI_SCANNER_DEBUG="save-temps" \
PYDEVDPATH="/c/bin/eclipse/eclipse-cpp-indigo-SR1-incubation-win32-x86_64/plugins/org.python.pydev.debug_2.5.0.2012040618/pysrc" \
make install &&


################################################################################
### Clean dist
################################################################################
cd "${DIST_DIR}" &&

find . -name *.la | xargs rm -vf &&


date --rfc-3339=seconds
) 2>&1 | tee "${ROOT_DIR}/${THIS}.log"

Follow-Ups:
- Re: EXTERNAL: Re: win32 installer?
  - From: Murray Cumming

References:
- win32 installer?
  - From: Murray Cumming
- Re: win32 installer?
  - From: Ignacio Casal Quinteiro
- Re: EXTERNAL: Re: win32 installer?
  - From: Damon Register
- Re: EXTERNAL: Re: win32 =?UTF-8?Q?installer=3F?=
  - From: Dieter Verfaillie
- Re: EXTERNAL: Re: win32 installer?
  - From: Damon Register

[Date Prev][Date Next] [Thread Prev][Thread Next] [Thread Index] [Date Index] [Author Index]