Re: [Boost-build] RFC: Rootless projects..

Subject: Re: [Boost-build] RFC: Rootless projects..
From: aaron_at_[hidden]
Date: 2015-06-16 11:08:44

I have two use cases for such a feature:

1) In order to test our custom boost.build jam library I have created a repo that contains boost.build as a submodule as well as submodules for all of the tools and extra libs that it needs. I am using BoostBuild.py for the system testing which creates the temp files in the temp directory. The directory structure of each is similar to the following:

some/where/to/test_repo/
    boost.build/
    libs/
        some_lib/
            build.jam
    tests/
    tools/

dynamically/created/directory/to/temp/TestProject/
    Jamroot.jam
    tests/
        build.jam
        my_test/
            build.jam

Our jam library provides support for our unit testing framework. That framework exists in test_repo/libs/some_lib and there is a use-project that points to the build.jam in that framework. In order to be able to call use-project on some_lib's build.jam, a Jamroot.jam must exist somewhere in its parent hierarchy. I currently have created an empty Jamroot.jam in the test_repo to satisfy that condition.

2) In the event that I want to make a library available to install via a package manage (like apt-get) and provide boost.build support, it would be nice to include a build.jam with that library. The way it currently stands, i would also have to create a wrapper directory structure that contains a Jamroot.jam so that I can actually point to the library's build.jam

I know that Boost.Build's primary focus is for the Boost library itself, but it would be nice in the event that it's being used for other libraries :)

Aaron

> -------- Original Message --------
> Subject: Re: [Boost-build] RFC: Rootless projects..
> From: Vladimir Prus <[e-mail]>
> Date: Tue, June 16, 2015 7:41 am
> To: [e-mail]
>
> On 6/11/2015 5:13 PM, Rene Rivera wrote:
> > The use case is one that I've run into since the git transition and doing Predef development. And recently I
> > also see it in the BPL development. For Predef my normal way to work on it is to clone *only* the Predef repo as
> > it's an entirely standalone library (doesn't depend on anything). Then I have a jamroot file above the cloned
> > Predef, as it's required to build anything with BBv2. It's easy enough for me to do this of course. But I would
> > like to make it easier for *users* to just get the Predef library and say, run tests and build without special
> > instructions or having the whole of the Boost super project. But at the same time I can't just include a jamroot
> > in the Predef project because it would break (in silent and strange ways) when it's part of the Boost super project.
>
> Rene,
>
> could you describe in more detail how you envision this feature to be used? While predef is entirely standalone,
> that does not appear to be a typical case, so I think we need to decide how a typical case should work, and
> optimize for that case.
>
> Say, a Boost library can be built either inside the tree, or outside the tree. In the former cases, it 
> automatically gets access to:
>
> - Requirements from Boost's Jamroot
> - constants
> - helper functions
>
> In the standalone case, how would a library access all that?
>
> Thanks,
> Volodya
>
>
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build