May 2009 - Boost - lists.preview.boost.org

Re: [boost] [BCP] Script for global renaming Boost Namespace
by Artyom 30 May '09

30 May '09

Hello, > I > think there is interest for such a feature, especially if > you are willing to > maintain it on regular basis. If there is an interest in it and, it would be accepted I'd be glad to continue supporting it on regular basis. Probably it may be integreted with regeression test to ensure that Boost still works after renaming. > If we do expect all > possible users to have Python > installed, it may be nice to use python for this. But > how do you propose to > integrate with bcp? 1. First of all this script is "one time use" and it is targeted for mostly project maintainers/managers that need to solve name collision problems. So, if it is not a big price to install Python to run such script, especially that it is availible by default for most supported platforms, like Solaris, FreeBSD, Linux, with an exception of Windows where in can be easily installed. So I don't see a real problem in using Python for this purpose. In any case there are already some Perl scripts are used for code generation. (See Boost.Asio for example) 2. I don't see it as a part of BCP but rather the tool that can be used together, like: bcp --boost=/path/to/boost bind.hpp regex asio my_boost_dir boost_rename.py my_boost_dir mybst Because it can be actually applied on full Boost tree, if someone wants its full version. Artyom > -- > Bjørn Roald > > > On Saturday 30 May 2009 10:55:25 am Artyom wrote: > > Hello, > > > > Some updates: > > ------------- > > > > 1. Added copyright - Boost License. > > 2. Some more regression tests passed, some code > cleanup > > > > Questions: > > ---------- > > > > 1. How can I submit it as an addon to BCP utility? > > 2. Have anybody tested it, I'd like to see if there > any problems, > > especially on Windows platform -- I > hadn't tested it there. > > > > > > Thanks > > Artyom > > > > P.S.: The source is there http://art-blog.no-ip.info/files/rename.py > > > > --- On Mon, 5/25/09, Artyom <artyomtnk(a)yahoo.com> > wrote: > > > From: Artyom <artyomtnk(a)yahoo.com> > > > Subject: [BCP] Script for global renaming Boost > Namespace > > > To: boost(a)lists.boost.org > > > Date: Monday, May 25, 2009, 11:14 AM > > > Hello, > > > > > > Today Boost does not provide any backward binary > > > compatibility. This > > > makes big problems in shipping 3rd part libraries > that > > > depend on Boost > > > because library user must use the same version of > Boost as > > > that 3rd > > > part library was compiled with. > > > > > > The problem is become even more critical for ELF > platforms > > > (UNIXes) > > > where all symbols are exported by default. > > > > > > I had written a small Python script that switches > boost > > > namespace > > > to other, allowing 3rd part project include it > without > > > collisions > > > with primary Boost namespace. > > > > > > The script passes over the source tree of boost > and changes > > > each > > > include path from <boost/foo/bar.hpp> too > > > <newnamespace/foo/bar.hpp> > > > and renames all macros and identifiers from > > > some_BOOST_something to > > > some_NEWNAMESPACE_something and > some_boost_something to > > > some_newnamespace_something. > > > > > > It does not touch comments (copyright) and > strings unless > > > the string > > > is in form "boost/.*" which is usually some > reference for > > > include. > > > > > > I've run this script on the 1.39 version of boost > and > > > successfully build full boost release and run > some of > > > regression tests > > > like Boost.Asio, Boost.Regex, Boost.Function and > others, > > > > > > The source code is available at: > > > http://art-blog.no-ip.info/files/rename.py > > > > > > You run it as: > > > > > > ./rename /path/to/boost/source > > > new_namespace_name > > > > > > It renames all macros and namespaces to new > namespace, and > > > renames > > > main include directory to new_namespace_na,e. > > > > > > Few points: > > > > > > 1. It is only alpha version script, I just want > to see > > > feedback and > > > proposals > > > 2. I do not update build scripts. I assume that > each > > > library that > > > tryes to import its own version of > Boost > > > would provide its own > > > build system. > > > 3. The build scripts should be updated > differently because > > > they have > > > different syntax and grammar. The > > > required changes are to > > > fix different build defines > > > > > > Please, give feedback proposal. If there someone > who is > > > familiar > > > with Boost.Build systems can actually help, this > would be > > > very good. > > > > > > Today there is a big problem with working with > different > > > versions of > > > Boost. It should be solved. > > > > > > I think this script may be a valuable addition > to > > > Boost.BCP utility > > > that allows extracting a subset of boost for > integration in > > > 3rd part > > > tools and libraries. > > > > > > Thanks, > > > Artyom > > > > > > > > > > > > > _______________________________________________ > > Unsubscribe & other changes: > > http://lists.boost.org/mailman/listinfo.cgi/boost > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost >

