Any comments on this from the Boost Sandbox admins, or anyone? -------- Original Message -------- Subject: Re: Boost Sandbox layout? Date: Wed, 17 Nov 2004 18:41:58 -0600 David Abrahams wrote:
Rene Rivera <grafik.list@redshift-software.com> writes:
Was there ever a discussion as to the layout? (A cursory search did not reveal anything)
I like what I _think_ you're suggesting we actually should do, but would you mind spelling it out for everyone's benefit?
I was trying not to prejudice the conversation if there was already reasons for the current layout... But since you ask :-) I think it would more beneficial to have each library in an individual sub directory of the boost-sandbox. Each library would still be required to follow the regular Boost layout within itself. For example I'm putting together the warnings submission and it would be nice to set it up like this: /boost-sandbox/warnings /boost/utility/warnings.hpp /libs/utility /docs/warnings.html /test /Jamfile /nowarn_unused_var_test.cpp Having the isolated subdir would remove the 3 drawbacks I mentioned. But itself has some drawbacks: 1) Some of the setup files would be duplicated. Like the boost.png, Jamfile, Jamrules, and boost-build.jam at the "top" level. But at the same time it means that the library would be truly standalone. 2) An eventual long list of directories right at the top. One advantage is the reduce complexity of management by the library authors. As it would be much easier to do things like remove a library from the sandbox after it's been accepted into Boost, a single recursive cvs remove and commit instead of finding all the files and dirs. It might even be possible to setup some form of script automation to make snapshots of the individual libraries automatically available (without CVS access). -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
Rene Rivera wrote:
Any comments on this from the Boost Sandbox admins, or anyone?
The suggested layout has a big disadvantage. Now I can just add boost-sandbox to include path, and used it. Otherwise, I'd have to add include paths to every library. I really wish there were a version control system with symlinks in repository. - Volodya
Vladimir Prus wrote:
Rene Rivera wrote:
Any comments on this from the Boost Sandbox admins, or anyone?
The suggested layout has a big disadvantage. Now I can just add boost-sandbox to include path, and used it. Otherwise, I'd have to add include paths to every library.
Yes, big disadvantage... But is using more than one library from the sandbox a common occurence? (I've only used the named_params).
I really wish there were a version control system with symlinks in repository.
There is. I'm still working on writing it. -- And I'm not kidding. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
Vladimir Prus <ghost@cs.msu.su> writes:
Rene Rivera wrote:
Any comments on this from the Boost Sandbox admins, or anyone?
The suggested layout has a big disadvantage. Now I can just add boost-sandbox to include path, and used it. Otherwise, I'd have to add include paths to every library.
"explicit is better than implicit" I've had real problems with sandbox elements conflicting with those in Boost.
I really wish there were a version control system with symlinks in repository.
Subversion (Unix only, though). -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
I really wish there were a version control system with symlinks in repository.
Subversion (Unix only, though).
Gnuarch does, unix only since getting it to work on other platforms is a lot of work. I think that Bitkeeper and Perforce do as well, and might even support them on Windows. With Monotone you have to write your own hooks to support them, which is a pain but means that you might be able to do something with non-unix platforms. I don't think Darcs does, although I'm not sure.
Daniel James wrote:
Gnuarch does, unix only since getting it to work on other platforms is a lot of work. I think that Bitkeeper and Perforce do as well, and might even support them on Windows. With Monotone you have to write your own hooks to support them, which is a pain but means that you might be able to do something with non-unix platforms. I don't think Darcs does, although I'm not sure.
Oh dear. Of course, windows doesn't have symbolic links - I was thinking of the faked ones on Cygwin. I really shouldn't post in the middle of the night. So Bitkeeper and Perforce certainly don't support them. Although apparently ClearCase implements them by intercepting file system calls, but ClearCase isn't really appropriate for open source projects. Since gnuarch currently only runs under cygwin, it probably supports them there. Thanks to Michael for pointing this out to me. Daniel
Daniel James wrote:
Oh dear. Of course, windows doesn't have symbolic links - I was thinking of the faked ones on Cygwin. I really shouldn't post in the middle of the night. So Bitkeeper and Perforce certainly don't support them. Although apparently ClearCase implements them by intercepting file system calls, but ClearCase isn't really appropriate for open source projects.
Sorry for jumping in, but I am sucessfully using a kind of "symlinks" on windows for this. Are you aware of the linkd command? (Also see junction points.) You can symlink directories with this. And it is so low level, that normal file IO goes through it. However support in the GUI is very limited in that you cannot by any means distinguish between a real and a linked directory. The command line however is different, because the dir command displays them with extra marks. I am currently using this to switch part of the boost tree to a local repository of mine. Roland
Rene Rivera <grafik.list@redshift-software.com> writes:
Any comments on this from the Boost Sandbox admins, or anyone?
-------- Original Message -------- Subject: Re: Boost Sandbox layout? Date: Wed, 17 Nov 2004 18:41:58 -0600
David Abrahams wrote:
Rene Rivera <grafik.list@redshift-software.com> writes:
Was there ever a discussion as to the layout? (A cursory search did not reveal anything) I like what I _think_ you're suggesting we actually should do, but would you mind spelling it out for everyone's benefit?
I was trying not to prejudice the conversation if there was already reasons for the current layout... But since you ask :-)
I think it would more beneficial to have each library in an individual sub directory of the boost-sandbox. Each library would still be required to follow the regular Boost layout within itself.
That's what I thought you'd say. I like that.
For example I'm putting together the warnings submission and it would be nice to set it up like this:
/boost-sandbox/warnings /boost/utility/warnings.hpp /libs/utility /docs/warnings.html /test /Jamfile /nowarn_unused_var_test.cpp
Having the isolated subdir would remove the 3 drawbacks I mentioned. But itself has some drawbacks:
1) Some of the setup files would be duplicated. Like the boost.png, Jamfile, Jamrules, and boost-build.jam at the "top" level. But at the same time it means that the library would be truly standalone.
Not a big deal, IMO. On the other hand, I think the top-level bjam files can be moved up one level to avoid duplication. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
participants (5)
-
Daniel James -
David Abrahams -
Rene Rivera -
Roland Schwarz -
Vladimir Prus