On 7/26/07, Craig Ringer <[EMAIL PROTECTED]> wrote: > P Linnell wrote: > > Hi, > > > > I've got the beginnings of a workable cross-platform spec file in the > > works for Suse's Build Server. > > > > Some questions and comments: > > > > 1) What does adding STL port add and should it be a BuildRequires for > > Linux/Unix ? > > I integrated STLPort support so that people could use it on platforms > with ancient or broken C++ libraries. > > STLPort support is also useful if the project that uses PoDoFo wishes to > use STLPort themselves. Since PoDoFo presents a public C++ API it must > use the same C++ libraries as the other components in the executable. > > It can also be handy to build a debug STLPort since it can check for use > of invalid iterators, etc (like Visual Studio's debug STL, but portable). > > It is unnecessary and unwise to build PoDoFo against STLPort on any > current major platform unless you have a specific reason to do so. Avoid > doing so for packages. I'll annotate the documentation to that effect.
OK. Good to know. Thanks for the explanation. > > > 2) There are no make uninstall targets. > > My bad. I'll try to sort that out shortly. `make uninstall' is something > I never use and that I distrust - and since I install into specific > prefixes for any dev work it never matters. Nonetheless, I'm sure it's > useful for others and for packaging so I'll have to make sure it works. > > > 3) I'm finding that paths are hardwired and without relative paths in > > an rpm build root, install tries to install to the real /usr/lib /etc > > if prefix is used. > > Interesting. I imagine I can examine how that was addressed in Scribus > to see a good approach to that issue. > > > 4) There needs to be a lib64 install option. We sorted this in Scribus > > 1.3.5svn recently. IRC might be easiest to discuss the gory details. > > Good point. I'll try to drop in and catch you over the next week or so. > I'm moving house at the moment though (same mobile number if you need to > reach me urgently) so I'm not too sure exactly when. > > > Once I'm happy with it you can have the spec file for commiting to svn. > > That's be brilliant. > > I would like to stress, though, that PoDoFo is _NOT_ API or ABI stable > from release to release. It's important that people using packaged > versions understand that, and it means that it might be necessary to > support the installation of multiple versions in parallel. It is > guaranteed that the soname will change with every release (since > compatibility is broken) but I'm not entirely sure about the best way to > handle the headers. > > -- > Craig Ringer > Yep, I am well aware of API and ABI stability. My interest is being able to support building podofobrowser which rpm fortunately will automatically pickup soname dependencies. Moreover with the browser I can force the depenency with a Requires: libpodofo-%version so newer versions of the lib will not support older browsers. I've managed to coerce Mandriva 2007.0, Suse 10.2+ and Fedora 6.+ to build podofo on the build server for 32 bit and podofobrowser for Suse 10.2+ so far. Getting the BuildRequires for Qt4 is finicky cross platform. The adventurous can grab from here: http://download.opensuse.org/repositories/home:/mrdocs/ Cheers, Peter ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Podofo-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/podofo-users
