Hi.... this is in an important issue so I'm going to bandstand for a bit. First off, let me preface this by saying that I am not terribly familiar with ac/am and therefore I am assuming, based on prior message traffic, that it does not support building under Microsoft or Borland compilers. If this is _not_ the case then I'll probably sound either opinionated, stupid or both. That said...
I think the answer is "not neccessarily". If ac/am is easier/preferable for the unix crowd _and_ the unix people are also willing to use (i.e. update) a system which supports both unix and windows compilers (i.e. CMake) then having an "unofficial" ac/am system which resides in the OpenGC repository is no problem. I'm willing to not enforce choice of a build system, however I must absolutely insist on the following: 1) A single, authoritative, copy of the OpenGC source exists in the repository, such that changes to the source are reflected in all build platforms on a per-change basis. At any given time, someone should be able to check out the latest CVS tree and compile it on their particular platform without having to immediately start hacking project or make files. 2) In accomplishing (1) we should not require developers to edit makefiles/project files for compilers they don't have. Linux users cannot modify windows project files at all, and for those of us weaned in Microsoft-land, modifying makefiles is not a fun thing to do. 3) In short, what I insist on avoiding is the following: a) I, working under Visual C++, create a new gauge, test, and commit it. I modify the repository's copy of the Visual Studio project to reflect this change. b) You, working under Linux, create a new gauge, test, and commit it. You modify the repository's copy of the makefiles to reflect this change. c) Person X comes along, checks out a clean copy of the CVS tree. Now we have a problem. Depending on their platform, they will see your changes or my changes, but not both. Best case is that they are simply missing a new piece of the code, and are missing functionality. Worst case is that it's impossible to compile either. Again, I'm making some assumptions about what am/ac can and cannot do. Also, since this project is open source, I can only "enforce" anything to the degree that people are willing to cooperate on making the project successful. Right now, active developers are primarily Unix/Flightgear people (with the sole exception of me). This may or may not be true over the lifespan of OpenGC, so it's important to adopt a build system early on which is truly cross-platform. Also - and this is not an insult in any way to Unix or Flightgear - the overwhelming majority of home cockpit builders are using Windows/FS200x. One of the goals of this project is to change that, but please understand that it's very important to keep the Windows version current (in sync with the repository), as it will likely have the largest audience for the near future. If am/ac works for you (and I mean this as you-plural), feel free to use it, and to upload it to the CVS repository. _However_, barring a better solution, I will be using CMake to generate Windows project files (and I encourage Unix users with no particular preference to use it as well), and I expect those who choose to use a different build system to update the relevant CMakeLists.txt files in order to ensure that there is _some_ way of having/maintaining an "authoritative" make environment. I hope this doesn't come across as being either arrogant or hard-nosed, but this is the sort of thing that can make or break a project. Comments are of course welcome.... -Damion- ----- Original Message ----- From: "Ross Golder" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, November 12, 2001 5:03 AM Subject: Re: [Flightgear-devel] OpenGC build process "from the horse's mouth" > On Sun, 2001-11-11 at 01:37, Damion Shelton wrote: > > > > Thanks for the feedback everyone - that's an impressive amount of message > > traffic! I've decided to go with the CMake build system from > > public.kitware.com/CMake - it uses a generic "makefile" (not unix format) > > syntax which is parsed by an executable (cmake) into makefiles for the > > various unix flavors and windows VC++ or Borland projects. It currently > > builds on (at least) the following Unix flavors: > > > > So does that mean you won't accept an autoconf/automake based build system? > > -- > Ross _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
