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

Re: RFS: presage



Thanks for all your help and comments on my package so far, Paul.

Paul Wise wrote:
On Sat, Jun 19, 2010 at 6:06 AM, Matteo Vescovi
<matteo.vescovi@yahoo.co.uk> wrote:

I haven't completely removed tinyxml from upstream presage because upstream
tinyxml doesn't ship with a build system capable of building a shared
libtinyxml library. In order for upstream presage to support those platforms
that don't provide a shared libtinyxml library, upstream presage needs to
embed tinyxml.

For those platforms that don't provide a shared libtinyxml library,
can't you just link against a static one instead?

Yes, exactly. That's why the upstream distribution embeds a convenience copy of libtinyxml and statically links against it.

You could send tinyxml upstream a patch to build shared libraries,
based on the tinyxml debian/rules file:

http://patch-tracker.debian.org/patch/debianonly/view/tinyxml/2.5.3-3

Another approach that works in other projects is to have a separate
tarball containing all of the external dependencies along with a
script to build them all. Essentially this is a miniature distribution
so it might be better to use packages from an existing distribution
like GnuWin32, Macports, fink or similar.

The current presage Debian package never builds against the embedded
version, as it build-depends on libtinyxml-dev and ./configure will detect
that a shared libtinyxml library is available and use it. The embedded copy
of tinyxml will not be built nor used in this case. Isn't this sufficient? I
can of course remove tinyxml before starting the build, but it seems an
unnecessary step. Advice?

Things change, removing the embedded tinyxml during build guards
against unexpected changes or buildd situations.

Fair enough, I added a rule to the clean target to remove all embedded libtinyxml source and header files.

I added "-Wl,--as-needed" to LDFLAGS (as recommend in section 9.1 of
libpkg-guide) and this has resolved those warnings.

--as-needed has some downsides though. Gentoo has some documentation about it:

http://www.gentoo.org/proj/en/qa/asneeded.xml

Fixed all warnings except for the following two informational tags:
I: presage: hyphen-used-as-minus-sign usr/share/man/man1/text2ngram.1.gz:7
I: libpresage1: no-symbols-control-file usr/lib/libpresage.so.1.1.1

Do I need to provide a symbols file for libpresage.so.1.1.1?

hyphen-used-as-minus-sign should be easy to fix.

Fixed.

If you think other source packages will link against libpresage1 then
you should definitely provide a symbols control file.

Yes, I'll work on getting this done too.

The issue here was caused by the fact that CDBS cleans out autotools before
cleaning out distutils. This results in make distclean running before python
setup.py clean --all. Because setup.py is generated by configure, it will be
removed by make distclean before python setup.py clean gets a chance to run.
Hence, the python build/ directory is left over. To fix this, I added a
clean target here to remove it explicitly. I wonder if there is a way to get
CDBS to get the python-distutils class to clean before the autotools class?

I have no idea, I prefer to avoid CDBS if at all possible. debhelper
7's dh is more compelling to me.

I've uploaded a new version of my presage package incorporating the fixes above. This package contains an additional change in the name of the -doc binary package, which has been renamed from presage-doc to libpresage-doc, to better reflect the fact that the -doc package contains documentation for the presage API, rather than documentation for users' applications.

- URL: http://mentors.debian.net/debian/pool/main/p/presage
- Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/p/presage/presage_0.8.3-3.dsc

I'm working on adding a patch to control the symbols exported by the shared library and add symbols versioning support. I'll upload a new version of my package when that's done.


Cheers,
- Matteo


Reply to: