On Wed, Dec 23, 2009 at 1:53 AM, Durk Talsma <d.tal...@xs4all.nl> wrote:
> Hi All, > > As we've discussed before, I'm working on merging the old ATC/AI code from > David Luff (ATCDCL) with our AIModels system. As part of the rewrite, I > have > added a new "--disable-atcdcl" option to my configure script. The default > behavior is that ATCDCL will be enabled. Disabling the build of this > library > currently results in a broken compile, because the alternate code isn't > ready > yet. > > Since the default behavior doesn't really affect the compile process, I'm > wondering whether there would be any objections to committing it to CVS. > I'm > asking, because I recently saw some patches being applied to ATCDCL, and I > don't want my development tree to get out of sync too much. I don't see any > obvious negative side effects, but this seems to my a case of better being > safe than sorry. :-) > Probably the biggest thing to worry about is if you introduce a new #define is the folks doing windows builds. Configure takes care of keeping everything consistent for unix builds, but depending on how this is done it could cause weird breakage for windows builds if the developers aren't aware they need to add a new define to their build environment. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/
------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
