[Pkg-osg-devel] Bug: #690878 "pkg-config reports wrong path"

[Manuel A. Fernandez Montecelo]

2012/11/22 Alberto Luaces <aluaces at udc.es>:
>> Failed to build again, it looks like ~7GB isn't enough... will have to
>> make more room to compile or try to grab the beefier machine soon.
>
> Yes, looking at the build tree it says
>
> $ du -sm
> 8079

I have tried with the other machine, and it built fine.  Diff attached
(I commited to VCS anyway).  Since release managers approved with
those changes enabled, I will go ahead later, but if you have the
opportunity confirm that it's OK in the meantime, please do.


> Nevertheless, I am starting to be worried about the size of the overall
> project.  I don't know if it is really worth to have the static version
> of the library.  It doubles build times and space requirements.
> Furthermore, it is typically aimed at developers, and popcon results
> show that OSG is mainly used as a dependency for other projects and not
> for developing.  If at least the static build were complex, its
> usefulness could be proven, but experience tells me that usually
> developers are compiling their own versions from the SVN upstream
> anyway.
>
> I had an idea of making a separate package for the static libraries in
> order to have popcon results saying what it real impact is, but now I
> just think that we could skip the burden of asking for permission to the
> ftp masters in order to create a new package and just not build them.
> Therefore debian/rules could be as small and lean as those other project
> of yours, pruning all that casuistic code that plagues the current
> version.

I am not sure about the usefulness of the static libraries.  In OGRE I
had requests, but since upstream don't recommend it, it's easy for me
to dismiss the request :-)

I don't know about Loic, but I don't have much experience with the OSG
community, so whatever you decide I'm fine with it.  We can drop the
static library just after the release and see the amount of complaints
that it generates, and decide after that.

Or we can implement an option in rules, so people can easily build the
static version if they set that option, but it's not built that way by
default (similar to noopt, nostrip, etc).

About space used, I noticed a strange trend:
https://buildd.debian.org/status/logs.php?pkg=openscenegraph&arch=armel
https://buildd.debian.org/status/logs.php?pkg=openscenegraph&arch=i386
https://buildd.debian.org/status/logs.php?pkg=openscenegraph&arch=ia64
https://buildd.debian.org/status/logs.php?pkg=openscenegraph&arch=kfreebsd-amd64

In all of these architectures (no data for amd64 since the binary that
we upload is used; and I can't bother to check all the rest), there's
a dramatic drop from 3.0.1-1 to -2, to just 10% of the previous 3.*
releases.  I don't know what change triggered that, and I don't know
why we need 7-8GB again, didn't look very much to it, but maybe it's
because some of our C[XX]FLAGS settings overriding other OSG or CMake
defaults.

I think that removing static could be a pragmatic measure in that
sense, if static is of not much use for most people, and will also not
make impossible the use of ccache (which I wished for very much in the
last few days :-) ).


Cheers.
-- 
Manuel A. Fernandez Montecelo <manuel.montezelo at gmail.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: debdiff_openscenegraph-3.0.1-3_to_-4.diff
Type: application/octet-stream
Size: 4288 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-osg-devel/attachments/20121122/80c42e15/attachment.obj>