On Feb 10, 2011, at 3:34 PM, Edward Diener wrote:
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.
Boost.Context used something like this to overwrite boost/context/context.hpp with the proper version for the platform it was on. The only other option to avoid a copy would be to add boost/libs/typetraits to the include path, but ultimately the headers need to be 'installed' someplace. I don't think it is any different than the jam file writing to the bin dir. And having an unzip go wrong is much more likely to tick off a user than a 'well defined' bjam script. Presumably a library 'owns' its directory in libs/MODULE and boost/MODULE and boost/MODULE.hpp so as long as the library maintainer tells it to do the right thing that maintainer will not tick off end-users.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost