Re: [jamboost] cygwin bjam support of windows-based tools

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-04-21 09:36:24

David Abrahams wrote:
> Now that we've finally got msvc and borland to work properly under
> Cygwin, 

Does it work now? You did not tell ;-)

> I've come to the conclusion that it may be neccessary to build
> in some core jam support for windows-style paths. The alternative of
> using backquoted invocations of `cygpath` is simply too awful to
> tolerate (see tools/build/new/msvc.jam). This is important especially
> for users of older versions of windows (e.g. 98) with highly
> restricted command-line length. 

It's not nice, but is it intolerable? But read on...

> I suggest a new modifier :W which uses
> http://cygwin.com/cygwin-api/func-cygwin-conv-to-win32-path.html to
> convert paths to windows-native format under Cygwin and which is a
> no-op elsewehere. This should allow us to write a single version of
> most build actions without special-casing Cygwin.

Do I understand correctly that this function is available as just C routine 
for cygwin build of jam. Oh.. that adding :W should be simple, and
it would solve all the problems 'cygpath' solves now.

> I'm not diving right in to do it immediately because:
>
> 1. I want to make sure this is the only core change which is
> immediately needed, especially in the area of path
> translation. There are a number of other functions at
> http://cygwin.com/cygwin-api/cygwin-api.html which might be
> worth exposing.

So far I don't know what else we need. 

> 2. I am not sure that this is quite enough. As you can see from
> borland.jam, I eventually gave up on trying to run Borland's
> TLIB tool through the cygwin shell (I write/execute a .bat file
> instead) because it was getting confused by paths like
> "bin/lib/borland/link-static/auxilliary.lib". No matter how I
> quoted the path, the dash was being interpreted by TLIB as an
> option separator. 

I've had similiar problems, I recall, without any solution.

> On the other hand, it's important to run
> TLIB through the Cygwin shell to get around path limitations.
> I'd like to have a better understanding of this problem before
> adding core features.

I think I'm rusty on the topic. How much of path length limitation comes from
shell and how much from windows api?

> I'm also a bit nervous about the need to reset the TMP variable from
> the directory name it starts with to something like /tmp in order to
> make the tests succeed. I'm not clear where in the code that
> requirement comes from, but it might indicate a need for an inverse
> operation to :W (say, :C)? If anyone understands this problem, I'd
> appreciate some description of what's going on.

I understand. Suppose you have a target

/cygdrive/c/Docume~1/ghost/foobar 

Jam tries to find if it exists. In order to do it, it lists directory entries 
from /cygdrive/c, and find only "Documents And Setting" there. It gives up, 
and declared the target as nonexisting. For regular file targets, it means 
they will be repeatedly created. For directory target, it means "mkdir" will 
be invoked on a existing directory, and will fail.

The are two solutions. 
First is to disallow short paths. We have a code in pwd.c which makes short 
name of current directory into a long one, and on NT it's the only place 
where paths implicitly enter Jam. All other paths are given by user and we 
can require that long ones are provided (can we?)

Second is to make Jam recognize both long and short names. It means that 
during reading directory it will get short names and add them to the list as 
well. It does not look hard, but remembering twice as many names looks wrong 
to me. Probably, we can ask on jamming ml how short names are usually 
handled.

- Volodya