[bjam] Trouble With Getting Started
Like some others writing recently, I found that http://www.boost.org/more/getting_started.html doesn't paint the whole picture. 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. 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? Another confusing aspect is where one should "install" boost. Upon downloading the tarball, where should one expand it? Once done, where should one tell bjam to install the files and how does that relate to where the tarball was expanded? There is no mention of the possible to simply install the header-only libraries. Perhaps that's not a supported option, but it should be. At the very least, there should be a way to install just the headers, without building any libraries, even if that includes headers for libraries that require a library. Then, folks can "install" Boost quickly, start using the header-only libraries and then, if desirable, go back and build the needed libraries. This would avoid the need to specify a toolset I think, so invoking bjam would be much simpler. 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. I created the directory and reran the command. Much to my chagrin, it then couldn't create d:/dev/boost/lib. I created that directory and reran the command. Finally, I thought, it needed but couldn't create "bin." Not "d:/dev/boost/bin" or some other fully qualified directory, but "bin." I tried creating d:/dev/boost/bin, but that didn't help. I didn't try creating $PWD/bin because I didn't really want files there. Since http://www.boost.org/more/getting_started.html doesn't mention a bin directory, I didn't know where else to create 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 This was in cygwin, so perhaps there's some confusion as to what should be on my path. At present, it's pretty simple: ~/bin:/bin:/usr/bin. Does bjam need more than that? If so, what? I don't know what MkDir1 is, so I was at somewhat of a loss. On a lark, I decided to set --builddir and rerun the command. I set it to d:/tmp/build and tried again. Lo and behold! It almost worked. The error then read: MkDir1 d:\tmp\build\bin spawn: No such file or directory That immediately made me wonder three things: 1. Why couldn't bjam create the bin subdirectory? 2. Why did bjam need to create a bin subdirectory instead of just using the directory I specified using --builddir? 3. Why didn't the error message indicate that "bin" was the --builddir value so I could know which parameter to manipulate? Well, the dance wasn't over yet. The next directory bjam wanted, but couldn't create was d:/tmp/build/bin/boost! Yes, I created that directory and tried again. Next I had to create d:/tmp/build/bin/boost/libs. Then it was d:/tmp/build/bin/boost/libs/date_time. I created that directory, too. Finally, I got this message: MkDir1 d:\tmp\build\bin\boost\libs\date_time\boost_date_time.dll spawn: No such file or directory At that point, I gave up. (No doubt I should have given up sooner!) Adding insult to injury were the interminable waits while bjam figured out over and over what needed to be done. Clearly, this isn't how things are supposed to work. Any ideas? -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
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: http://thread.gmane.org/gmane.comp.lib.boost.devel/124641 http://thread.gmane.org/gmane.comp.lib.boost.devel/126320 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?
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.
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. <snip rehash stuff>
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?
I created the directory and reran the command. Much to my chagrin, it then couldn't create d:/dev/boost/lib. I created that directory and reran the command. Finally, I thought, it needed but couldn't create "bin." Not "d:/dev/boost/bin" or some other fully qualified directory, but "bin." I tried creating d:/dev/boost/bin, but that didn't help. I didn't try creating $PWD/bin because I didn't really want files there. Since http://www.boost.org/more/getting_started.html doesn't mention a bin directory, I didn't know where else to create 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
This was in cygwin, so perhaps there's some confusion as to what should be on my path. At present, it's pretty simple: ~/bin:/bin:/usr/bin. Does bjam need more than that? If so, what? I don't know what MkDir1 is, so I was at somewhat of a loss.
On a lark, I decided to set --builddir and rerun the command. I set it to d:/tmp/build and tried again. Lo and behold! It almost worked. The error then read:
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.
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.
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?
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 b. The spawn message comes from the windows shell and is beyond bjam's control.
Well, the dance wasn't over yet. The next directory bjam wanted, but couldn't create was d:/tmp/build/bin/boost! Yes, I created that directory and tried again. Next I had to create d:/tmp/build/bin/boost/libs. Then it was d:/tmp/build/bin/boost/libs/date_time. I created that directory, too. Finally, I got this message:
MkDir1 d:\tmp\build\bin\boost\libs\date_time\boost_date_time.dll spawn: No such file or directory
At that point, I gave up. (No doubt I should have given up sooner!)
Adding insult to injury were the interminable waits while bjam figured out over and over what needed to be done.
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: http://www.boost.org/more/mailing_lists.htm#jamboost -- Dave Abrahams Boost Consulting www.boost-consulting.com
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;
Rob Stewart <stewart@sig.com> writes:
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.
No biggie.
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.
Yeah, I'm just trying to get you to direct your remarks at the new effort, that's all.
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.
Oh, I see what you mean. PREFIX should not be ALL_CAPS in that cell. It should be italicized (or, using boostbook, <replaceable>...</>). But, y'see, I don't want to spend any effort on fixing that document since it's doomed anyway.
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
Yes, but not _there_, IMO.
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
Really? 'Cause I didn't seen any messages about "couldn't create" whatever in your post.
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.
I don't think that's the problem.
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?
You have to rebuild bjam under cygwin. Just pretend you're on Unix and follow the directions to rebuild it.
Furthermore, since Getting Started talks about building under Cygwin, there is some means implied by which it should work.
Yes, it works with a Cygwin build of bjam
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.
No, bjam is pretty good about handling both kinds of slashes.
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.
I think that's right.
If so, what's the point of my giving it a unique directory name?
So you can control where the build products go. For example, if your boost is in a read-only directory, it had better not build into the bin/ subdirectory of your Boost installation. That's hard to fix. If you don't like the directory name "bin", well, that's simple; just rename it. Anyway, your results will all end up in subdirectories of bin, so I'm not sure controlling that name would be very satisfying for you.
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?
The current directory.
Without that, I can't figure out which disk is full or which parent directory is missing.
I don't think either of those things is the problem.
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."
Sheesh. Should it also say "unable to compile xxxx.cpp" and clarify why and where it is trying to create xxx.cpp? I'm pretty sure that after the "spawn: " message there should have been a command line printed that shows the actual mkdir command it was using to build. To understand all the error messages from bjam you have to know that all its commands are issued from the directory where bjam was invoked.
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.
Hah; I wouldn't bet on it! -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (2)
-
David Abrahams -
Rob Stewart