X-Spam-Check-By: sourceware.org
Message-ID: <4397B5DE.4090408@cwilson.fastmail.fm>
Date: Wed, 07 Dec 2005 23:26:06 -0500
From: Charles Wilson <cygwin AT cwilson DOT fastmail DOT fm>
User-Agent: Thunderbird 1.5 (Windows/20051025)
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: octave-forge dependency?
References: <20051207153014 DOT 36506 DOT qmail AT web51505 DOT mail DOT yahoo DOT com> <439703E8 DOT 10701 AT equate DOT dyndns DOT org>
In-Reply-To: <439703E8.10701@equate.dyndns.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

Chris Taylor wrote:
> James R. Phillips wrote:
>> OK, it seems an elaboration of the idea could though.  The 
>> autoconf/automake
>> environment needs to be like octave, while the rest of the time, you want
>> miktex in the front of the path.  Wouldn't executing
>>
>> export PATH=$PATH_FOR_OCTAVE
>>
>> before starting ./configure work for that purpose?
>>
>> jrp
>>
> 
> No.
> 
> Two things: Firstly, the OP _doesn't_ want his configure scripts picking 
> up tetex, ergo tetex must not be in the path.

As jrp pointed out in a separate message, I don't mind having tetex 
installed *as long as* it doesn't interfere with my command-line usage 
of miktex.

It's okay if my packages get configured using (now) available tetex 
tools; they are mostly "re-build the documentation" and don't actually 
add new runtime dependencies to MY packages.

So resetting the PATH to remove miktex, just before configuring, is okay 
-- but feels like a kludgy, ad-hoc solution to me.  If I wanted to do it 
"Right" (e.g. the Corporate, controlled-release) I'd have a rigorously 
consistent runtime environment that I used to build packages for release 
(e.g. with only minimal "other" packages installed).  A partway solution 
would be a separate user, sharing my kitchen-sink cygwin installation, 
but with controlled .profile stuff specifically for this purpose (and 
THAT user wouldn't need "miktex" in the front of HIS $path).

Or, I suppose, a "launch maintainance shell" script that culls out all 
the "goodies" of my normal shell environment.

But, fellas, I'm touched that my original post raised such a ruckus -- 
it's really not that big a deal (to me).  I'm okay, you're okay.

I guess it's good that the actual source of the dependency was tracked 
down, and will hopefully lead to a correction in gnuplot's code, but 
gollee...

> Secondly, tetex installs (at least last time I checked) in such a way 
> that it's located automatically by configure scripts (given that it's in 
> the default path).
> The only way to stop this behaviour is to
> a) completely trash the cygwin path, and thus lose 99% of the functionality
> b) install tetex elsewhere (/usr/local/octave-tetex/*hierarchy_here* for 
> example).
> 
> Neither of these are brilliant solutions, and the latter would actually 
> require hacking the cygwin package in order for it to install there, and 
> still work (it would probably require tetex to be recompiled).

Yep, all the above would be true -- IF I really really didn't want my 
configure scripts to find tetex, or be used by packages when I build 
them (since, by default, tetex goes smack in the middle of all the OTHER 
cygwin tools, right there under /usr).  But *that* doesn't matter to me.

[snip]

I think the rest of this post is OBE, given the discovery of the gnuplot 
issue.

Thanks for everybody chiming in on this thread. (I gotta start checking 
the list more than once a day...)

--
Chuck

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/