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