From: Mat Marcus (mat-lists_at_[hidden])
Date: 2008-04-15 18:42:18
On Tue, Apr 15, 2008 at 3:11 PM, Roland Schwarz
> Hi Mat,
> you are making alot of good points, one I favour most:
> *) don't break anything.
> However unfortunately the situation is far from ideal.
> Didn't someone in this thread say the compiler should determine the
> thread api? Do you know a reliable method? If so please
> tell me. (I am not talking about macros here, we do not have
> access to these.) Until then I use the approximation that
> bjam gives me and rely on users tweaking their setup for
> unusual setups. By unusual I mean: look at the boost regression
> pages and try to find out how common your setup is.
I'm not a boost build expert, so please allow the following naive
question: Is the problem that on windows the same toolset (gcc) might
want a different default threadapi according to whether or not it is a
mingw gcc? Or is the situation more complex?
> What complicates things is, I am not the maintainer of gcc.jam.
> gcc.jam already has a big load on it. It cannot omit any of the
> gcc variants and also needs to deal with a stranger, i.e. mingw
> compiler. Of course it is not a cross compiler, but perhaps it
> is a good aproach to view it in this light.
> It is hairy to change it without risk of break on some seemingly
> unrelated platform.
> I tried my best to to get at "make it just work". Ok I admit I
> failed for your case. Others so far can use the setup, and so can I.
> So what shall we do? Can you possibly supply not only a suggestion
> of how it should work, but also how to implement it?
> If so, please do.
Sorry if it seems otherwise, but I am in fact attempting to
contribute. My first order of business was to decribe the complex
issues involved, establish that there was a bug and to find a
workaround. Now that that's been square away, I am tyring to do what I
can to help find a solution.
> Do you mean I should drop support of pthread for mingw and msvc builds?
Of course not. Nor do I wish to claim that my particular use cases
must be supported with the minimum of user effort.
> If not please stick with Renes advice until a solution is found
> that will also work for your environment without heavy user-config.jam
Yes, I will do so.
> I admit it would be nice if everything goes auto-config like.
> Still we are not there yet.
Sure. The urgency of my request faded when Rene answered my orginal
question. Now I am trying to be a good citizen by writing up the
appropriate bugs and drawing attention to use cases from the field
that were inadvertently broken. And to help if I can.
> Btw. this is what I am doing most of the time. My user config
> already contains lot of code to work around certain deficiencies,
> I was not able yet to convince the maintainers to implement.
> Also I did not complain, instead started to look into the problems
> and tried to help solve some of them.
I reported a bug, asked for help and thanked those who helped me. A
bug report is not a complaint. I did complain about your initial
responses to my attempt to get to the bottom of things, but I am
hoping that we are past that now.
> Btw. I just succeded building bjam both from 1.35.0 and trunk.
> Possibly you can check if your self compiled gcc does not work
> as you expect?
> Regards Roland
I tried this with both the cygwin-supplied gcc-3.4.4 and with a
chand-compiled gcc-4.2.0 with similar results. I pasted the results
for gcc-3.4.4 in another thread, and posed the question: what does
expand.c want l->string to be at the point where it asserts that it
must not be C:\foo\bar ?
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