[sandbox] SVN externals, and large subdirs.
Troy, Doug, and others, I just moved the boost/sandbox/troy subdir to boost/sandbox-branches/troy. This was to fix two problems: a) That dir has svn externals which point to the dev/write side of the svn repo. This makes it impossible for read-only checkouts to work as it asks for user name and password as soon as it hits those externals. b) It's a very large tree containing multiple "copies" of the 1.34.0 sources. I know copies are a "cheap" operation on SVN, but they are not cheap operations on users hard drives. (In my personal case svn ends up having memory failures as it tries to do the checkout, and leads to corrupt partial checkouts, and corrupt a file system.) My suggestion is to restrict to putting library projects only in the boost/sandbox dir. And under no circumstances use externals. They just don't seem to work as one might expect. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
On Wed, 2007-05-23 at 22:52 -0500, Rene Rivera wrote:
Troy, Doug, and others,
I just moved the boost/sandbox/troy subdir to boost/sandbox-branches/troy. This was to fix two problems:
Ouch. Some warning would have been nice... that move breaks all of the automatic regression testing Troy has setup (about 5 boxes running continuous builds of Boost via CMake, and submitting those results to a Dart2 server). Troy's away, so it'll be a few days before he can tweak the machines to deal with this change. Not catastrophic, but it'll slow me down a bit :(
a) That dir has svn externals which point to the dev/write side of the svn repo. This makes it impossible for read-only checkouts to work as it asks for user name and password as soon as it hits those externals.
We'll fix those.
b) It's a very large tree containing multiple "copies" of the 1.34.0 sources. I know copies are a "cheap" operation on SVN, but they are not cheap operations on users hard drives. (In my personal case svn ends up having memory failures as it tries to do the checkout, and leads to corrupt partial checkouts, and corrupt a file system.)
Yeah, we've become accustomed to checking out the whole sandbox.
My suggestion is to restrict to putting library projects only in the boost/sandbox dir.
And, eventually, moving those projects under sandbox/projects/projectname.
And under no circumstances use externals. They just don't seem to work as one might expect.
Interesting. - Doug
Douglas Gregor wrote:
On Wed, 2007-05-23 at 22:52 -0500, Rene Rivera wrote:
My suggestion is to restrict to putting library projects only in the boost/sandbox dir.
And, eventually, moving those projects under sandbox/projects/projectname.
And under no circumstances use externals. They just don't seem to work as one might expect.
Interesting.
I'm not sure that radical a measure is needed. In fact, I can imagine svn:externals to be put to good use if individual sandbox projects drag in build system chunks from a sibling template directory. That way it's possible to keep the build system in sync with HEAD (sorry, trunk :-) ), without sandbox users / developers having to care. I'm sure there are more use cases for svn:externals. Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...
Douglas Gregor wrote:
On Wed, 2007-05-23 at 22:52 -0500, Rene Rivera wrote:
Troy, Doug, and others,
I just moved the boost/sandbox/troy subdir to boost/sandbox-branches/troy. This was to fix two problems:
Ouch. Some warning would have been nice...
Sorry about that... But I had various users, and myself, being unable to use the sandbox.
b) It's a very large tree containing multiple "copies" of the 1.34.0 sources. I know copies are a "cheap" operation on SVN, but they are not cheap operations on users hard drives. (In my personal case svn ends up having memory failures as it tries to do the checkout, and leads to corrupt partial checkouts, and corrupt a file system.)
Yeah, we've become accustomed to checking out the whole sandbox.
It's not a question of adaptation. Many people checkout the top level sandbox dir, myself included, so that they can tell when people add new projects.
My suggestion is to restrict to putting library projects only in the boost/sandbox dir.
And, eventually, moving those projects under sandbox/projects/projectname.
Yep... and more projects are doing that. And I've done some minor cleanup in there, and I'll probably do some more :-)
And under no circumstances use externals. They just don't seem to work as one might expect.
Interesting.
Perhaps that was a bit extreme :-) But my feelings for svn are probably seeping through. Sorry. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
on Thu May 24 2007, Rene Rivera <grafikrobot-AT-gmail.com> wrote:
Douglas Gregor wrote:
On Wed, 2007-05-23 at 22:52 -0500, Rene Rivera wrote:
Troy, Doug, and others,
I just moved the boost/sandbox/troy subdir to boost/sandbox-branches/troy. This was to fix two problems:
Ouch. Some warning would have been nice...
Sorry about that... But I had various users, and myself, being unable to use the sandbox.
b) It's a very large tree containing multiple "copies" of the 1.34.0 sources. I know copies are a "cheap" operation on SVN, but they are not cheap operations on users hard drives. (In my personal case svn ends up having memory failures as it tries to do the checkout, and leads to corrupt partial checkouts, and corrupt a file system.)
Yeah, we've become accustomed to checking out the whole sandbox.
It's not a question of adaptation. Many people checkout the top level sandbox dir, myself included, so that they can tell when people add new projects.
IMO that's not the way to deal with it. If you want notifications we should set up an RSS feed or just a mailing list based on the post-commit hook.
My suggestion is to restrict to putting library projects only in the boost/sandbox dir.
And, eventually, moving those projects under sandbox/projects/projectname.
Yep... and more projects are doing that. And I've done some minor cleanup in there, and I'll probably do some more :-)
And under no circumstances use externals. They just don't seem to work as one might expect.
Interesting.
Perhaps that was a bit extreme :-) But my feelings for svn are probably seeping through. Sorry.
Well, Troy has been using externals very effectively; you just need an appropriate project organization. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
on Thu May 24 2007, Rene Rivera <grafikrobot-AT-gmail.com> wrote:
It's not a question of adaptation. Many people checkout the top level sandbox dir, myself included, so that they can tell when people add new projects.
IMO that's not the way to deal with it. If you want notifications we should set up an RSS feed or just a mailing list based on the post-commit hook.
Hm, we could argue about user interfaces for a long time :-) But I'll just say that, a minimal UI is better than a layered UI. Sure we could add another layer (or facet) to the SVN interface as you suggest, but it just makes the use of SVN that one layer more complicated to use.
Well, Troy has been using externals very effectively; you just need an appropriate project organization.
Sure, I didn't say his use wasn't effective, just that it doesn't work for *our* general use. But since you stepped into it, please suggest a better project organization. After all the point of doing the sandbox move is to discover problems with how we are doing things. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Douglas Gregor <doug.gregor <at> gmail.com> writes:
On Wed, 2007-05-23 at 22:52 -0500, Rene Rivera wrote:
Troy, Doug, and others,
I just moved the boost/sandbox/troy subdir to boost/sandbox-branches/troy. This was to fix two problems:
Ouch. Some warning would have been nice... that move breaks all of the automatic regression testing Troy has setup (about 5 boxes running continuous builds of Boost via CMake, and submitting those results to a Dart2 server). Troy's away, so it'll be a few days before he can tweak the machines to deal with this change. Not catastrophic, but it'll slow me down a bit :(
Excuse me, but wouldn't it be better to reserve the sandbox (or whatever other repository/area) for candidate libraries and keep them separate from this kind of work? While we're at it, I understand the desire of better separating each candidate library/sandbox project than they were in the SF repository, but wouldn't a structure as close as the official Boost tree help avoid having to change one's library from "sandbox" style to "official" style? I'm asking because I find that there are things in the Boost environment that work automatically if you have a boost/your-library - libs/your-library structure which are harder to do with a different directory tree. Cheers, Nicola Musatti
Nicola Musatti wrote:
Douglas Gregor <doug.gregor <at> gmail.com> writes:
Troy, Doug, and others,
I just moved the boost/sandbox/troy subdir to boost/sandbox-branches/troy. This was to fix two problems: Ouch. Some warning would have been nice... that move breaks all of the automatic regression testing Troy has setup (about 5 boxes running continuous builds of Boost via CMake, and submitting those results to a Dart2 server). Troy's away, so it'll be a few days before he can tweak
On Wed, 2007-05-23 at 22:52 -0500, Rene Rivera wrote: the machines to deal with this change. Not catastrophic, but it'll slow me down a bit :(
Excuse me, but wouldn't it be better to reserve the sandbox (or whatever other repository/area) for candidate libraries and keep them separate from this kind of work?
While we're at it, I understand the desire of better separating each candidate library/sandbox project than they were in the SF repository, but wouldn't a structure as close as the official Boost tree help avoid having to change one's library from "sandbox" style to "official" style?
I'm asking because I find that there are things in the Boost environment that work automatically if you have a boost/your-library - libs/your-library structure which are harder to do with a different directory tree.
Yes, that's the structure for the sandbox <http://svn.boost.org/trac/boost/wiki/BoostSandbox>. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Rene Rivera <grafikrobot <at> gmail.com> writes: [...]
I'm asking because I find that there are things in the Boost environment that work automatically if you have a boost/your-library - libs/your-library structure which are harder to do with a different directory tree.
Yes, that's the structure for the sandbox <http://svn.boost.org/trac/boost/wiki/BoostSandbox>.
I see, so the only change with respect to the original SF structure is the additional top level project specific directory (not counting those projects that didn't follow the canonical structure, that is). That's reasonable. I don't really know how I got the idea that some different structure was being put into place :-( Cheers, Nicola Musatti
On Thu, May 24, 2007 at 10:39:33AM -0500, Rene Rivera wrote:
Yes, that's the structure for the sandbox <http://svn.boost.org/trac/boost/wiki/BoostSandbox>.
Whoops. Sorry about mussin' the dirs. Apologies for not having seen that page before. So where should that stuff go? I'm accustomed to having "sandbox" identify a free-form area. 'sandbox-branches' isn't appropriate either. I think the current sandbox should actually be a subdirectory of sandbox called "projects". Here's another thing. The layout of the sandbox currently does not support independent versioning of projects, e.g., the author of library A has no way to create a branch/tag of A independently of library B. You have to branch the entire sandbox. So you can envision a structure: projects/ a/ trunk/ branches/ somebranch/ otherbranch/ tags/ somerelease/ otherrelease/ b/ trunk/ branches/ somebranch/ otherbranch/ tags/ somerelease/ otherrelease/ (...) Where each of the trunk, branches/*/, tags/*/, dirs contain the standard tree boost/ a/ libs/ a/ src/ docs/ test/ This enables one to create a directory (in the free-form type sandbox, wherever that turns out to be) of the sandbox projects you're watching: % svn pg svn:externals . a https://svn.boost.org/svn/boost/projects/a/trunk b https://svn.boost.org/svn/boost/projects/b/trunk c https://svn.boost.org/svn/boost/projects/c/trunk d https://svn.boost.org/svn/boost/projects/d/tags/stable-release Which shows svn:externals in a new light. The use case "I use svn update to see if there is anything new in the sandbox" works. It also opens up clean ways to support a all kinds of other use-cases, like "i want to restrict commit access to certain branches of various projects because it is release time and I am the release manager". and "I want to create a distribution of boost containing only certain components at certain revisions". But that's another story. Anyhow let me know what you think about moving sandbox => sandbox/(something). -t
troy d. straszheim wrote:
So where should that stuff go? I'm accustomed to having "sandbox" identify a free-form area. 'sandbox-branches' isn't appropriate either. I think the current sandbox should actually be a subdirectory of sandbox called "projects".
In boost itself libraries live next to each other (in terms of file system layout). Thus, a sandbox project could be looked at as a single library stored 'out-of-place'. The build system should support referring to an existing boost tree for the 'official boost' dependencies, such that the sandbox project only needs to provide new or updated files, but not a whole copy of boost-mainline.
Here's another thing. The layout of the sandbox currently does not support independent versioning of projects, e.g., the author of library A has no way to create a branch/tag of A independently of library B. You have to branch the entire sandbox.
I'm not sure what you mean by 'support'. With subversion, branching (and tagging) is just a matter of making a copy of the tree you want to branch. It's all about conventions. Thus, you can 'branch' inside your sandbox project just fine. Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...
On Fri, May 25, 2007 at 09:37:37AM -0400, Stefan Seefeld wrote:
troy d. straszheim wrote:
So where should that stuff go? I'm accustomed to having "sandbox" identify a free-form area. 'sandbox-branches' isn't appropriate either. I think the current sandbox should actually be a subdirectory of sandbox called "projects".
A rephrase of the question: where should this stuff that isn't boost libraries go? A new directory? What to call it?
In boost itself libraries live next to each other (in terms of file system layout). Thus, a sandbox project could be looked at as a single library stored 'out-of-place'.
Yes of course.
The build system should support referring to an existing boost tree for the 'official boost' dependencies, such that the sandbox project only needs to provide new or updated files, but not a whole copy of boost-mainline.
Naturally.
Here's another thing. The layout of the sandbox currently does not support independent versioning of projects, e.g., the author of library A has no way to create a branch/tag of A independently of library B. You have to branch the entire sandbox.
I'm not sure what you mean by 'support'. With subversion, branching (and tagging) is just a matter of making a copy of the tree you want to branch. It's all about conventions. Thus, you can 'branch' inside your sandbox project just fine.
But the conventions explicitly prohibit independent versioning of projects in an organized way. This page: http://svn.boost.org/trac/boost/wiki/BoostSandbox Does not account for how one should branch/tag/trunk one's project in the sandbox independently of the others. -t
troy d. straszheim wrote:
On Fri, May 25, 2007 at 09:37:37AM -0400, Stefan Seefeld wrote:
troy d. straszheim wrote:
So where should that stuff go? I'm accustomed to having "sandbox" identify a free-form area. 'sandbox-branches' isn't appropriate either. I think the current sandbox should actually be a subdirectory of sandbox called "projects".
A rephrase of the question: where should this stuff that isn't boost libraries go? A new directory? What to call it?
I have an 'xml' project that lives in sandbox/xml. I think that is in line with your suggestion of having sandbox/X be independent projects (for any value of 'X').
But the conventions explicitly prohibit independent versioning of projects in an organized way.
How so ?
This page:
http://svn.boost.org/trac/boost/wiki/BoostSandbox
Does not account for how one should branch/tag/trunk one's project in the sandbox independently of the others.
It simply doesn't talk about versioning / branching at all. This doesn't imply that the whole sandbox has to be branched as a whole. I'm pretty sure everybody agrees that versioning should be by project, as far as the sandbox is concerned. Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...
On Fri, May 25, 2007 at 09:59:31AM -0400, Stefan Seefeld wrote:
It simply doesn't talk about versioning / branching at all. This doesn't imply that the whole sandbox has to be branched as a whole.
Of course you can branch sandbox/ProjectA off to some ad-hoc location in sandbox-branches. But this is haphazard.... Branches of ProjectA should be located someplace specific.
I'm pretty sure everybody agrees that versioning should be by project, as far as the sandbox is concerned.
OK, then at some point we could discuss how to accomplish this in an orderly fashion. -t
troy d. straszheim wrote:
I'm pretty sure everybody agrees that versioning should be by project, as far as the sandbox is concerned.
OK, then at some point we could discuss how to accomplish this in an orderly fashion.
To use my sandbox/xml example, I can see moving to something akin to sandbox/xml/trunk branches etc. Would that make sense for your project(s) ? Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...
On Fri, May 25, 2007 at 10:15:53AM -0400, Stefan Seefeld wrote:
To use my sandbox/xml example, I can see moving to something akin to
sandbox/xml/trunk branches
etc.
Would that make sense for your project(s) ?
Yah. See this mail: http://lists.boost.org/Archives/boost/2007/05/122282.php which proposes almost exactly that. -t
Stefan Seefeld wrote:
troy d. straszheim wrote:
On Fri, May 25, 2007 at 09:37:37AM -0400, Stefan Seefeld wrote:
troy d. straszheim wrote: This page:
http://svn.boost.org/trac/boost/wiki/BoostSandbox
Does not account for how one should branch/tag/trunk one's project in the sandbox independently of the others.
It simply doesn't talk about versioning / branching at all. This doesn't imply that the whole sandbox has to be branched as a whole. I'm pretty sure everybody agrees that versioning should be by project, as far as the sandbox is concerned.
What the wiki doesn't mention is that we have both 'sandbox-branches', and 'sandbox-tags'. Seems reasonable to keep that arrangement. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Rene Rivera wrote:
What the wiki doesn't mention is that we have both 'sandbox-branches', and 'sandbox-tags'. Seems reasonable to keep that arrangement.
I'm not sure I agree. If sandbox projects are managed individually, why not letting them care for their own branching arrangements (i.e. local file layout) ? Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...
Stefan Seefeld wrote:
Rene Rivera wrote:
What the wiki doesn't mention is that we have both 'sandbox-branches', and 'sandbox-tags'. Seems reasonable to keep that arrangement.
I'm not sure I agree. If sandbox projects are managed individually, why not letting them care for their own branching arrangements (i.e. local file layout) ?
Because then when one checks out the boost/sandbox one will also get a bunch of "copies" of all the projects. AFAIK the arrangement was designed such that one can check out boost/sandbox or boost/stable or boost/devel, and have a simple tree. I know this isn't the "recommended" svn layout but personally (even though I didn't come up with it) it seems more _humane_ than the recommended. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Rene Rivera wrote:
Stefan Seefeld wrote:
Rene Rivera wrote:
What the wiki doesn't mention is that we have both 'sandbox-branches', and 'sandbox-tags'. Seems reasonable to keep that arrangement. I'm not sure I agree. If sandbox projects are managed individually, why not letting them care for their own branching arrangements (i.e. local file layout) ?
Because then when one checks out the boost/sandbox one will also get a bunch of "copies" of all the projects. AFAIK the arrangement was designed such that one can check out boost/sandbox or boost/stable or boost/devel, and have a simple tree. I know this isn't the "recommended" svn layout but personally (even though I didn't come up with it) it seems more _humane_ than the recommended.
Why would anybody check out the whole sandbox ? I'd expect people to check out individual projects. And, if many people do want a single sandbox (for example defined as the set of all sandbox trunks), one can easily set up such a metaproject using svn:externals. (see, another good use case for it ! ;-) ) Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...
Stefan Seefeld wrote:
troy d. straszheim wrote:
In boost itself libraries live next to each other (in terms of file system layout). Thus, a sandbox project could be looked at as a single library stored 'out-of-place'. The build system should support referring to an existing boost tree for the 'official boost' dependencies, such that the sandbox project only needs to provide new or updated files, but not a whole copy of boost-mainline.
This is a huge problem with the current sandbox organization. After spending a couple hours the other day trying to get boost.build to work in the sandbox tree I gave up in frustration and had to copy sandbox directories into my boost tree to use bjam. This is very annoying to say the least. Jeff
Jeff Garland wrote:
Stefan Seefeld wrote:
troy d. straszheim wrote:
In boost itself libraries live next to each other (in terms of file system layout). Thus, a sandbox project could be looked at as a single library stored 'out-of-place'. The build system should support referring to an existing boost tree for the 'official boost' dependencies, such that the sandbox project only needs to provide new or updated files, but not a whole copy of boost-mainline.
This is a huge problem with the current sandbox organization. After spending a couple hours the other day trying to get boost.build to work in the sandbox tree I gave up in frustration and had to copy sandbox directories into my boost tree to use bjam. This is very annoying to say the least.
Is this a boost.build limitation ? What's the proper way to fix that ? Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...
Stefan Seefeld wrote:
Jeff Garland wrote:
troy d. straszheim wrote:
In boost itself libraries live next to each other (in terms of file system layout). Thus, a sandbox project could be looked at as a single library stored 'out-of-place'. The build system should support referring to an existing boost tree for the 'official boost' dependencies, such that the sandbox project only needs to provide new or updated files, but not a whole copy of boost-mainline. This is a huge problem with the current sandbox organization. After spending a couple hours the other day trying to get boost.build to work in the sandbox
Stefan Seefeld wrote: tree I gave up in frustration and had to copy sandbox directories into my boost tree to use bjam. This is very annoying to say the least.
Is this a boost.build limitation ?
Probably.
What's the proper way to fix that ?
It sounds like the sandbox libs will eventually become branches of the main repository, so that would entrench the practice of embedding these libraries into an existing tree. Personally I'd prefer to have something where I can keep a pristine distribution and then add new libs by having them in their own tree -- something like: boost_1_34_0 boost_some_new_lib1 boost_some_new_lib2 But to build and run the tests/examples in these 'one library trees' means that you'd need to have a way to specify the base distribution to the build system. Jeff
Jeff Garland wrote:
It sounds like the sandbox libs will eventually become branches of the main repository, so that would entrench the practice of embedding these libraries into an existing tree. Personally I'd prefer to have something where I can keep a pristine distribution and then add new libs by having them in their own tree -- something like:
boost_1_34_0 boost_some_new_lib1 boost_some_new_lib2
I totally agree. Having to branch the whole boost tree in order to add a new project seems very redundant (in different ways). For one, it requires me manually tracking changes in the trunk/, even if my own work is only kept in a (new) subtree. It's also redundant since users who want to try a sandbox project would essentially need to store (and build !) a separate boost source and build tree just for the sandbox project.
But to build and run the tests/examples in these 'one library trees' means that you'd need to have a way to specify the base distribution to the build system.
Indeed. But that appears to me to be a good idea anyways. We were discussing ways to modularize boost better. Being able to compile specific boost libs in isolation, while referring / using a separate external boost tree for dependencies seemed to be a worthwhile goal (say, for more modular testing). Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...
Stefan Seefeld wrote:
Jeff Garland wrote:
It sounds like the sandbox libs will eventually become branches of the main repository, so that would entrench the practice of embedding these libraries into an existing tree. Personally I'd prefer to have something where I can keep a pristine distribution and then add new libs by having them in their own tree -- something like:
boost_1_34_0 boost_some_new_lib1 boost_some_new_lib2
I totally agree. Having to branch the whole boost tree in order to add a new project seems very redundant (in different ways). For one, it requires me manually tracking changes in the trunk/, even if my own work is only kept in a (new) subtree.
It's also redundant since users who want to try a sandbox project would essentially need to store (and build !) a separate boost source and build tree just for the sandbox project.
Hadn't even thought of these issues, but they are good points. I was thinking of the case where I didn't even have subversion for the core boost, but an official distribution.
But to build and run the tests/examples in these 'one library trees' means that you'd need to have a way to specify the base distribution to the build system.
Indeed. But that appears to me to be a good idea anyways. We were discussing ways to modularize boost better. Being able to compile specific boost libs in isolation, while referring / using a separate external boost tree for dependencies seemed to be a worthwhile goal (say, for more modular testing).
Totally agree. Jeff
Jeff Garland wrote:
I was thinking of the case where I didn't even have subversion for the core boost, but an official distribution.
I'm adding some support for the "installed Boost" use case. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Stefan Seefeld wrote:
Jeff Garland wrote:
Stefan Seefeld wrote:
troy d. straszheim wrote:
In boost itself libraries live next to each other (in terms of file system layout). Thus, a sandbox project could be looked at as a single library stored 'out-of-place'. The build system should support referring to an existing boost tree for the 'official boost' dependencies, such that the sandbox project only needs to provide new or updated files, but not a whole copy of boost-mainline.
This is a huge problem with the current sandbox organization. After spending a couple hours the other day trying to get boost.build to work in the sandbox tree I gave up in frustration and had to copy sandbox directories into my boost tree to use bjam. This is very annoying to say the least.
Is this a boost.build limitation ? What's the proper way to fix that ?
Making it work "seamlessly" is up to the individual library authors. I was expecting that having a template for authors would fix most of these problems. The usual arrangement with sandbox things is that one provides a -sBOOST_ROOT=/some/path, and one can then build in the specific sandbox project. I'll see if I can do some cleanups to make so of this easier. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Stefan Seefeld wrote:
Jeff Garland wrote:
This is a huge problem with the current sandbox organization. After spending a couple hours the other day trying to get boost.build to work in the sandbox tree I gave up in frustration and had to copy sandbox directories into my boost tree to use bjam. This is very annoying to say the least.
Is this a boost.build limitation ? What's the proper way to fix that ?
Regards, Stefan
Unless I mis-understand the problem... this is not a boost.build issue at all. In fact, this is one of the things I love about bjam and the boost.build system. For example, this is a snipping from one of my Jamroot files: ... use-project /omd/common : library/common/trunk/build ; use-project /omd/xml : library/xml/trunk/build ; use-project /omd/room : library/room/trunk/build ; use-project /omd/factory : library/factory/trunk/build ; use-project /omd/daemon : library/daemon/trunk/build ; use-project /vendor/xerces-c : library/vendor/xerces-c/build ; ... As you can see, I use the "recommended" best practice for subversion filesystem layout (trunk/branch/tag). Personally, this was a total pain; however, I couldn't think of anything better to do for layout given the size and reuse of many of my projects. Then I discovered bjam/boost.build and I became a very happy person. Between the concepts of project id's and usage requirements my build tasks have become trivial compared to what they were. In other projects I have a single library sitting parallel to the rest of the release tree that I'm specializing for a client. Again, the process has been trivial by simply modifying the Jamroot project id to point elsewhere. This may be an issue with the Jamroot project definitions, but it is not a limitation of bjam/boost.build. Now you can tell me I didn't understand the problem (o; michael -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com
Michael Caisse wrote:
Unless I mis-understand the problem... this is not a boost.build issue at all. In fact, this is one of the things I love about bjam and the boost.build system.
It may not be, but the sandbox isn't really setup with boost.build when you check it out from the repository. And there's no instructions on how to do it either. And
This may be an issue with the Jamroot project definitions, but it is not a limitation of bjam/boost.build.
Possibly. I'd like to see someone post (or better yet check into the sandbox) a set of Jamfiles that can be customized so that this would work smoothly -- if that's possible. Jeff
Possibly. I'd like to see someone post (or better yet check into the sandbox) a set of Jamfiles that can be customized so that this would work smoothly -- if that's possible.
Jeff
Rene Rivera and I got started on a template processing system with a provided template for sandbox libraries, including a small "dummy" lib, docs, and build files. Please see the announcement I just sent out. HTH, Stjepan
Stjepan Rajko wrote:
Possibly. I'd like to see someone post (or better yet check into the sandbox) a set of Jamfiles that can be customized so that this would work smoothly -- if that's possible.
Jeff
Rene Rivera and I got started on a template processing system with a provided template for sandbox libraries, including a small "dummy" lib, docs, and build files. Please see the announcement I just sent out.
PS. I also just checked in some changes to boost/sandbox/boost-build.jam to make specifying the Boost and Boost.Build location easy. And some minor instructions to Jamfile.v2 at that location. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
AMDG Jeff Garland <jeff <at> crystalclearsoftware.com> writes:
This is a huge problem with the current sandbox organization. After spending a couple hours the other day trying to get boost.build to work in the sandbox tree I gave up in frustration and had to copy sandbox directories into my boost tree to use bjam. This is very annoying to say the least.
Jeff
I made it work for Units by putting <include>$(BOOST_ROOT) <include>../../.. in the test and example Jamfiles, and setting BOOST_ROOT appropriately in boost-build.jam and project-root.jam To build the documentation I had to make a few edits to Boost.Build. In Christ, Steven Watanabe
Steven Watanabe wrote:
AMDG
Jeff Garland <jeff <at> crystalclearsoftware.com> writes:
This is a huge problem with the current sandbox organization. After spending a couple hours the other day trying to get boost.build to work in the sandbox tree I gave up in frustration and had to copy sandbox directories into my boost tree to use bjam. This is very annoying to say the least.
Jeff
I made it work for Units by putting <include>$(BOOST_ROOT) <include>../../.. in the test and example Jamfiles, and setting BOOST_ROOT appropriately in boost-build.jam and project-root.jam
Interesting... Can you post your modified boost-build.jam and other files? As I recall now the I couldn't get bjam to recognize it's home in the main boost tree even though I set up the build home and tried other ways as well.
To build the documentation I had to make a few edits to Boost.Build.
Scary ;-) Jeff
Steven Watanabe wrote:
This is a huge problem with the current sandbox organization. After spending a couple hours the other day trying to get boost.build to work in the sandbox tree I gave up in frustration and had to copy sandbox directories into my boost tree to use bjam. This is very annoying to say the least.
Jeff
I made it work for Units by putting <include>$(BOOST_ROOT) <include>../../.. in the test and example Jamfiles, and setting BOOST_ROOT appropriately in boost-build.jam and project-root.jam
To build the documentation I had to make a few edits to Boost.Build.
You shouldn't have to do that: take a look at the sandbox/math_toolkit/libs/math directory, the project-root.jam in there let's you just set BOOST_ROOT to point to your main Boost tree and then away you go! No other modifications required. The only slightly tricky thing is refering to other libraries that are in your main Boost tree, but there are some examples for that as well :-) HTH, John.
John Maddock wrote:
To build the documentation I had to make a few edits to Boost.Build.
You shouldn't have to do that: take a look at the sandbox/math_toolkit/libs/math directory, the project-root.jam in there let's you just set BOOST_ROOT to point to your main Boost tree and then away you go! No other modifications required. The only slightly tricky thing is refering to other libraries that are in your main Boost tree, but there are some examples for that as well :-)
Excellent...I'll take a look at this. Thx! Jeff
Jeff Garland wrote:
Excellent...I'll take a look at this. Thx!
Ah, just a word of caution: there are some bbv1 files lurking in the root directory of the sandbox, I had to delete these to get things to work correctly. However, maybe the recent changes Rene has made has fixed this? John.
On May 25, 2007, at 9:24 AM, troy d. straszheim wrote:
So where should that stuff go? I'm accustomed to having "sandbox" identify a free-form area. 'sandbox-branches' isn't appropriate either. I think the current sandbox should actually be a subdirectory of sandbox called "projects".
Eventually, this stuff should just be a branch of the main development branch in, say, branches/boost-cmake. However, we don't want to do that before Boost development moves over to Subversion. So, for now, let's put everything in sandbox-branches/boost-cmake, knowing that it is wrong, and we'll fix it later. - Doug
Doug Gregor wrote:
On May 25, 2007, at 9:24 AM, troy d. straszheim wrote:
So where should that stuff go? I'm accustomed to having "sandbox" identify a free-form area. 'sandbox-branches' isn't appropriate either. I think the current sandbox should actually be a subdirectory of sandbox called "projects".
Eventually, this stuff should just be a branch of the main development branch in, say, branches/boost-cmake. However, we don't want to do that before Boost development moves over to Subversion.
So, for now, let's put everything in sandbox-branches/boost-cmake, knowing that it is wrong, and we'll fix it later.
Yep, makes sense. Here's to wishing that happens sooner rather than later :-) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
On Fri, May 25, 2007 at 09:18:10AM -0500, Rene Rivera wrote:
Doug Gregor wrote:
On May 25, 2007, at 9:24 AM, troy d. straszheim wrote:
So where should that stuff go? I'm accustomed to having "sandbox" identify a free-form area. 'sandbox-branches' isn't appropriate either. I think the current sandbox should actually be a subdirectory of sandbox called "projects".
Eventually, this stuff should just be a branch of the main development branch in, say, branches/boost-cmake. However, we don't want to do that before Boost development moves over to Subversion.
So, for now, let's put everything in sandbox-branches/boost-cmake, knowing that it is wrong, and we'll fix it later.
Done.
Yep, makes sense. Here's to wishing that happens sooner rather than later :-)
Yah. -t
troy d. straszheim wrote:
On Thu, May 24, 2007 at 10:39:33AM -0500, Rene Rivera wrote:
Yes, that's the structure for the sandbox <http://svn.boost.org/trac/boost/wiki/BoostSandbox>.
Whoops. Sorry about mussin' the dirs. Apologies for not having seen that page before.
Learn and live... for all of us :-)
a https://svn.boost.org/svn/boost/projects/a/trunk b https://svn.boost.org/svn/boost/projects/b/trunk c https://svn.boost.org/svn/boost/projects/c/trunk d https://svn.boost.org/svn/boost/projects/d/tags/stable-release
But those types of externals are exactly what are causing problems. They don't work for anonymous access. And since SVN doesn't handle relative/partial URLs they can't be fixed so that they work for both dev and anonymous users. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
On May 25, 2007, at 11:06 AM, troy d. straszheim wrote:
On Fri, May 25, 2007 at 09:22:32AM -0500, Rene Rivera wrote:
But those types of externals are exactly what are causing problems.
[snip]
Ach, this slipped by me, sorry. It's the http vs. https bit. I will look in to this. Maybe the pros at the OSL have some ideas.
I don't have any ideas, but I'm just an amateur. I'll ask around. - Doug
On Fri, May 25, 2007 at 09:22:32AM -0500, Rene Rivera wrote:
troy d. straszheim wrote:
On Thu, May 24, 2007 at 10:39:33AM -0500, Rene Rivera wrote:
Yes, that's the structure for the sandbox <http://svn.boost.org/trac/boost/wiki/BoostSandbox>.
Whoops. Sorry about mussin' the dirs. Apologies for not having seen that page before.
Learn and live... for all of us :-)
a https://svn.boost.org/svn/boost/projects/a/trunk b https://svn.boost.org/svn/boost/projects/b/trunk c https://svn.boost.org/svn/boost/projects/c/trunk d https://svn.boost.org/svn/boost/projects/d/tags/stable-release
But those types of externals are exactly what are causing problems. They don't work for anonymous access. And since SVN doesn't handle relative/partial URLs they can't be fixed so that they work for both dev and anonymous users.
It looks like something along the lines of svn:internals is in the works for subversion 1.5: http://www.svnforum.org/2017/viewtopic.php?=&p=6560 http://subversion.tigris.org/issues/show_bug.cgi?id=1336 meanwhile the solution is to put anonymous and developers everybody on the same "side" (scheme) of the server. Either: create a read-only anonymous account on the https side or, dump https and put the devs read-write accounts on the http side both of these things are straightforward to do. -t
participants (12)
-
David Abrahams -
Doug Gregor -
Douglas Gregor -
Jeff Garland -
John Maddock -
Michael Caisse -
Nicola Musatti -
Rene Rivera -
Stefan Seefeld -
Steven Watanabe -
Stjepan Rajko -
troy d. straszheim