[Po4a-devel] build methods

[Neil Williams]

On Sun, 8 Nov 2009 19:52:17 +0100
Nicolas François <nicolas.francois at centraliens.net> wrote:

> For releases, I'm usually first doing an upstream release (make dist), and
> then I copy the debian directory (minus some files).

Yes, I ended up using similar things for my CVS packages. It's one
reason I prefer subversion - svn-buildpackage is more "upstream-aware"
than cvs-buildpackage.

> I'm attaching the Makefile provided by the previous maintainer, which
> worked up to now.
> 
> I would be open to move po4a to something more modern (another VCS
> included).
> (Note that the *-buildpackage may not be sufficient since I need to be
> able to make upstream releases.)

Not a problem, if we choose svn. svn-buildpackage works nicely with an
existing upstream tarball, prepared by alternative methods like make
dist. (It has to, I'm maintainer of svn-bp and I require that it obeys
my upstream requirements as well as my Debian native ones.)
;-)

> With the attached Makefile, I'm using the following layout:
> 
> pkg/
>     orig/po4a/
>               Makefile (the attached Makefile)
>               po4a-cvs/ (a checkout of the po4a repository)
> 
> for a releases:
> 1) I'm updating po4a-cvs/
> 2) I'm copying orig/ to build/
> 3) I'm running make from build/po4a/
> 4) This creates all the files in build/po4a/

Ah, I see.

svn-bp can do that using mergeWithUpstream behaviour. I'd 'make dist'
in the working copy, set that tarball as the .orig.tar.gz for svn-bp
and then svn-bp merges the debian/ stuff onto the decompressed 'make
dist' tarball.

I'm currently playing with po4a in a local svn because it's easier to
do the layout tests that I need for po4a-build.

First, I'm trying to get po4a-build to work cleanly with the "assumed"
layout:

Script output translations:
po/

Manpage output translations:
doc/po

HTML output translations (which could be merged with those in doc/po,
as done currently with svn-bp and emdebian-rootfs):
doc/www

Once that's working cleanly, I'll see what is needed to get po4a-build
to work with the po4a layout:

Script output translations:
po/bin/

Manpage output translations:
po/pod/

HTML output translations :
po/www

The main check there is whether the Makefile snippet packaged with
po4a-build is happy to accept working in po/bin instead of po/ and
whether sub-directories of po/ then confuse it. This is a necessary step
to ensure that po4a-build is cleared of hidden assumptions prior to a
release.

Is anyone on this list packaging po4a for Fedora? (I note Fedora has
po4a already).

It would be nice to know if the proposed po4a-build layout (for built
files) is helpful or a hindrance to RPM building:

script output:
$(DESTDIR)/share/locale/<$lang>/LC_MESSAGES/

manpage output:
doc/<$PACKAGE>/man/man1/
doc/<$PACKAGE>/man/<$lang>/man1/

html output:
doc/<$PACKAGE>/html
doc/<$PACKAGE>/<$lang>/html

I might investigate whether po4a-build should be sensitive to DESTDIR
too.

po4a-build does it this way because that's useful for Debian packaging
(so that our .install files can just use doc/$<PACKAGE>/* to include
both translated and untranslated content without needing updates each
time a new translation is added *and* allowing manpages for one script
to be packaged separately to manpages for a different script.

($PACKAGE in the above corresponds to the *binary* package name in
Debian, whereby one source package builds multiple binary packages and
the manpage needs to accompany the script it describes but *may* be
translated from a set of PO files that cover *multiple* scripts.)

So, if source package foo builds bar and baz, we could have:

<$prefix>./usr/share/locale/fr/LC_MESSAGES/bar.mo
<$prefix>./usr/share/locale/fr/LC_MESSAGES/baz.mo
./doc/bar/man/man1/bar.1
./doc/bar/man/fr/man1/bar.1
./doc/baz/man/man1/baz.1
./doc/baz/man/fr/man1/baz.1

bar then needs only:
./usr/share/locale/*/LC_MESSAGES/bar.mo
./doc/bar/*

It's years since I built RPM's, I can't remember whether this path
simplification would be useful or not. It certainly helps in Debian.

(The script output behaviour mimics exactly what happens with normal
autotools usage in intltool, line of least surprise etc.)

-- 


Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/po4a-devel/attachments/20091108/ba3d0046/attachment.pgp>