2 1

mingw help
by Vladimir Prus 30 May '09

30 May '09

We have two issues: https://svn.boost.org/trac/boost/ticket/1907 https://svn.boost.org/trac/boost/ticket/2181 that claim the the names of library files on mingw are wrong. Unfortunately, the picture is not exactly clear, and it's not even clear what the right naming would be. I'd appreciate if somebody who actually uses mingw could clarify these points: 1. Currently, we use the same naming on mingw as on windows -- foo.dll and foo.lib for shared libs and import libs, and libfoo.lib for static library. Is this OK? 2. Are the search rules listed in tools/build/v2/tools/gcc.jam around line 657 matching the reality? 3. Is naming in (1) compatible with using -Bstatic to request static libs? Thanks, Volodya

3 4

Re: [boost] [BCP] Script for global renaming Boost Namespace
by Artyom 30 May '09

30 May '09

Hello, Some updates: ------------- 1. Added copyright - Boost License. 2. Some more regression tests passed, some code cleanup Questions: ---------- 1. How can I submit it as an addon to BCP utility? 2. Have anybody tested it, I'd like to see if there any problems, especially on Windows platform -- I hadn't tested it there. Thanks Artyom P.S.: The source is there http://art-blog.no-ip.info/files/rename.py --- On Mon, 5/25/09, Artyom <artyomtnk(a)yahoo.com> wrote: > From: Artyom <artyomtnk(a)yahoo.com> > Subject: [BCP] Script for global renaming Boost Namespace > To: boost(a)lists.boost.org > Date: Monday, May 25, 2009, 11:14 AM > Hello, > > Today Boost does not provide any backward binary > compatibility. This > makes big problems in shipping 3rd part libraries that > depend on Boost > because library user must use the same version of Boost as > that 3rd > part library was compiled with. > > The problem is become even more critical for ELF platforms > (UNIXes) > where all symbols are exported by default. > > I had written a small Python script that switches boost > namespace > to other, allowing 3rd part project include it without > collisions > with primary Boost namespace. > > The script passes over the source tree of boost and changes > each > include path from <boost/foo/bar.hpp> too > <newnamespace/foo/bar.hpp> > and renames all macros and identifiers from > some_BOOST_something to > some_NEWNAMESPACE_something and some_boost_something to > some_newnamespace_something. > > It does not touch comments (copyright) and strings unless > the string > is in form "boost/.*" which is usually some reference for > include. > > I've run this script on the 1.39 version of boost and > successfully build full boost release and run some of > regression tests > like Boost.Asio, Boost.Regex, Boost.Function and others, > > The source code is available at: > http://art-blog.no-ip.info/files/rename.py > > You run it as: > > ./rename /path/to/boost/source > new_namespace_name > > It renames all macros and namespaces to new namespace, and > renames > main include directory to new_namespace_na,e. > > Few points: > > 1. It is only alpha version script, I just want to see > feedback and > proposals > 2. I do not update build scripts. I assume that each > library that > tryes to import its own version of Boost > would provide its own > build system. > 3. The build scripts should be updated differently because > they have > different syntax and grammar. The > required changes are to > fix different build defines > > Please, give feedback proposal. If there someone who is > familiar > with Boost.Build systems can actually help, this would be > very good. > > Today there is a big problem with working with different > versions of > Boost. It should be solved. > > I think this script may be a valuable addition to > Boost.BCP utility > that allows extracting a subset of boost for integration in > 3rd part > tools and libraries. > > Thanks, > Artyom > > > >

2 1

[Conversion] Looking for a review manager
by vicente.botet 30 May '09

30 May '09

Hi there, I'm looking for a review manager for the new Conversion library. Anyone around here who would like to volunteer? "Generic explicit conversion between unrelated types: generic convert to and assign to functions which can be specialized by the user to make explicit conversion between unrelated types + partial specialization for std::complex, std::pair, boost::optional, boost::rational, boost::interval and between boost::chrono::time point and boost::ptime and between boost::chrono::duration and boost::time duration" Waiting for that any comments on the library is welcome. You can retrieve it from https://svn.boost.org/trac/boost/wiki/LibrariesUnderConstruction#Boost.Conv… Regards, _____________________ Vicente Juan Botet Escribá

1 0

[Regex] build bug: Makefiles contain old version number (1.38 vs 1.39)
by Harald Csaszar 30 May '09

30 May '09

