From: Mat Marcus (mat-lists_at_[hidden])
Date: 2008-04-15 17:18:43
Roland Schwarz writes:
mat> 3) suggested that what I want to do, and was able to do in
mat> 1.34.1, is cross-compilation and therefore an unreasonable
mat> thing to ask for
roland> This is what I said:
roland> I think what you are trying to do is some kind of cross
roland> building with the mingw compiler for the cygwin
roland> environment, yes?
I was referring to a different comment that you made. That is, when I said:
mat> Mat Marcus wrote: My goal is to restore the state of affairs
mat> to that of 1.34.1: the user didn't need to make any explicit
mat> mention of the threadapi or target-os on the command line or
mat> in the user-config.jam.
roland> I don't think this goal is reasonable.
roland> You are doing essentially a cross compile, so you need to
roland> specify the essential parts, which is <target-os> and
In any case, since Rene already answered my question, I will drop
mat> 6) asked anthony not to fix what he might have regarded as a
mat> bug in his thread jamfile without talking to you first
roland> I asked this because 1) I wrote it.
Ok, that clarifies a few things. In that case, I will try to work with
a bit more you to help you understand an alternate point of view.
mat> If so, great. My question is, what must I do to restore the
mat> ability to use the following command line in 1.35.0:
mat> bjam debug release gcc-4.2.0 msvc-8.0 msvc-9.0
roland> This indeed is possible, but 1) you need to decide which
roland> threading api you want.
Why do I *need* to decide? I think that the ability to select either
threading model is a laudable improvement. On the other hand, I don't
see why we can't also pick some defaults that work when the user
doesn't explicitly want to select a threading model (as was the case
roland> 2) you need to separate the case whether you build from
roland> bash or from cmd.
This is one of the points on which we differ most. Why should the
shell used determine the nature of the artifacts produced by a build
system? Why should the compiler used to create bjam affect the choices
of threading model in the built artifacts? I build cross-platform
libraries. I typically use some version of msvc on windows and some
version of gcc on the mac. I invoke
bjam debug release gcc-4.2.0 msvc-8.0 msvc-9.0
from my bash shell in cygwin. Ensuring that the gcc-4.2.0 builds are
ok on windows reduces the number of surprises when I move the code to
the mac and compile with the darwin toolset. I have no desire to
change my workflow to write new scripts to use separate shells or
separately compiled versions of bjam in order to build with separate
compilers. Also, I also build using the cmd shell from time to time,
to make sure my users can do the same.
roland> From your previous posts I deduce you have only msvc built
roland> bjam. This implies one important consequence: It
roland> determines the OS boost-build thinks it is on.
roland> Even when you invoke from bash. You really be better off
roland> to get your cygwin built bjam and get it picked up from
roland> e.g. /usr/local/bin.
I don't view cygwin as an OS. I view it as a shell, a compiler, and a
set of tools that is useful when running windows OS, under whichever
shell, and I claim that it is a bug for Jamfiles to depend on how bjam
was compiled. Not to mention the fact 1.35.0 seems to have broken
cygwin-gcc (not mingw) builds under my configuration and that, last I
checked, the msvc-built bjam was the only one that supported both msvc
and gcc toolsets.
roland> I continue with building from cmd. Again from your
roland> previous posts I have learned that the gcc you are using
roland> is not a mingw. And there the next problem arises: gcc
roland> wants to use cygwin dll by default. You can switch this
roland> off however: The switch (which is unfortuantely
roland> undocumented, don't aks me why) is -mno-cygwin. This
roland> should make your gcc try to link against mingw dll and
roland> msvc rt dlls.
Why are you saying that it is a problem to use cygwin dll? I
understand that some users may not wish to use it, but this is not a
problem for me. I don't wish to link against mingw dll or msvc rt dlls
at present. Can we eliminate mingw from the discussion now?
roland> To sum up: While your setup should work in principle it
roland> is not very solid when you are not exactly trying to find
roland> out what is going on under the hoods.
I view it as: my setup was working fine in 1.34.1. But then you made
some changes to the boost thread jamfile that made threads depend on
how the bjam tool was compiled, introducing what I would claim
is a 1.35.0 bug.
roland> I recommend
roland> 1) Using the mingw compilers and mingw (or msvc) built
roland> bjam when compiling from cmd.
This is a fine use case. But it is not the only one, and it is not mine.
I don't wish to see the other use cases broken in order to support it.
roland> 2) Using cygwin gcc and bjam built from bash with cygwing
I argue that, while it may make implementor's lives easier, it does
not benefit users to have to compile different versions of bjam in
order to use different toolsets.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk