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

From: David Abrahams (dave_at_[hidden])
Date: 2003-04-21 10:37:44

Vladimir Prus <ghost_at_[hidden]> writes:

> 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 ;-)

Yes, all the tests pass (I assumed you'd be watching my checkin comments).

>> 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? 

IMO, yes. It makes writing and maintaining a toolset needlessly
difficult.

> 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. 

AFAICT, yes.

> Oh.. that adding :W should be simple, and it would solve all the
> problems 'cygpath' solves now.

AFAICT, yes.

>> 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. 

We might need the short and long variants, for example. We might also
need the inverse operation.

>> 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.

It's pretty hard to understand how this could be insoluble, isn't it?

>> 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?

Almost all comes from the shell, especially on Win98 where it's less
than 1K characters.

>> 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.

Third, build in support for more of the Cygwin path API:

http://cygwin.com/cygwin-api/func-cygwin-conv-to-posix-path.html

For example, might be enough.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com