Hi Bertrand,
Here are a couple quick responses:
- The reason JSBSim would want to keep a copy of the glue code would be to
serve as an example for others who want to integrate JSBSim into their
projects.
- Changing the name of the glue code (I guess I missed seeing that this was
officially decided). But if I'm not mistaken, currently we have JSBSim.cxx
and JSBSim.cpp so that is also pretty confusing since they both produce a
JSBSim.o. It would make sense to call this FlightGear.cxx within the JSBSim
project, probably that's a less informative name within the FlightGear
source tree.
- 2 way patch patch propagation. Really the only important direction is for
us to merge JSBSim changes into FlightGear. Merging the glue code changes
back to the JSBSim project would simply be a courtesy to keep the example
code up to date and reduce the chance that some bug or poor way to handle
something is propagated to others (assuming we discover and fix something in
the glue code ourselves.)
Best regards,
Curt.
On Wed, Jan 26, 2011 at 1:53 PM, Bertrand Coconnier wrote:
> 2011/1/26 Erik Hofman <[email protected]>:
> >
> > After a bit of discussion it was decided that the FlightGear/JSBSim glue
> > code in JSBSim.[ch]xx located in FlightGear/src/FDM/JSBSim now is
> > maintained by FlightGear developers instead of by JSBSim developers and
> > therefore these files will not be overwritten in future updates.
>
> I don't know where this discussion took place so I may have missed the
> juicier bits. Then I apologize in advance if my questions have already
> been answered.
>
> > Instead they are now copied over to JSBSim instead to act as example
> code.
> >
>
> Given the decisions taken above, I don't understand why, in the first
> place, JSBSim should keep a copy of some code that will now be
> maintained elsewhere ? What is the plan ? Porting all patches from
> FlightGear to JSBSim's copy ? What for ? AFAICT JSBSim stand-alone
> executable is itself an example of how to integrate JSBSim library in
> an executable. And JSBSim.[ch]xx seems a fairly complicated chunk of
> code to serve as an example. For instance, JSBSim.cpp (the stand-alone
> executable) contains 635 lines of code while JSBSim.cxx (the glue
> code) contains 1413 lines of code.
>
> Even though, why the name of the Flight Gear glue code has been
> changed from JSBSim.[ch]xx to FlightGear.[ch]xx in JSBSim ? Now we
> have 2 copies of the same source code with 2 different file names.
> What is the point of this renaming ? Is it not confusing ?
>
> 2011/1/26 Erik Hofman <[email protected]>:
> > On Wed, 2011-01-26 at 07:19 -0600, Jon S. Berndt wrote:
> >
> >> I have received and applied patches from several places recently. Make
> sure
> >> that patches are not accidentally reversed.
> >
> > They won't since the patches at the FlightGear side will be overwritten
> > by what JSBSim had in CVS.
>
> Unless I am mistaken, the plan is now to have a 2-way code exchange
> between FlightGear and JSBSim :
> FG => JSBSim for JSBSim.[ch]xx/FlightGear.[ch]xx
> JSBSim => FG for other JSBSim files.
>
> Who will make sure that those files are always in a consistent state ?
>
> Let's take an example : let's say I develop some code for JSBSim to
> take into account FG ground material in the landing gears friction
> forces. For that, I need to modify both JSBSim library *and*
> FlightGear glue code. So I will submit a patch to JSBSim (for the
> friction calcs) and another patch to FlightGear (to give JSBSim access
> to FG material data). The patch for FG glue code cannot be applied
> readily : first JSBSim needs to be patched and then copied in
> FlightGear (or otherwise FG compilation will fail). Once JSBSim last
> revision is copied in FlightGear the second part of the patch must be
> committed immediately in FlightGear (otherwise FG compilation will
> fail). And then the patched glue code will be copied back in JSBSim.
> Notice that the patch can be applied at any moment in JSBSim, even 1
> month or 1 year after its submission. On the other hand, some tight
> synchronization is needed on the FlightGear side if you don't want FG
> compilation to break. Do you think such a process is sustainable ? I
> don't.
>
> Cheers,
>
> Bertrand.
>
>
> ------------------------------------------------------------------------------
> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> Finally, a world-class log management solution at an even better
> price-free!
> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
> February 28th, so secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsight-sfd2d
> _______________________________________________
> Flightgear-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>
--
Curtis Olson:
http://www.atiak.com - http://aem.umn.edu/~uav/
http://www.flightgear.org -
http://www.flightgear.org/blogs/category/curt/<http://www.flightgear.org/blogs/category/personal/curt/>
------------------------------------------------------------------------------
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d
_______________________________________________
Flightgear-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
