Cygwin and PATH

We have a ticket in Boost Trac about need to set
PATH when using cygwin gcc:

	http://sv
n.boost.org/trac/boost/ticket/1041

Unfortunately, cygwin is already at the bottom of my
list of important toolsets, and using cygwin gcc from
cmd.exe makes it even worse.

So, it's not likely I'll get to this issue in the nearest 10
years.
Anybody wants to adopt the issue, or should I wontfix it?

- Volodya
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

Vladimir Prus wrote:
> We have a ticket in Boost Trac about need to set
> PATH when using cygwin gcc:
> 
> 	http://sv
n.boost.org/trac/boost/ticket/1041
> 
> Unfortunately, cygwin is already at the bottom of my
> list of important toolsets, and using cygwin gcc from
> cmd.exe makes it even worse.
> 
> So, it's not likely I'll get to this issue in the
nearest 10 years.
> Anybody wants to adopt the issue, or should I wontfix
it?

I assigned it to myself, but here's the more general
plea/explanation on 
why fixing this is important... It's not really a problem
for Cygwin 
only. In general the gcc toolset, and most others, don't do
what the 
msvc and other Windows toolsets of doing precommand setup.
It's a 
general pattern that it seems to me should be handled
generically like 
the CONFIG_COMMAND var. Regardless... I'm fine with doing
this myself 


-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software
.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

Rene Rivera wrote:

> Vladimir Prus wrote:
>> We have a ticket in Boost Trac about need to set
>> PATH when using cygwin gcc:
>> 
>> http://sv
n.boost.org/trac/boost/ticket/1041
>> 
>> Unfortunately, cygwin is already at the bottom of
my
>> list of important toolsets, and using cygwin gcc
from
>> cmd.exe makes it even worse.
>> 
>> So, it's not likely I'll get to this issue in the
nearest 10 years.
>> Anybody wants to adopt the issue, or should I
wontfix it?
> 
> I assigned it to myself, 

Thanks!

> but here's the more general plea/explanation on 
> why fixing this is important... It's not really a
problem for Cygwin
> only. In general the gcc toolset, and most others,
don't do what the
> msvc and other Windows toolsets of doing precommand
setup. It's a
> general pattern that it seems to me should be handled
generically like
> the CONFIG_COMMAND var. Regardless... I'm fine with
doing this myself 

Why do you think it's necessary? With msvc, there's that
vcvars script,
whereas with gcc, it was not required so far.

- Volodya


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

Vladimir Prus wrote:
> Rene Rivera wrote:
>> but here's the more general plea/explanation on 
>> why fixing this is important... It's not really a
problem for Cygwin
>> only. In general the gcc toolset, and most others,
don't do what the
>> msvc and other Windows toolsets of doing precommand
setup. It's a
>> general pattern that it seems to me should be
handled generically like
>> the CONFIG_COMMAND var. Regardless... I'm fine with
doing this myself 
> 
> Why do you think it's necessary? With msvc, there's
that vcvars script,
> whereas with gcc, it was not required so far.

Simple math... Currently this handling is implemented in N
toolsets, and 
not implemented in M toolsets. Now, and in the future, we
need to 
implement it for N+X toolsets. Having some common support
for this 
functionality not only saves part of the X work but reduces
the work 
needed to maintain N toolsets. Hence we save C*(N+X) amount
of work over 
both development, testing, and maintenance.


-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software
.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

On Thursday 12 July 2007 19:38:36 Rene Rivera wrote:
> Vladimir Prus wrote:
> > Rene Rivera wrote:
> >> but here's the more general plea/explanation
on 
> >> why fixing this is important... It's not
really a problem for Cygwin
> >> only. In general the gcc toolset, and most
others, don't do what the
> >> msvc and other Windows toolsets of doing
precommand setup. It's a
> >> general pattern that it seems to me should be
handled generically like
> >> the CONFIG_COMMAND var. Regardless... I'm fine
with doing this myself 
> > 
> > Why do you think it's necessary? With msvc,
there's that vcvars script,
> > whereas with gcc, it was not required so far.
> 
> Simple math... Currently this handling is implemented
in N toolsets, and 
> not implemented in M toolsets. Now, and in the future,
we need to 
> implement it for N+X toolsets. Having some common
support for this 
> functionality not only saves part of the X work but
reduces the work 
> needed to maintain N toolsets. Hence we save C*(N+X)
amount of work over 
> both development, testing, and maintenance.

It seems to be that N is actually 1, and X for far seems to
be 1, if we assume we
need to change gcc to use any pre-command. So generic
framework might be
actually more work.

But basically, if you care about cygwin, you pretty much get
to decide what
helper routines you need.

- Volodya
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build