Hi, It seems as if the regex library makefiles have not been updated in the 1.39 release. Files like <boost>/libs/regex/build/gcc.mak and vc71.mak create libraries with version number 1_38 instead of 1_39. Regards, Harald Csaszar

2 1

Re: [boost] mingw help
by Artyom 30 May '09

30 May '09

> 1. Currently, we use the same naming on mingw as on windows > -- > foo.dll and foo.lib for shared libs and import libs, and > libfoo.lib > for static library. Is this OK? No, this is definatly not correct. This is how, autotools generate libraries: Mingw Naming convention for library "foo" with ABI version 3: Static library: libfoo.a --> installed to lib Import lubrary: libfoo.dll.a --> installed to lib Dynamic library: libfoo-3.dll --> installed to bin Cygwin Naming convention Static library: libfoo.a --> installed to lib Import lubrary: libfoo.dll.a --> installed to lib Dynamic library: cygfoo-3.dll --> installed to bin Artyom

2 1

[thread] #2636 threads and locks
by vicente.botet 30 May '09

30 May '09

Hi, "The standard includes template <class Duration> unique_lock(mutex_type& m, const Duration& rel_time); which is not in boost::threads. " Anthony, I think that this ticket is already on the released locks.hpp file (modified with 48213, 49324) : template<typename TimeDuration> unique_lock(Mutex& m_,TimeDuration const& target_time): m(&m_),is_locked(false) { timed_lock(target_time); } So it can be closed. Best, _____________________ Vicente Juan Botet Escribá

1 1

[thread] #2637 shared mutex lock
by vicente.botet 30 May '09

30 May '09

Hi, "The folowing should be added template<typename TimeDuration?> bool shared_mutex::timed_lock_shared(TimeDuration? const & relative_time); template<typename TimeDuration?> bool shared_mutex::timed_lock(TimeDuration? const & relative_time); " Anthony, I think that this ticket is already on the released shared_mutex.hpp files: template<typename TimeDuration> bool timed_lock_shared(TimeDuration const & relative_time) { return timed_lock_shared(get_system_time()+relative_time); } template<typename TimeDuration> bool timed_lock(TimeDuration const & relative_time) { return timed_lock(get_system_time()+relative_time); } So it can be closed. Best, _____________________ Vicente Juan Botet Escribá

1 0

[thread] #2741 proposal to manage portable and non portable thread attributes
by vicente.botet 30 May '09

30 May '09

Hi, Anthony, I have attached to the ticket https://svn.boost.org/trac/boost/ticket/2741 a test files and patches for the feature POSIX implementation Do you think that this is on the right way? Best, _____________________ Vicente Juan Botet Escribá

1 0

Re: [boost] [Graph] how to test/submit patch
by Tim Keitt 30 May '09

30 May '09

On Fri, May 29, 2009 at 2:08 PM, Marshall Clow <marshall(a)idio.com> wrote: > At 1:02 PM -0500 5/29/09, Tim Keitt wrote: >> >> I would like to submit a patch for the Graph library. (This is the >> iterator splitting issue I raised some time ago.) > > Same answer as on the -users list ;-) > >> So what is the procedure? >> >> 1) check out source from sourceforge SVN (done) >> 2) make changes >> 3) run tests??? (what is the best way to ensure the behavior has not >> changed?) > > Run the tests. I was trying to ascertain where they live and how to run them. > If you think that there should be more tests, write them. Should be easy to come up with a test case or two. Just checking to see if I haven't missed something standard in terms of regressions, etc. > Ideally, you should write a test that fails on the unpatched version of the > library, and succeeds after applying your patch. The goal is not to change the existing behavior. My patch should not affect algorithms called on the built-in data structures. It will make the library compatible with my own data structures that require slightly more restrictive assumptions regarding iterator pairs. > >> 4) generate the patch (use svn diff?) > > Yep. Its been a long time -- are there preferred formats/switches when calling diff? (I recall vaguely a -p argument.) > >> 5) submit somewhere > > In a Trac ticket. <http://svn.boost.org> OK. Thanks for the help. THK > >> I just want to be sure I'm pulling the correct tree and there is some >> means to run regressions on my changes. > > Sounds good to me. > -- > -- Marshall > > Marshall Clow Idio Software <mailto:marshall@idio.com> > > It is by caffeine alone I set my mind in motion. > It is by the beans of Java that thoughts acquire speed, > the hands acquire shaking, the shaking becomes a warning. > It is by caffeine alone I set my mind in motion. > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > -- Timothy H. Keitt Associate Professor Section of Integrative Biology University of Texas at Austin http://www.keittlab.org/

2 1