On Tue, Apr 22, 2008 at 3:27 PM, Roland Schwarz <roland.schwarz@chello.at> wrote:

Vladimir Prus wrote:

...

You can use cygwin gcc in both cygwin mode and -mno-cygwin mode. What default threading api do you expect for the latter case, and can it be inferred in any way from output of -dumpmachine?

The default api possibly should be win32 in the latter case. In principle it could be infered from -dumpmachine by evaluating the flavor which would be in that case: i686_pc_mingw32

When building gcc from sources under cygwin, one begins with a call to configure. I recently used the following invocation: configure --enable-threads=posix --disable-bootstrap --prefix=/opt/gcc-4.3.0 --enable-languages=c++ Actually, at first I mistakenly forgot to pass an --enable-threads parameter. I was made aware of this when I tried to build boost and found that the BOOST_DISABLE_THREADS was being #defined (good auto-detection work by the boost/config machinery I presume). After starting over by configuring gcc with --enable-threads=posix before building it all was well. Now I haven't tried this, but preliminary googling tells me that it is also possible to configure gcc with --enable-threads=win32. My first questions are: 1) Does setting --enable-threads=win32 affect the eventual output of -dumpmachine? 2) If not, how could such a gcc fit into the flavor scheme? You may tell me that --enable-threads=win32 cannot be made to work without also setting other flags until one ends up with what is essentially a mingw compiler, but I haven't studied things carefully enough yet to see whether this is true. Stepping back a little, a more fundamental question occurs to me: 3) Why does the thread Jamfile.v2 need to know the default threading model? Here's why I ask: (What follows may be wrong, since I don't know all the corners of the build system.) Today, for example, if I compile on a powerpc mac without specifically selecting the architecture or address-model, I get no mention of either in my paths or in my mangled library names. The build system will silently use the architecture of the host machine. If I compile the same code on an Intel mac, the build system uses the same folder and library names IIUC, but the generated code will use x86 instructions. I believe one has to parse the output from a tool that lives outside of the build system, such as arch, to determine what the resulting instruction set will be in this scenario. That is, I'm not aware of a way to treat the default architecture as a property that can be used in conditionals, except in the case where the user specifically asks for, say, architecture=x86. Am I correct here? Maybe this isn't just a mac issue. If the user doesn't explicitly mention target-os I am unaware of how to successfully add library usage-requirements like: <toolset>gcc,<architecture>x86: <instruction-set>i486 ## require intrinsic support for patched cygwin compatible Intel TBB 4) If I'm wrong here, how do I do this? This is actually coming up in our code base today Ideally I'd like to be able to narrow this to a conditional that implements: IF (toolset = gcc and target-os = cygwin and architecture = x86) then ensure that instruction-set is at least i486 but I'm unaware as to how to do it. In any case, the point of all this is that, from what I can gather, the build system really doesn't have all of this information at present. This leads me to ask: 5) Would it be possible or desirable to give up a little 'safety' in return for a simpler thread Jamfile? Such a Jamfile would only add the state of the threadapi feature (different from none) to the path in the case when the user explicitly sets threadapi. This way it wouldn't have to try to (imperfectly) duplicate the logic in the boost/config headers, but it could still offer a way for the user to manually override them when necessary. I can see several benefits if the answer to question 5 turns out to be yes. A) Thread's Jamfile's dependence on who compiled the bjam.exe tool would go away B) Maybe some of the need for enhanced flavor support is lessened (I have no idea whether this is true) C) Paths could be made somewhat shorter and shell independent I would like to digress for a moment to relate a small anecdote about how long paths are not simply an aestehetic nuisance, but can increase development costs. Currently to be able to use 1.35.0 threads from an msvc-compiled bjam under from bash, I have to have my users add toolset.add-requirements <toolset>gcc:<target-os>cygwin <toolset>gcc:<threadapi>pthread ; to their user-config.jam While allowing threads to build, in our environment this has the side-effect of producing paths like the following: C:\opensource\sanbox\joeuser\sandbox\built_artifacts\test\ unit_tests\copy_on_write\copy_on_write_test.test\gcc-4.3.0\debug\ architecture-x86\asl-dev\instruction-set-i486\link-static\ target-os-cygwin\threadapi-pthread\threading-multi\ copy_on_write_test.exe Yesterday this bit us. Apparently, on some users' machines the full path length exceeds the cygwin/XP limits and the executable can not be run! So the tests in our Jamfile were mysteriously failing. One remedy here seems to be to use shorter paths for our own features, directories and project names. Another is to try to pass --abbreviate-paths to bjam to drop a few vowels from the paths. A third is to perhaps use a cygwin-built bjam. For various reasons none of these have much appeal, though I'll do what I can. Ideally, though, I'd like target-os-cygwin and threadapi-pthread to disappear from the path, since they don't add much value for me. In fact, I argue that they remove value, since they are not present in the paths that I get if I happen to choose a cygwin-compiled bjam.exe, so I end up with two needlessly incompatible trees of artifacts. This has been a long email with several different kinds of questions, and a number of guesses about the behavior of the build system. Some of my assumptions are undoubtedly wrong. But, if there is interest, I'd like hear several other people's thoughts on these issues. And of course answers to any of my questions are most welcome. -Mat