Re: [boost] [BCP] Script for global renaming Boost Namespace
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
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@yahoo.com> wrote:
From: Artyom <artyomtnk@yahoo.com> Subject: [BCP] Script for global renaming Boost Namespace To: boost@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
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
On Saturday 30 May 2009 10:55:25 am Artyom wrote: that 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
On Saturday 30 May 2009 08:43:19 pm Artyom wrote:
If there is an interest in it and, it would be accepted I'd be glad to continue supporting it on regular basis.
That is a very good thing :-)
Probably it may be integreted with regeression test to ensure that Boost still works after renaming.
Yes, that is needed for this to be useful. Users need to assert the issues before and after a namespace switch are identical for the same platform/toolset. I did some testing of running test after conversion and got most of it automated and successful. It was actually some special handling in the build scripts that caused most grief, as they had to be modified more or less with special cases or by hand. This all need to be automated. The good thing is that most of these special cases probably went away with the change to Boost.Build 2.
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.
Yes, I think that is a fair demand on those in need of this tool.
So I don't see a real problem in using Python for this purpose.
neither do I.
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
Ah, in that case this is a stand-alone tool. Much easier to get accepted I would think. ;-) And you do not need to get it accepted to make it useful and maintainable as integration and use does not affect boost in any way.
Because it can be actually applied on full Boost tree, if someone wants its full version.
yes. In my view, the key issue to solve is automating the complete boost test suite execution after conversion of namespace, and then compare relevant results to the original on same platform/toolset. Differences in compilation and test results is a problem with the tool. If bcp is used, only relevant tests can be executed, and that may provide some trickiness. Maybe it is good enough to validate the tool with the whole lot, and then assume it is correct for any destination namespace and bcp subset of boost. -- Bjørn
participants (2)
-
Artyom -
Bjørn Roald