On Sun, Sep 3, 2017 at 11:18 PM, JP Cimalando via Boost-build <boost-build@lists.boost.org> wrote:

Hi,
I am a new user attempting a transition from CMake to Boost.Build,
and I want to ask some questions to which I couldn't find answers in
the manual.

First, welcome to B2 :-)

Second, are you getting B2 from the develop branch, or some place else?

Since switching I appreciate how this new build system is more rigorous
and how it offers a better freedom.

Can I quote you on that? For publicity that is. I'm keeping track of such quotes for future use on the web site.

1. Cross-compilation.
Let's say I defined some toolsets in the project configuration.
using gcc : host : g++ : $(gcc_colors) ;
using gcc : mingw32 : i686-w64-mingw32-g++ : $(gcc_colors) ;

For gcc I usually leave the "version" arg, i.e. the second one, blank as the gcc toolset can interrogate the version directly.

This allows me to build with either command "b2 toolset=gcc-host" or
"b2 toolset=gcc-mingw32 target-os=windows". However...

The first configuration incorrectly defines the build dir as
"bin/gcc-mingw-gnu-host". If I comment the second toolset, the build
dir goes back to normal "bin/gcc-gnu-host". As curious as this is, it
still seems to produce a correct build.

So what is this, a benign anomaly?

That's definitely an anomaly. We should find out why it's doing that and fix it. Question

do I do things the incorrect way?

Depends on what your goals are. It looks "correct". But perhaps not ideal. If it's cross-building choice that you are after.. I prefer adding a condition to configuration that selects the particular gcc based on the target-os feature [1]. You can do this (with the current develop branch of gcc) as such:

# Regular host-os is target-os compiler..

using gcc ;

# Cross compiler..

using gcc : : i686-w64-mingw32-g++ : : <target-os>windows ;

And doing "b2 toolset=gcc target-os=windows" should pick up the second one. If you only have gcc, you can even leave out the "toolset=gcc" argument.

Am I supposed to edit project-config.jam whenever I want to use the
other toolset?

Definitely not.

2. I want my build to generate some sources using tools which are also
built as part of the project. These tools should be generated using the
host compiler to support cross compiling.
I solve this by making two separate projects, but is there a way to
integrate the two in a single build and make them properly dependent?

This is an example of what it looks like.

# Jamroot.jam
path-constant MY_TOOL : "tools/dist/my-tool" ;
actions my-tool {
$(MY_TOOL) $(>) > $(<)
}

# tools/Jamroot.jam
exe my-tool : "my-tool.cc" ;
install tools : my-tool : <location>"dist" ;

I don't have a concrete answer for you on this one. As this is not something I've done myself.

3. Is there already some facility to substitute text in *.in files, in
the same fashion as GNU's AC_SUBST or CMake's configure_file?

Nothing built-in AFAIK. You could use a "make" target to run whatever you want though. But I'd be interesting in adding a tool to do this if something appropriate was multi-platform available. It could theoretically be done with the built-in regex search/replace. But that would take some thinking as to what the use case is more carefully.

[1] I also notice that the docs current suggest using the version argument for the cross-compile case. I should amend that for the better way.

-- Rene Rivera
-- Grafik - Don't Assume Anything
-- Robot Dreams - http://robot-dreams.net
-- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail