From: Ian S. <ian...@st...> - 2006-10-09 08:36:42
|
You mention wanting to use BGL. Where do you want to use it? in contrib? your own private code? in core? Are there any other reasons in favour of importing BOOST into VXL? Several reasons against have been aired below. Additionally I would add 1. BOOST's build system is not CMake, and rewriting it in CMake would be a lot of effort. 2. Nothing in vxl/core currently needs any of BOOST's functionality. I am familiar with many of these arguments against importing 3rd party libraries in VXL. I'd be grateful if you could explain your needs, and the other reasons in favour of importing the code. Ian. Miguel A. Figueroa-Villanueva wrote: > On 10/7/06, Gehua Yang <ya...@rp...> wrote: >>> Gehua Yang wrote: >>>> I am thinking about the possibility of importing BOOST into VXL, >>>> possibly in V3P. It may be treated as Level 1 (so as not to contaminate >>>> the Level 1 core libraries). >>>> >>>> This issues was brought up once in the mailing list (see >>>> >>> http://sourceforge.net/search/?type_of_search=mlists&group_id=24293&words= >>> boost). >>>> But no conclusion was drawn. It seemed people liked the functionality >>>> of BOOST, but worried about its compatibility with broken compilers such >>>> as VC6. Now that we have dropped the support for broken compilers, it >>>> is time to revisit this issue. >>>> >>>> For those who have experienced with BOOST and possibly used it with >>>> VXL, please comment on BOOST's functionality, stability, and possible >>>> issues if we are going to import it into VXL. >>> FYI, the boost source tree is larger than the entire vxl tree. Just the >>> header-only part of boost is about half vxl's current size. >>> >>> -Brad >>> >> Thanks for pointing it out. Personally, I am interested in the Boost Graph >> Lib (BGL). Others, such as the serialization lib, may have potential use. >> I am looking for a consistent way to start importing BOOST libraries. >> >> Gehua >> > > I asked this question on the list a while ago and my conclusion (and > please correct me if I'm wrong) was that BOOST wholesale would be > quite a maintenance burden (as Brad points out). If it is for use in > contrib, finding BOOST with a FIND_PACKAGE cmake module might be a > better approach. If it is for use in core, then it should be > VXL'ified. I think that there is quite some interest in limited > portions of BOOST, so this would be a nice thing to do. Of course, for > those limited parts of BOOST. > > To VXL'ify a particular piece of BOOST, for example vbl_shared_ptr, I > initially thought that a typedef approach like we use in vcl or a > wrapper to a vbl/internals/boost::shared_ptr would make sense and make > it easier to import. I haven't given this much further thought though. > It is important to note that some of these things might make it to the > standard in the future, so making it easy to replace vbl_shared_ptr to > vcl_shared_ptr would be ideal. > > Just my two cents on the topic. > > --Miguel > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers |