make issues

[Pablo d'Angelo]

Hi,

On Mon, 26 May 2003, Kai-Uwe Behrmann wrote:

> Sorry for my misssounding monday morning mail.

no worries!

A short note about the makefiles:
i'd like to keep the makefiles inside the src dir simple, at the expense
of making rules.mk more complicated ;). When I captured what we excatly
need I'll put some more stuff into there, so that the hacks can go
away, and you can simply add something like

PROG_1_XRC = xrc/*.xrc
PROG_1_PO  = po/*.po

to the makefiles it should work like expected. I still hope that
this will save me some time in the future ;), when I need makefiles for
another project or so. (I probably have to start quite a few to see the
saving...)

Another thing that I was thinking about:
What was the reason for putting po and data under hugin/src and not under
hugin/src/hugin, when they are specific for the wxwin gui?

> Am 26.05.03, 13:15 +0200 schrieb Pablo d'Angelo:
> 
> > I haven't looked at what steps are needed for the i18 stuff, but I'll
> > have a look and if nobody volunteers to make a good transition to
> > automake/autoconf I'll add it to the makefiles.
> 
> I am underway to include the i18n in the buildprocess. The problem I
> have, is how to include paths to hugins for different installations. Is
> there a startingpoint for in the old hugins or ptbcbgui code?

Do you mean, where to put the xrc, image, help, po and other files?

I have to admit that the current makefiles do not support the xrc,
images and i18n stuff. We need a clean solution for that.

But I'm not completely sure where we should put this data so that we can
run hugin from the source directory and from an installed system. We must
also think about the windows world, where everything should be in one
directory. I don't know how programs are installed on a mac.

probably we therefore should keep everything a bit flexible so that we can
either compile hugin with the different pathes, or it could even load
its data paths on runtime from somewhere.

I do not like compiling absolute pathes into binaries. If we compile pathes
into the binaries they should be relative.

for the unix world I propose the following defaults:
PREFIX=/usr/local
BINDIR_SUFFIX=bin
DATADIR_SUFFIX=share/hugin
DOCDIR_SUFFIX=$DATADIR_SUFFIX/doc
RESSOURCEDIR_SUFFIX=$DATADIR_SUFFIX/xrc
DATA_DIR=RESSOURCEDIR/data

lets just keep images and all stuff need by xrc (and maybe other
gui code) inside RES_DATADIR. the final local data should go to
$PREFIX. We might not need a RESSOURCE dir at all for release
versions.

all the suffixes be compiled into the exe
(for example by creating a src/config.h) file and defining
the pathes there.

on system startup hugin could then add the right paths relative
to the location of the binary (is it possible to get that with
some wxwindows function?)

to compile for windows we could just use a different config.h
file, with simpler SUFFIXES.

Now I begin to understand why the autoconf/automake/libtool is so messy.
I just downloaded the gnu hello world program, and their configure script
is 240 kB big. And autoconf is unix only.

for the developer we could add a developer flag to the makefiles that
would switch between developer and release mode.

devel mode: change pathes so that we can run the binary right from the
            source dir, use ressource files.
install mode:  references to the system path, hugin the must be installed
            before running (not something I like, from a user
            perspecitve), use compiled in ressources. (or should we ship the xrc files
	    so that somebody can change them?)

hugin could also check system and local pathes on startup, so that
both is possible. this might be the right way.

I have the feeling that my thoughts are way too complicated. It should be really
simpler. Maybe we should put everything into one single flat dir ;) Any ideas?

ciao
  Pablo
--
http://wurm.wohnheim.uni-ulm.de/~redman/
Please use PGP