Re: [boost] [bjam] Trouble With Getting Started

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;