From: Curtis O. <cur...@gm...> - 2011-10-17 17:38:49
|
Hi James, One thing that stresses me out is large scale technology changes with no documentation or howto's to back them up. This change might be fine for people who are cmake experts. And I know anyone can start from scratch and read the cmake manual from cover to cover. But that takes time and a lot of effort, and there is not enough time in our lives to be experts in everything, but we often need to know some basics in just about every subject. Judging by the number of tweaks and changes I see through the change logs that are cmake config related only, there is a lot of subtle nuance and expertise required to make cmake do the equivalent of autoconf/automake (and the auto tools required a lot of expertise too.) Would it be possible to write a quick "howto" for doing some basic coding/developer things in cmake. Like: "how to add a new source file to the project." Or "how to add a new module/library to the project". Maybe a few quick summeries of "how to install in a custom directory", how to build with custom compiler options, how to configure for debug vs. release build, or some the more subtle build options that invoke different levels of optimizations or warnings. Either that, or our cmake experts need to be willing and ready to respond to frustrated "dumb" questions in a timely manner -- and do that over time if we don't have central place to find this information without investing the required time to become cmake experts ourselves. Thanks! Curt. On Mon, Oct 17, 2011 at 12:10 PM, James Turner wrote: > It's been a month since I announced the intention, to switch all the main > FG platforms to use CMake, and to deprecate and remove the other build > systems from Git. There's been many small improvements in the Cmake files > since then, which I hope have eased some people's concerns about the switch. > > (Notably Brisa' compile scripts have been updated to use Cmake!) > > I still have some work to do, to ensure the 'make dist' rules are handled > property in CMake, so we don't get a shock when releasing FG 2.6 in a few > months. > > Are there are any other issues people have, areas they think should be > tested, etc? I'd love to know the status of cygwin and mingw, but only > people who run those environments can test or improve them. > > Barring last minute surprises, my intention is to declare the other build > systems 'dead' next weekend (the 21st), and then gradually start disabling > Jenkins jobs, removing files, and so on. The idea is to force everyone who > runs FG from Git, to definitely be testing and using CMake, in plenty of > time for the 2.6 release. > > Regards, > James > > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2d-oct > _______________________________________________ > Flightgear-devel mailing list > Fli...@li... > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org |