Steven Watanabe wrote:

...

Does anyone have an idea why b2 looks for the tools/inspect Jamfile?

I seem to recall that someone (Beman maybe?) used inspect in his test Jamfile.

No, it's probably this part of Jamroot: if [ path.exists $(BOOST_ROOT)/tools/inspect ] { use-project /boost/tools/inspect : tools/inspect/build ; } tools/inspect does exist as an empty directory in a freshly cloned superproject. This should probably be if [ path.exists $(BOOST_ROOT)/tools/inspect/build ]

Vladimir Prus wrote:

On 21/05/2016 16:51, Peter Dimov wrote:

...

Steven Watanabe wrote:

...

...

Does anyone have an idea why b2 looks for the tools/inspect Jamfile?

I seem to recall that someone (Beman maybe?) used inspect in his test Jamfile.

No, it's probably this part of Jamroot:

if [ path.exists $(BOOST_ROOT)/tools/inspect ] { use-project /boost/tools/inspect : tools/inspect/build ; }

tools/inspect does exist as an empty directory in a freshly cloned superproject. This should probably be

if [ path.exists $(BOOST_ROOT)/tools/inspect/build ]

Fair enough; I've pushed such a change to develop - could you give it a try?

Seems to work now, thanks. I'm setting up Travis/Appveyor and trying to keep the submodules to the minimum necessary: https://github.com/boostorg/core/blob/develop/.travis.yml which is how I spotted it. There's one additional problem, Boost.Build requires Boost.Config to be present: error: Could not find a Jamfile in directory 'libs/config/checks/architecture'. This is mostly theoretical, because the only library that doesn't need Config anyway is Predef, but it still feels a bit wrong. :-)

On Sat, May 21, 2016 at 3:49 PM, Peter Dimov wrote:

I'm setting up Travis/Appveyor and trying to keep the submodules to the minimum necessary:

https://github.com/boostorg/core/blob/develop/.travis.yml

You might be interested in the work I've been doing to have a common CI testing script. The goal is to support testing all libraries, individually, against a particular Boost version (develop, master, etc). It's Python so it can handle a bit more logic than easily than sh. And it's currently used by Predef for its CI testing. Checking out the subset of Boost that a library requires is something I've had on my todo list. If you are comfortable enough with Python it would be great if I could get help in adding features to it :-) -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

Rene Rivera wrote:

...

You might be interested in the work I've been doing to have a common CI testing script. The goal is to support testing all libraries, individually, against a particular Boost version (develop, master, etc). It's Python so it can handle a bit more logic than easily than sh. And it's currently used by Predef for its CI testing. Checking out the subset of Boost that a library requires is something I've had on my todo list. If you are comfortable enough with Python it would be great if I could get help in adding features to it :-)

Forgot to provide the link: < https://github.com/boostorg/regression/blob/develop/ci/src/script.py>.

I actually did look at Predef's .travis.yml, but didn't "follow the link" to the script at the time. :-) Predef is a bit of a special case because it can be tested standalone, most of the libraries need the superproject and their dependencies checked out. I also looked at Antony's script https://github.com/boostorg/any/blob/develop/.travis.yml which does check out the whole superproject (and moves the current directory into its proper place); it also appears to be generic. I however didn't want to use the CI matrix and boot many VMs when one could do. My appveyor.yml for instance has b2 libs/bind/test toolset=msvc-9.0,msvc-10.0,msvc-11.0,msvc-12.0 and if I at some point decide to improve the Travis script to test multiple g++ versions and multiple c++ dialects (-std=c++03/11/14...) I would also prefer to use one run for them, and none of the .yml scripts currently in Boost do this. Re

If you are comfortable enough with Python

Python is not exactly my forte. I was thinking of rewriting bpm to issue the appropriate git commands. Something like bpm init develop bpm install -t bind@SHA bpm test bind Although I have a deadline incoming and I should really stop fiddling with this while Rome burns. :-) By the way, do we really need to package a release on every commit to develop? :-)

Rene Rivera wrote:

...

bpm init develop bpm install -t bind@SHA bpm test bind

I dislike using C++ for these kinds of tools.. The requirement to compile them makes it cumbersome.

Yes, there is that. The above as written will only work with a prebuilt binary, which is basically only feasible on Windows.

On Mon, May 23, 2016 at 5:19 PM, Peter Dimov wrote:

Rene Rivera wrote:

...

...

By the way, do we really need to package a release on every commit to > develop? :-)

Yes, it's needed. It's how I reduce the likelihood that merging to master will still work for the actual releases. We've had enough problems in the past with this last step not working that I'm ok with it running all the time.

Now that I took a second and third look, it occurs to me - and this may well be your plan - that the "ci_boost_status.py" part can actually parse the commit message ("Update foo, bar from develop") and then checkout foo, bar and their testing dependencies and run

b2 libs/foo/test libs/bar/test toolset=...

which would actually make it unnecessary for every library to add its own travis/appveyor integration. We'll just need to route the email notification to the proper person, or perhaps setup a dedicated mailing list for that, or do both.

Not my original plan.. But I like it. Actually... we could checkout the whole Boost, without dependency analysis,

as a first step, and deal with dependencies later. The other VMs do that anyway. :-)

Yeah.. We could do that, with the above easily enough. This does not entirely replace per-library travis/appveyor integration

because it will not test the library pull requests, but on the other hand, it requires zero effort on part of individual maintainers. And that is the outdated, Boost 1.x way, is it not? :-)

Right.. Although it would certainly be nice to have consistent CI handling. My plan was to write a script that authors could use if they like to easily configure their library to use CI testing (for both Travis and Appveyor). I.e. it does everything by just adding and editing the config file to their library (and me turning it on in the global boostorg accounts). I figured authors would happily add those config files to get the benefit with almost no work on their part :-) -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

On Sat, May 21, 2016 at 9:41 AM, Steven Watanabe wrote:

AMDG

On 05/21/2016 07:19 AM, Peter Dimov wrote:

...

I'm experimenting with a partial Boost clone, the superproject, tools/build, libs/bind, libs/config and few others, and when trying to build the tests, I'm getting the following error:

D:\tmp\boost\libs\bind\test>..\..\..\b2 toolset=msvc-10.0 D:/tmp/boost/tools/build/src/build\project.jam:262: in find-jamfile from module project error: Unable to load Jamfile. error: Could not find a Jamfile in directory '../../../tools/inspect/build'. <snip> Does anyone have an idea why b2 looks for the tools/inspect Jamfile? I don't remember this being a problem before when I tried a stripped-down installation.

I seem to recall that someone (Beman maybe?) used inspect in his test Jamfile.

Yes, but that ended up being a failed experiment, so you can remove the dependency as far as I'm concerned. Thanks, --Beman