On Mon, 2001-11-12 at 18:36, Damion Shelton wrote: > 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 maintain the auto* tools, which will make life easier for unix people. However, I cannot promise to maintain CMake files, as I do wish to install CMake on my machine, or invest any time learning it, as it is not adopted widely enough for me to consider it worthwhile.
> 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. > CVS commits which require build system updates (e.g. new source file) should be notified to the list so that users of whichever system the committer didn't update in his testing get a chance to update and test their system. All this would happen on both sides before releases anyway, so this really shouldn't be a problem to non-developer users. > 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. > All this would be taken care of, as long as changes are communicated between developers on the mailling list. > 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. > Truly cross-platform build systems are many and varied, and there doesn't appear to be a reasonable consensus within the open source community, so at the moment, in most cases, things are broken down into build-system-per-platform. Most projects I check out that don't have some kind of auto* build system usually present some kind of problem, as the developers have made assumptions about library locations/versions their build scripts are expecting to find. Exceptions to this rule are larger projects like Sendmail and Apache, which have large enough user bases to cater for the plethora of platforms and configurations out there. > 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. > Thanks for your endorsement. Looking at the format of the CMakeLists.txt file, it should be fairly straightforward for developers to add new widgets/whatever, even if they do not have CMake installed to test their changes (hence they should tell the list, and leave it to someone who can test before committing). Hopefully, I'll be in a position to look a bit closer at the OpenGC auto* support soon. I've been stalled a bit by having a fried CPU on my main FlightGear workstation, which I've still not fixed. I've been working from my laptop for last two weeks, which doesn't do 3D so well. -- Ross _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
