Re: RFS: presage
On Sat, Jun 19, 2010 at 6:06 AM, Matteo Vescovi
> 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?
You could send tinyxml upstream a patch to build shared libraries,
based on the tinyxml debian/rules file:
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.
> 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:
> 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.
If you think other source packages will link against libpresage1 then
you should definitely provide a symbols control file.
> 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.