On 2011/07/09 10:53, Piotr Sikora wrote:
> Hi,
> 
> >>SHARED_ONLY =           Yes
> >these should be removed, there's a perfectly good static lib,
> 
> Honestly, I was always confused by this... What is the proper way of
> figuring out if library should be SHARED_ONLY or not?

If something relies on using dlopen() to load modules or something
similar, then it's SHARED_ONLY. We also sometimes set it on things
which aren't strictly SHARED_ONLY themselves but they depend on
something else which *is* SHARED_ONLY to save a bit of time in
bulk builds.

Here, we have the .so file but also a .a which can be linked
statically, so the port is still useful on a static-only arch.

> >>USE_GMAKE =             Yes
> >and it works fine with normal make.
> 
> Oops, too much copy & paste, sorry.

:)

> >>CONFIGURE_ARGS +=       ${CONFIGURE_SHARED} \
> >>                        --disable-gtest \
> >
> >gtest should just be a standard BUILD_DEPENDS, it's only a single
> >package with no deps, and small enough, so there's no point in
> >REGRESS_FLAGS hacks and a patch which are only there to reduce the
> >build depends. I've left gflags disabled as it doesn't seem to
> >add much to the port/tests.
> 
> I had this originally, but I assumed that port with surplus
> BUILD_DEPENDS wouldn't stand a chance of getting in.

The preferred method for installing things is from packages,
where BUILD_DEPENDS aren't a problem at all. If I have a port with
a heavy set of optional build dependencies then I'd consider
what value they bring, if it's a port that people might build
themselves more often than normal (e.g. if it gets lots of
security updates) I'd be a bit more aggressive about trimming
them down, but I normally wouldn't see any need for this.

> >updated tgz attached. any OKs to import?
> 
> All the changes look alright, but obviously I cannot give you OK ;)
> 
> Thanks for super-fast response on this!

I started looking at this myself a few days ago in case it
might be any use for hibernate support (then I spotted it was
C++ and figured probably not) so I had half a port in my
tree already ;-)

(For anyone interested in this stuff, there's also a fast
compression library written in C under MIT license,
http://www.fastlz.org/)

Reply via email to