Am Donnerstag 24 Mai 2007 schrieb jeremy rosen: > * it's not GPL (might be GPL-compatible, but I havn't checked)
It is compatible and used by other (L)GPL projects like OpenOffice.org The license is like that für libstdc++ - the goal is to be usable by everyone. > * any thought from our tiny-GUI guys ? how large is boost ? what mem > requirements does it have... Tiny GUI is about small screens and I can't imagine that the memory usage of boost will add much to that of Wesnoth itself. > * it seems to provide the same type of functionalities than SDL... Boost is to C++ what CPAN is to Perl just with much higher quality requirements. It got founded by members of the C++ standard comitee and its primary goal is to explore usefull additions to C++ which could enter newer versions of the standard. > * I couldn't find anything about portability, this has probably been > looked into bug just to be sure > ** linux > ** macosX > ** windows/mingw > ** windows/gcc > ** windows/msvc++ Those are all supported. > ** amigaOS > I am particularly concerned about Amiga OS. I regularly receive > patches from these guys because their OS seems to have a very special > way of handling files... We should be carefull to break their builds > as little as possible, if only by respect for thoses that do look into > our code and review it... Actually I'm rather little concerned about them. They're are a very small community and we shouldn't let restrictions of those block Wesnoth. Of course we should always try to keep it easy for them to add #ifdef variants supporting their needs. If they have GCC in a recent version there should be litttle problems for them from boost. > * Long: well, with the breakage of the Editor, we can either release > 1.3.3 with a known broken editor or postpone it for long, so if the > breakage is minor, let's release with the known bug and integrate > boost after. If it's long, well, let's admit it and start integrating > right away, knowing that it's going to be long.... I think we should try to get out 1.3.3 first before we do such a change. > * Delicate: in the past big changes like that, especially the ones > that affect the build system have broken SVN for some quite long > periods, so if we go for it, it might be a good idea to do it on a > separate branch... if only to avoid blocking other developements... This is a much smaller change. We're adding a library and replacing some of Wesnoths code by it. I don't see anything very hard about that. Boost is already present in all major distributions AFAIK. Bye David PS: from http://www.boost.org/more/lib_guide.htm License requirements The preferred way to meet the license requirements is to use the Boost Software License. See license information. If for any reason you do not intend to use the Boost Software License, please discuss the issues on the Boost developers mailing list first. The license requirements: * Must be simple to read and understand. * Must grant permission without fee to copy, use and modify the software for any use (commercial and non-commercial). * Must require that the license appear on all copies of the software source code. * Must not require that the license appear with executables or other binary uses of the library. * Must not require that the source code be available for execution or other binary uses of the library. * May restrict the use of the name and description of the library to the standard version found on the Boost web site. Portability requirements * A library's interface must portable and not restricted to a particular compiler or operating system. * A library's implementation must if possible be portable and not restricted to a particular compiler or operating system. If a portable implementation is not possible, non-portable constructions are acceptable if reasonably easy to port to other environments, and implementations are provided for at least two popular operating systems (such as UNIX and Windows). * There is no requirement that a library run on C++ compilers which do not conform to the ISO standard. * There is no requirement that a library run on any particular C++ compiler. Boost contributors often try to ensure their libraries work with popular compilers. The boost/config.hpp configuration header is the preferred mechanism for working around compiler deficiencies. Since there is no absolute way to prove portability, many boost submissions demonstrate practical portability by compiling and executing correctly with two different C++ compilers, often under different operating systems. Otherwise reviewers may disbelieve that porting is in fact practical. _______________________________________________ Wesnoth-dev mailing list [email protected] https://mail.gna.org/listinfo/wesnoth-dev
