On 2/10/2011 2:14 PM, Daniel Larimer wrote:
On 2/10/11 12:52 PM, "Frédéric Bron"<frederic.bron@m4x.org> wrote:
as a possible user/tester of the library I would prefer if the library package contains only the new files so we can decompress them directly on the boost root system. If the name of the directory was specific this could be even easier (e.g. why not movie temporary all your new files to a specific directory "operators")
Can you tell me what you would like more precisely: - only the header files, - everything, including test files and documentation?
I could tar it so that if you extract it from a boost distribution you get: boost/type_traits/has_operator_xxx.hpp libs/type_traits/test/... libs/type_traits/doc/...
For the doc however the merge could be a problem...
When trying to work on a modularized boost, it would be very helpful if each library was set up like so:
type_traits/ test/ doc/ ... src/ build/ *.jam boost/ type_traits/hasoperator_xxx.hpp
Then use the .jam file to copy/symlink libs/type_traits/boost/typetraits to boost_1_45_0/boost/typetraits
Then developers could create a git,svn,cvs,tar.gz repository of just 'type_traits' and put it in boost/libs and it would be very easy to manage individual libraries without having to worry about the problems with 'overlaying' two directory structures manually via .zip files.
It seems like such a change would be relatively small, yet ease the transition to something like ryppl or Boost.CMake.
I do not think a jamfile should be copying anything to a hardcoded path outside of the directories in which the library resides. That is a real recipe for ticked off end-users.