make issues

[Kai-Uwe Behrmann]

Am 27.05.03, 00:24 +0200 schrieb Pablo d'Angelo:

> 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
Yes I understand this.

> 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

Would be fine for me not to go through the rules.mk file myself.

> 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?

> Do you mean, where to put the xrc, image, help, po and other files?
Yes I am in doubt of it, and just putted into src/[po,images,...] for the
moment.

> I have to admit that the current makefiles do not support the xrc,
> images and i18n stuff. We need a clean solution for that.
My checked in solution dont work as good as I would like. I am no makefile
expert, have to look at this.

> 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.
For the i18n stuff I could add an variable to locale so the hugin.mo file
get searched the right way, even it is located in actual src/po/de (for
german) and hugin executeable is in src/hugin/.  . This is an local
solution working in the build tree with an relative path.

> 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

Seems to be good default standards. Next would be to let PREFIX free
selectable by the user - for instance PREFIX=/home/user/user_me/test/hugin.
So most applications create an .huginrc like file to store all the path
variables for later searching in the home dir of the user. The time when
we can tell hugin last time wich pathes are valid would be install time.
Then should an decision been taken. - We can later add an panel in an
preferences dialog to change this on runtime. - To let the user decide
wich PREFIX he likes should be enough for beginning. If he/she takes
/tmp/my_test/hugin it would be good o find all hugin files under this
directory to erase the whole application later very easy.
With later rpm generation for unix packages (Bruno?) we can spread it in
the whole filetree around on standard places.

> 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.

Can You change tell me the new tree and I will make the changes as needed
in all source and the xrc files itselfe to work again.

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

> 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?)
There exist an wxConfig class wich maybe do the job. I am still reading
the docu.

> to compile for windows we could just use a different config.h
> file, with simpler SUFFIXES.
It would be fine to find these settings set in an windows environment.

> 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.
Yes there are a lot of standard querys wich are not allways usefull.
Configure could be adviced by an wizard to make it for simple programs
easier to handle. At the moment I am not aware of such an easy handling.
The only thing I could do is to copy an working script, and adopt it till
work as liked. I think as You take a hand at rules.mk we can stay with the
current system.

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

> 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?)
I think it could become a behaviour like any other config file: Take an
xrceditor and change the whole gui as You like. This was my first thought
about the xrc capabilities. Maybe we can get feedback from users providing
good layouts and include them into an release. In .hugin/xrc could reside
all the selfemade files.

> 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?

This option would be a good starting point for an uncertain project at
beginning. I hope not to stop in an unfinished state of an gui for PT
again.
At the moment I think sometimes make and friends are very timeconsuming to
learn. And this will get solved and then it works as we need it.

More concrete: I would like to take over the internal configure stuff of
hugin, due to my make unknowledge and let the make and directory structure
to others.

> ciao
>   Pablo

Tschuess
Kai-Uwe

PS: I checked in some files and it produced a lot of emails. Pablo can You
add an [hugin-cvs] or similiar to the Subjectline of this messages? Then
procmail could sort them more simple for me and I find them more clear on
the ptx list, where I want ot put them.