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
> Flightgear-devel@lists.sourceforge.net
> 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
------------------------------------------------------------------------------
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
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
