On Thu, Jul 7, 2011 at 12:58 AM, Chris Foster <[email protected]> wrote:
> On Thu, Jul 7, 2011 at 2:49 AM, Richard Shaw <[email protected]> wrote:
>> Some remaining issues:
>> 2. Right now I'm putting the libraries in /usr/lib{,64} which means I
>> need to run ldconfig. Is this the correct location
>
> Sounds right.
>
>> or would a named
>> subdirectory be more appropriate? (i.e. /usr/lib{,64}/OpenImageIO/)
>
> What is this usually used for? libOpenImageIO is intended to be linked
> against by the user, so having it out of the standard linker path
> doesn't seem right.
I guess they would be called private libraries for situations where
it's not expected that another program would link against them. It's
also sometimes done for libraries that have very generic library names
that another program might use. Doesn't look to be an issue in this
case.
>> 3. There's no man pages for the binaries. It's not an absolute
>> requirement for Fedora but it's *STRONGLY* recommend for any command
>> line program.
>
> From work that Larry just posted it looks like idiff, iinfo, iprocess,
> and possibly iconvert, maketx may dissappear in the near future, so I
> doubt there will be much interest in writing comprehensive docs for
> these right now. Would it be sufficient for a quick & dirty job to use
> txt2man on the --help output?
That should do it. The packaging guidelines only require that they exist.
In reviewing the build log I have some additional questions:
4. Would it be a lot of work to get a cmake option added to respect
either CMAKE_INSTALL_LIBDIR or LIB_INSTALL_DIR? This would get the
library in the proper location (/usr/lib{,64}) without having to
manually move them around.
Actually here's the output of the cmake command in the build log that
rpmbuild uses:
+ /usr/bin/cmake -DCMAKE_VERBOSE_MAKEFILE=ON
-DCMAKE_INSTALL_PREFIX:PATH=/usr
-DCMAKE_INSTALL_LIBDIR:PATH=/usr/lib64
-DINCLUDE_INSTALL_DIR:PATH=/usr/include
-DLIB_INSTALL_DIR:PATH=/usr/lib64 -DSYSCONF_INSTALL_DIR:PATH=/etc
-DSHARE_INSTALL_PREFIX:PATH=/usr/share -DLIB_SUFFIX=64
-DBUILD_SHARED_LIBS:BOOL=ON -DCMAKE_SKIP_RPATH:BOOL=TRUE ../src
The only two I'm adding is CMAKE_SKIP_RPATH and "../src". Everything
else is part of the macro.
5. Also, there's a non-critical error in the configuration. Here's the snippet:
"""
-- Looking for system HDF5
CMake Warning (dev) at /usr/share/cmake/Modules/FindHDF5.cmake:59 (include):
File /usr/share/cmake/Modules/FindHDF5.cmake includes
/builddir/build/BUILD/OpenImageIO-oiio-8055b0f/src/cmake/modules/SelectLibraryConfigurations.cmake
(found via CMAKE_MODULE_PATH) which shadows
/usr/share/cmake/Modules/SelectLibraryConfigurations.cmake. This may cause
errors later on .
Policy CMP0017 is not set: Prefer files from the CMake module directory
when including from there. Run "cmake --help-policy CMP0017" for policy
details. Use the cmake_policy command to set the policy and suppress this
warning.
Call Stack (most recent call first):
cmake/externalpackages.cmake:198 (find_package)
CMakeLists.txt:60 (include)
This warning is for project developers. Use -Wno-dev to suppress it.
"""
6. There are a number of warnings in the build but no errors. Is
anyone interested in reviewing them to see if they actually need to be
fixed?
What I did was to create a pseudo-index by grepping through the build
log for "warning" with line numbers since anyone looking into the
warning would probably need to see the lines above and/or below the
warning.
I can post both of those files online somewhere if anyone's interested.
7. On fedora we use a program called "rpmlint" which checks for the
most common packaging problems and also ones that are time consuming
or difficult to check. Here's the output:
$ rpmlint OpenImageIO-*.rpm
OpenImageIO.src: W: spelling-error %description -l en_US plugins ->
plug ins, plug-ins, plugging
OpenImageIO.src: W: invalid-url Source0:
OpenImageIO-oiio-Release-0.10.0-12-g8055b0f.tar.gz
OpenImageIO.x86_64: W: spelling-error %description -l en_US plugins ->
plug ins, plug-ins, plugging
OpenImageIO.x86_64: W: private-shared-object-provides
/usr/lib64/python2.7/site-packages/OpenImageIO.so
OpenImageIO.so()(64bit)
OpenImageIO.x86_64: W: no-manual-page-for-binary iinfo
OpenImageIO.x86_64: W: no-manual-page-for-binary maketx
OpenImageIO.x86_64: W: no-manual-page-for-binary idiff
OpenImageIO.x86_64: W: no-manual-page-for-binary iv
OpenImageIO.x86_64: W: no-manual-page-for-binary igrep
OpenImageIO.x86_64: W: no-manual-page-for-binary iprocess
OpenImageIO.x86_64: W: no-manual-page-for-binary iconvert
OpenImageIO-devel.x86_64: W: no-documentation
5 packages and 0 specfiles checked; 0 errors, 13 warnings.
Most of these can be ignored but I'm concerned about:
OpenImageIO.x86_64: W: private-shared-object-provides
/usr/lib64/python2.7/site-packages/OpenImageIO.so
OpenImageIO.so()(64bit)
The description of the error:
$ rpmlint -I private-shared-object-provides
private-shared-object-provides:
A shared object soname provides is provided by a file in a path from which
other packages should not directly load shared objects from. Such shared
objects should thus not be depended on and they should not result in provides
in the containing package. Get rid of the provides if appropriate, for
example by filtering it out during build. Note that in some cases this may
require disabling rpmbuild's internal dependency generator.
I'm not sure if this is rpmbuild being pedantic or is there's
something in the way the python library is built that causes this. I
may ask this question on the Fedora developer list as well.
Thanks,
Richard
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
