From: David Abrahams <dave@boost-consulting.com>
Rob Stewart <stewart@sig.com> writes:
Like some others writing recently, I found that http://www.boost.org/more/getting_started.html doesn't paint the whole picture.
It's great that you're getting involved with this, but you really should be connecting with Andrey Melnikov and Hendrik Schober, who are supposedly working on a rewrite. Editorial comments on a document that is about to be replaced are not necessarily going to have much of an impact. Much of what you write below is a rehash of stuff we've already discussed. In fact, you were clearly involved in the thread: [snip] As you can see, unless someone actually *does the work*, the best editorial comments in the world won't have an impact. I know Schobi got overwhelmed, and I'm sure Andrey could use some help with the English language part. Why don't you throw in with them?
I might be able to assist them, but that is a different matter. First, I didn't recall the points I made as having been made before. If they were, I'm sorry for the noise. Second, my noting problems with the document *can* help in their efforts because if they weren't changing the things on which I commented, now they might.
In step five, the table describing the actions was a bit confusing. Some options were described with "<something>" values and others with "SOMETHING" values. I thought the latter were e-var references at first.
They are, in fact, or can be; bjam picks up all the environment variables when you run it.
When I set (and exported) $PREFIX, it was ignored. Only --prefix worked.
Also in that table, there is mention of cygwin as a special case. Elsewhere, only *nix and windows are mentioned. Is cygwin considered *nix or windows in those other contexts?
Unix. I don't think that needs to be specially explained there, although it should be explained that bjam acts like Cygwin is Unix if you build bjam under the Cygwin shell, but a Windows build of bjam can still build things using the Cygwin tools.
It does need to be mentioned because I didn't know how it was treated. For example, when I went to download bjam, I didn't find a Cygwin version. I was left with choosing a Linux version or a Windows version if I didn't build my own. I tried the Windows version since Windows doesn't run ELF executables, so the Linux version didn't seem applicable. Still, I wondered if there was a special build for running within Cygwin.
Now for the real problem: When I ran bjam -sTools=gcc --prefix=d:/dev/boost install, I was surprised to find that bjam wouldn't create that directory.
Did you get an error message saying it couldn't create _that_ directory? If not, why did you presume that was the problem?
The first error message said it couldn't create C:\Boost which was good because that's not where I wanted the output. That's when I figured out the need for --prefix. Given that it couldn't create C:\Boost, I went ahead and created d:/dev/boost. After creating d:/dev/boost, bjam couldn't create the next directory. So, I'm certain it would have complained about d:/dev/boost if I hadn't created it.
So, I could't seem to get bjam to build anything and it wasn't helping me to understand what was wrong. The error message was simple:
MkDir1 bin spawn: No such file or directory [snip] MkDir1 d:\tmp\build\bin
You're clearly using a Windows build of bjam to build under a cygwin shell. That isn't going to work out... although maybe we should make it work.
So what build should I use? Furthermore, since Getting Started talks about building under Cygwin, there is some means implied by which it should work.
spawn: No such file or directory
That immediately made me wonder three things:
1. Why couldn't bjam create the bin subdirectory?
Unclear. problames from spawn usually mean there was something wrong with the command line. Please try adding -d+2 to your bjam command-line.
In the light of another day, it occurred to me that the confusion may have stemmed from using *nix-style forward slashes as arguments to a Windows program. I tried switching to \\ instead of / but it didn't help.
2. Why did bjam need to create a bin subdirectory instead of just using the directory I specified using --builddir?
Because that's the way it works. Why do you care what it creates underneath your builddir?
Because I told it where to build the files. My comment is based upon the assumption that the --builddir I name will be empty except for a "bin" subdirectory. If so, what's the point of my giving it a unique directory name? If not, then I've spoken out of turn.
3. Why didn't the error message indicate that "bin" was the --builddir value so I could know which parameter to manipulate?
a. I'd say
MkDir1 bin spawn: No such file or directory
pretty clearly indicates where the problem is
That's a relative path. What's it relative to? Without that, I can't figure out which disk is full or which parent directory is missing.
b. The spawn message comes from the windows shell and is beyond bjam's control.
OK. Still, bjam could add something like "Unable to create "bin" subdirectory under the build directory, "d:/tmp/build," and clarify why and where it was creating "bin."
Clearly, this isn't how things are supposed to work. Any ideas?
Lets' see the output with -d+2. Heck, add -d+4 too, for good measure. And let's take this over to the jamboost list:
I've gone through all of the hassles to sign up with Yahoo now, which I wasn't interested in doing last night. I still have to figure out how to reply to this message and send the debug output you want. In the meantime, since you cross-posted your reply, I'm hoping this message will make it to the jamboost list even though I used a different e-mail address to be a member of the group. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;