Questions from a new user

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Questions from a new user

Boost - Build mailing list
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.
Since switching I appreciate how this new build system is more rigorous
and how it offers a better freedom.

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) ;

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? do I do things the incorrect way?
Am I supposed to edit project-config.jam whenever I want to use the
other toolset?

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" ;

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?
_______________________________________________
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: Questions from a new user

Boost - Build mailing list
On Sun, Sep 3, 2017 at 11:18 PM, JP Cimalando via Boost-build <[hidden email]> 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

_______________________________________________
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: Questions from a new user

Boost - Build mailing list
AMDG

On 09/04/2017 11:03 AM, Rene Rivera via Boost-build wrote:

> On Sun, Sep 3, 2017 at 11:18 PM, JP Cimalando via Boost-build <
> [hidden email]> wrote:
>
>>
> 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.
>

  The reason is most likely the creation of
the <flavor>mingw subfeature, which has always
caused problems when defining both mingw and
non-mingw toolsets.  I believe that the uses
of this have been cleaned up (replaced with
<target-os>windows), so it should be safe to
remove it.

In Christ,
Steven Watanabe

_______________________________________________
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: Questions from a new user

Boost - Build mailing list
In reply to this post by Boost - Build mailing list
On Mon, 4 Sep 2017 12:03:16 -0500
Rene Rivera via Boost-build <[hidden email]> wrote:

> First, welcome to B2 :-)

Thanks for helping.

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

I began with the version included in boost 1.63.0 which my Linux ships,
then moved to git master to check if it would fix my cross-compiler
trouble. That's still my current version as of now.
I also have a VM for Visual Studio which has 2016.03.
(if that's of any interest I published a script for windows binary
installer, here https://git.io/v5zvg)

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

Sure, please do.

> # 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.

It feels like being on right track yet I still can't make this work.
Looking at outputs of "b2 -d2" I obtain completely mixed up compiler
commands.

using gcc ;
using gcc : : i686-w64-mingw32-g++
 : : <target-os>windows ;
using gcc : : x86_64-w64-mingw32-g++
 : : <target-os>windows <address-model>64 ;

"b2 target-os=windows" gets me commands such as
    "g++" "i686-w64-mingw32-g++"   -O3 [....]
and the same with "address-model=64" added
    "g++" "i686-w64-mingw32-g++" "x86_64-w64-mingw32-g++"   -O3 [...]

> You can do this (with the current develop branch of gcc)
It is for gcc only right? (clang seems to reject such an option)
_______________________________________________
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: Questions from a new user

Boost - Build mailing list
On Mon, Sep 4, 2017 at 11:08 PM, JP Cimalando via Boost-build <[hidden email]> wrote:
On Mon, 4 Sep 2017 12:03:16 -0500
Rene Rivera via Boost-build <[hidden email]> wrote:

> # 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.

It feels like being on right track yet I still can't make this work.
Looking at outputs of "b2 -d2" I obtain completely mixed up compiler
commands.

using gcc ;
using gcc : : i686-w64-mingw32-g++
 : : <target-os>windows ;
using gcc : : x86_64-w64-mingw32-g++
 : : <target-os>windows <address-model>64 ;

"b2 target-os=windows" gets me commands such as
    "g++" "i686-w64-mingw32-g++"   -O3 [....]
and the same with "address-model=64" added
    "g++" "i686-w64-mingw32-g++" "x86_64-w64-mingw32-g++"   -O3 [...]

Do you get the same results if you use the "develop" b2 version? 

> You can do this (with the current develop branch of gcc)
It is for gcc only right? (clang seems to reject such an option)

Yes, it's only for gcc at the moment. I'm planning a clang rewrite soon though. So I'll add that option in at that point. 


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

_______________________________________________
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build