On Thu, 31 Oct 2013 14:39:21 -0400
Brian Hinz <bph...@users.sourceforge.net> wrote:

> I don't follow you here.  By "normal" do you mean foregoing the advanced
> features of the viewer that depend on the patched fltk and dynamically
> linking against the distribution supplied libfltk.so?  Short of replacing
> the system libfltk.so, I don't see a reasonable way to build a dynamically
> linked viewer with all the bells and whistles.

I've been suffering from a cold so my ramblings might be more
incoherent than usual. :)

By "normal" I mean dynamical linking. I.e. the way a distribution would
build things if they would include it themselves.

For a user that needs to replace a system libfltk.so that could pose
problems, yes. It is solvable through various means though. But I see
that as an exception, not the rule, for a multitude of reasons. That's
why I've always made the sure we can build against a standard FLTK. I
also hope if will soon be a solved problem (see below).

> I think that most people that have chosen to incorporate the patched fltk
> would link it statically, and in order to make anything portable
> (particularly for platforms that don't natively have fltk) you pretty much
> have to.  I don't have any dogmatic objections to building against the
> patched fltk, I think the features are well worth the overhead.  It's
> unfortunate that Fltk has not accepted so many of these patches after all
> this time and I'm not sure what needs to happen before they will.

Their problem is a lack of resources. Fortunately I have been given
commit rights to FLTK so I'm trying to get everything upstream as
quickly as I can. My hope is that by the time we make our next release
we can depend on an unpatched FLTK.

> So here's my suggestion:
> Add a 'contrib' directory to the trunk and in it keep a copy of not only
> the most current build recipes, but also distribution-specific packaging
> scripts, patches, etc.  I know that there is already a buildscripts
> directory, we could alternatively update that but I would like to see it
> under the trunk for packaging convenience.  This at least archives the
> patches that are necessary to build on certain platforms and provides some
> additional templates for people that wish to build from source.  I'm OK
> with taking responsibility for this if no one objects.

Sounds good.

Pierre Ossman           Software Development
Cendio AB               http://cendio.com
Teknikringen 8          http://twitter.com/ThinLinc
583 30 Linköping        http://facebook.com/ThinLinc
Phone: +46-13-214600    http://plus.google.com/112509906846170010689

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

Attachment: signature.asc
Description: PGP signature

Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
Tigervnc-devel mailing list

Reply via email to