Re: [Flightgear-devel] Joystick support code location

[Curtis O. <cur...@fl...>]

Rolling the portions of plib that we still use into our own code base is a
topic worth discussing.  With a small bit of thought, I don't see a
downside.  Plib development/support ended long ago.  If anyone new ever did
pick up plib again, and begin actively developing it, there's no telling if
the new effort would have flightgear in mind.  The original purpose of plib
was to create platform independent libraries for a number of the things
that software such as flightgear needs ... things like asyncronous socket
servers, joystick input, a simple gui that runs on top of the opengl
graphics layer, etc.  Many of these things have better replacements
available today.  When we started FlightGear there wasn't a platform
independent gui library that married nicely with opengl ... maybe now qt
offers a reasonable answer for that.  (Totally as an aside: as I learn more
about python for other projects, I see much of the functionality of plib
and simgear provided by python system libraries ... meaning the python
world has traveled a parallel path in many ways.  I just discovered an
exact work alike for plib's netChat/netChannel with python's async library
... but FlightGear needed these things going back to the late 90's and
early 2000's, we needed these in C/C++, and we needed them to work on all
the platforms we supported.  Thus we had to develop many of these things
ourselves, or depend on libraries like plib which were developed
concurrently with early FlightGear.)

For one of my own projects I actually did roll a couple plib source files
right into my own code base (and statically linked that code into the main
binary) ... I hadn't considered that for FlightGear, but I think we could
make a compelling case for taking that action.  We should make sure we
don't duplicate any of the original plib library names (just to be on the
safe side.)  Originally plib was careful to discourage
building/packaging/distributing itself as a shared library, and I
discourage building simgear as shared libraries ... but I recognize that
some people choose to build this way.  I think as long as we don't
duplicate library names, we wouldn't introduce any problems by rolling the
plib code into the flightgear/simgear code base.  Beyond that in eliminates
an external dependency and makes our code more self contained.

Those are my thoughts ...

Thanks,

Curt.

On Wed, Mar 9, 2016 at 12:27 PM James Turner <zak...@ma...> wrote:

> Hello,
>
> We have an issue with the PLIB joystick support code, that we can’t bugfix
> it since PLIB is a fossil.
>
> I have a change, to move the JS code into FlightGear, so we can apply
> fixes. Longer term we might replace this code entirely (with the EventInput
> system, although this didn’t get much work recently, and lacks Windows
> support).
>
> Are there any objections to, or downsides, to moving the PLIB-JS code into
> src/Input, and then being able to apply fixes?
>
> Another option is to move /all/ the remaining pieces of PLIB we use
> (actually just FNT, PUI and JS) into 3rdparty, and drop our dependency on
> external PLIB. This would fractionally simplify some build issues, but I
> wonder if we would encounter the issue of distribution maintainers wanting
> to use the system version, even if our local fork has bug-fixes applied. As
> ever, I am not a Linux user so don’t know what is good practice here.
>
> Kind regards,
> James
>
>
>
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140
> _______________________________________________
> Flightgear-devel mailing list
> Fli...@li...
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>