after a quick look at the website... * it's not GPL (might be GPL-compatible, but I havn't checked) * any thought from our tiny-GUI guys ? how large is boost ? what mem requirements does it have... * it seems to provide the same type of functionalities than SDL... * 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++ ** 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... Last, including a new library is a long and delicate process * 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.... * 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... Regard Boucman On 5/24/07, David Philippi <[EMAIL PROTECTED]> wrote: > Am Donnerstag 24 Mai 2007 schrieb Eric S. Raymond: > > Ivanovic, myself, alink, and allefant have all been whacking at this > > problem but have failed to solve it. There is a suggestion on the > > table that we ought to drop a nuke on the problem by linking the > > Boost filesystem library and using its directory-traversal primitives, > > which whould at least simplify the code path. > > Using Boost just for the filesystem would be a nuke, but if we subsequently > encourage developers to use more parts of it in other areas of the code this > doesn't hold anymore. :-) > Personally I think that while many dependencys are bad, depending on a few > well known and maintained libs is better then to duplicate the code > everywhere. > > Bye David > > _______________________________________________ > Wesnoth-dev mailing list > [email protected] > https://mail.gna.org/listinfo/wesnoth-dev > _______________________________________________ Wesnoth-dev mailing list [email protected] https://mail.gna.org/listinfo/wesnoth-dev
