From: Rob Stewart (stewart_at_[hidden])
Date: 2005-08-21 11:31:25
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. 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:
>
> 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.
-- Rob Stewart stewart_at_[hidden] Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;