Re: [bjam] Trouble With Getting Started

From: David Abrahams (dave_at_[hidden])
Date: 2005-08-21 15:05:18

Rob Stewart <stewart_at_[hidden]> writes:

> From: David Abrahams <dave_at_[hidden]>
>> Rob Stewart <stewart_at_[hidden]> 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:
>> 
>> http://www.boost.org/more/mailing_lists.htm#jamboost
>
> 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