Re: octave-forge dependency?

[Dr. Volker Zell]

> James R Phillips writes:

> BTW, the gnuplot version in Debian sarge behaves exactly the same way as 
the
> cygwin version in response saving a file if kpsexpand is not present.  And
> Debian does not list tetex-bin as a dependency for gnuplot.  Probably this
> needs to be researched further with the gnuplot mailing lists.  Possibly 
some
> bugs need to be filed upstream.

That's what I'm doing now.

Ciao
  Volker


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

Re: octave-forge dependency?

[Igor Pechtchanski]

On Thu, 8 Dec 2005, Tony Richardson wrote:

> Igor Pechtchanski  cs.nyu.edu> writes:
>
> > On Wed, 7 Dec 2005, Tony Richardson wrote:
> >
> > > I often use octave and do no plotting at all.  Octave starts and runs
> > > fine if gnuplot isn't installed.  (It complains about not being able
> > > to find gnuplot when the plot command is used.)  Should there really
> > > be a dependency if only a subset of features requires a package?
> > >
> > > I'd prefer to see gnuplot removed from the octave dependency list.
> > > Of course then you'd have to deal with all the posts saying that
> > > the plot command in octave is broken.  So I don't know what the best
> > > approach would be.  How do others feel?
> >
> > Actually, a viable solution for this was already proposed by John W Eaton
> > in .  Since octave adds
> > other directories to the path before it runs, it's possible to create a
> > gnuplot wrapper that uses the real gnuplot if present and exits with a
> > reasonable error message otherwise.
> >
> > Just to clarify, the reason I thought it was a hack was that it was an
> > *octave-forge* script dealing with a *gnuplot* bug.  I don't think the
> > mechanism itself is in any way hacky.
> > Igor
>
> I don't follow.  I'm asking for the gnuplot requirement for octave to be
> dropped from setup.ini so that when I install octave all of the X11
> stuff (through a gnuplot dependency) isn't installed by default.

You were also asking what the best approach would be to avoid the
complaints that octave is broken once that dependency is removed.  That's
what my post was trying to address.  FWIW, I agree that if it's possible
to avoid the dependency, it should be done.

> It's not that I can't work around the problem, I can.  Perhaps a better
> way to handle it, as you suggested in another message regarding tetex-bin,
> is to add a comment in the README about installing cygwin/X11/gnuplot
> and/or setting up Windows-native gnuplot if you want to do plotting
> with octave.

The message I quoted was a solution for the package maintainer, not for
the users (though it's possible for the users to employ it as well).
IMO, it's not enough to just mention this in the README if things are
going to break -- my suggestion was only meant for things like harmless
warnings.
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. /DA

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

Re: octave-forge dependency?

[Tony Richardson]

Igor Pechtchanski  cs.nyu.edu> writes:

> 
> On Wed, 7 Dec 2005, Tony Richardson wrote:
> 
> > I often use octave and do no plotting at all.  Octave starts and runs
> > fine if gnuplot isn't installed.  (It complains about not being able
> > to find gnuplot when the plot command is used.)  Should there really
> > be a dependency if only a subset of features requires a package?
> >
> > I'd prefer to see gnuplot removed from the octave dependency list.
> > Of course then you'd have to deal with all the posts saying that
> > the plot command in octave is broken.  So I don't know what the best
> > approach would be.  How do others feel?
> 
> Actually, a viable solution for this was already proposed by John W Eaton
> in .  Since octave adds
> other directories to the path before it runs, it's possible to create a
> gnuplot wrapper that uses the real gnuplot if present and exits with a
> reasonable error message otherwise.
> 
> Just to clarify, the reason I thought it was a hack was that it was an
> *octave-forge* script dealing with a *gnuplot* bug.  I don't think the
> mechanism itself is in any way hacky.
>   Igor

I don't follow.  I'm asking for the gnuplot requirement for octave to be
dropped from setup.ini so that when I install octave all of the X11
stuff (through a gnuplot dependency) isn't installed by default.
It's not that I can't work around the problem, I can.  Perhaps a better
way to handle it, as you suggested in another message regarding tetex-bin,
is to add a comment in the README about installing cygwin/X11/gnuplot
and/or setting up Windows-native gnuplot if you want to do plotting
with octave.

Tony

I can.  The 





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

Re: octave-forge dependency?

[Charles Wilson]

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/

Re: octave-forge dependency?

[Igor Pechtchanski]

On Wed, 7 Dec 2005, Tony Richardson wrote:

> I often use octave and do no plotting at all.  Octave starts and runs
> fine if gnuplot isn't installed.  (It complains about not being able
> to find gnuplot when the plot command is used.)  Should there really
> be a dependency if only a subset of features requires a package?
>
> I'd prefer to see gnuplot removed from the octave dependency list.
> Of course then you'd have to deal with all the posts saying that
> the plot command in octave is broken.  So I don't know what the best
> approach would be.  How do others feel?

Actually, a viable solution for this was already proposed by John W Eaton
in .  Since octave adds
other directories to the path before it runs, it's possible to create a
gnuplot wrapper that uses the real gnuplot if present and exits with a
reasonable error message otherwise.

Just to clarify, the reason I thought it was a hack was that it was an
*octave-forge* script dealing with a *gnuplot* bug.  I don't think the
mechanism itself is in any way hacky.
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. /DA

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

Re: octave-forge dependency?

[Igor Pechtchanski]

On Wed, 7 Dec 2005, James R. Phillips wrote:

> --- Igor Pechtchanski wrote:
>
> > Ok, so first off, octave-forge *shouldn't* depend on tetex-bin. If
> > anything needs to depend on tetex-bin, it should be gnuplot.  The
> > presence of tetex-bin in octave-forge's requires: line is a packaging
> > bug (even if it's intended to work around gnuplot's missing
> > dependency).
>
> Igor, if you read the whole thread, you will see that the dependency
> could not possibly have been intended to work around a problem with
> gnuplot, because we didn't know there was a problem with gnuplot.  All
> we knew was that there was a problem with octave-forge.

I realize that.  I never claimed that you should have not inserted the
dependency -- just that in the light of this thread, the dependency should
be in gnuplot.  Maybe adding the "anymore" after the sentence with the
starred "shouldn't" would help...

> Now that we know more specifically where the problem is, I can agree
> that the tetex-bin dependency for octave-forge causes more problems than
> it solves, and should be dropped.
>
> It seems the best solution to this problem lies in updating the gnuplot
> package.  In the meantime, users can try the workarounds suggested.
>
> BTW, the gnuplot version in Debian sarge behaves exactly the same way as
> the cygwin version in response saving a file if kpsexpand is not
> present.

What is the behavior?  Does it fail, or does it simply produce the error
messages?  I don't think this was ever specified...  If it's the error
messages, then I'd even say a note in the README that those are harmless
would be enough...

> And Debian does not list tetex-bin as a dependency for gnuplot.

Well, Debian doesn't quite target the OOTB experience that Cygwin does...
:-)

> Probably this needs to be researched further with the gnuplot mailing
> lists.  Possibly some bugs need to be filed upstream.

True.
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. /DA

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

Re: octave-forge dependency?

[Tony Richardson]

James R. Phillips  yahoo.com> writes:

> 
> The octave-forge legend command requires tetex-bin.  This came up in:
> 
> http://www.octave.org/mailing-lists/help-octave/2005/4239
> 
> I promised to fix it, and I did.
> 
> Everyone who complains about long downloads should get broadband ;)
> 
> Everyone who complains about many files should get a bigger hard drive ;)

I have a similar gripe regarding an octave dependency.  I have an old
laptop in which I keep a rather lean cygwin installation.  I do use octave
quite a bit, but I prefer to use it with the native-Windows version of
gnuplot instead of the cygwin-X11 version.  (Just set gnuplot_binary equal
to "/cygdrive/c/Program Files/gnuplot4.00/bin/pgnuplot" or similar
in the .octaverc file.)

Because of the dependency on gnuplot and the gnuplot dependency on X11
upgrading octave is painful.  (I don't have any of the X11 packages
installed and I don't want to install them.  Note also that X11 is
required only through the gnuplot dependency, it isn't required for
viewing images, octave-forge sets up IE as the default image viewer.)

I often use octave and do no plotting at all.  Octave starts and runs
fine if gnuplot isn't installed.  (It complains about not being able
to find gnuplot when the plot command is used.)  Should there really
be a dependency if only a subset of features requires a package?

I'd prefer to see gnuplot removed from the octave dependency list.
Of course then you'd have to deal with all the posts saying that
the plot command in octave is broken.  So I don't know what the best
approach would be.  How do others feel?

Tony Richardson



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

Re: octave-forge dependency?

[James R. Phillips]

--- Igor Pechtchanski wrote:

> Ok, so first off, octave-forge *shouldn't* depend on tetex-bin. If
> anything needs to depend on tetex-bin, it should be gnuplot.  The presence
> of tetex-bin in octave-forge's requires: line is a packaging bug (even if
> it's intended to work around gnuplot's missing dependency).
> 

Igor, if you read the whole thread, you will see that the dependency could not
possibly have been intended to work around a problem with gnuplot, because we
didn't know there was a problem with gnuplot.  All we knew was that there was a
problem with octave-forge.

Now that we know more specifically where the problem is, I can agree that the
tetex-bin dependency for octave-forge causes more problems than it solves, and
should be dropped.

It seems the best solution to this problem lies in updating the gnuplot
package.  In the meantime, users can try the workarounds suggested.

BTW, the gnuplot version in Debian sarge behaves exactly the same way as the
cygwin version in response saving a file if kpsexpand is not present.  And
Debian does not list tetex-bin as a dependency for gnuplot.  Probably this
needs to be researched further with the gnuplot mailing lists.  Possibly some
bugs need to be filed upstream.

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

Re: octave-forge dependency?

[Igor Pechtchanski]

On Wed, 7 Dec 2005, John W. Eaton wrote:

> OK, let's back up a bit, and see why kpsexpand is needed in the first
> place.

Yes, let's.

> Graphics in Octave use gnuplot.  The legend function from Octave Forge
> sends a "save FILE" command to gnuplot so that it can extract some
> information about gnuplot's current state.  If you do the following
>
>   mv /usr/bin/kpsexpand. /usr/bin/kpsexpand-save
>   gnuplot
>   ...
>   gnuplot> save "foo"
>
> you should see the errors
>
>   sh: kpsexpand: command not found

Ok, so first off, octave-forge *shouldn't* depend on tetex-bin.  If
anything needs to depend on tetex-bin, it should be gnuplot.  The presence
of tetex-bin in octave-forge's requires: line is a packaging bug (even if
it's intended to work around gnuplot's missing dependency).

> So, why does gnuplot need kpsexpand to save state?

Yes, why does it *need* kpsexpand/kpsewhich to save state?  Looks like the
kpsexpand command can easily fail with no adverse effects.  The only
problem is the error message -- so this looks to me to be a bug in gnuplot
(either a minor one if all it does is display the message, or a major one
if it stops processing the curr_fontpath array on such errors).

> So gnuplot is using kpsexpand to locate some font files.
> It looks like there are a couple of options.
>
> One is to set GNUPLOT_FONTPATH in the environment before calling
> gnuplot.

That would avoid the use of kpsexpand altogether, but will hard-code the
paths.  A better solution would be to use kpsexpand if it's available, and
ignore it if it isn't (but this has to be done in gnuplot).

> Another is to make a wrapper kpsexpand that looks for the real version
> and does nothing if the real version is not present:
>
>   #! /bin/sh
>   if [ -x /usr/bin/kpsexpand ]; then
> exec /usr/bin/kspexpand "$@"
>   fi
>
> (though you might want to add some comments about why this is needed).

Ugh.  Why not just modify gnuplot to test whether an executable is present
before blindly calling it?

> If the real kpsexpand is not present, then chances are the font files
> are not -either, so it should not matter that the corresponding
> directories named in the fontpath are bogus.

Bingo.

> You could install the wrapper script in one of the directories in
> Octave's DEFAULT_EXEC_PATH (for example,
> /usr/lib/octave/2.1.72/exec/i686-pc-cygwin, where a couple of other
> scripts are already installed), then it would only be found by Octave
> and should not introduce any other conflicts.

Either one is a reasonable hack pending the appropriate gnuplot change,
but both are still hacks, IMO.
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. /DA

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

Re: octave-forge dependency?

[John W. Eaton]

OK, let's back up a bit, and see why kpsexpand is needed in the first
place.

Graphics in Octave use gnuplot.  The legend function from Octave Forge
sends a "save FILE" command to gnuplot so that it can extract some
information about gnuplot's current state.  If you do the following

  mv /usr/bin/kpsexpand. /usr/bin/kpsexpand-save
  gnuplot
  ...
  gnuplot> save "foo"

you should see the errors

  sh: kpsexpand: command not found

So, why does gnuplot need kpsexpand to save state?  Looking at the
gnuplot sources, one finds

  /* Yet, no special font paths for these operating systems:
   * MSDOS, ATARI, AMIGA, MTOS, NeXT, ultrix, VMS, _IBMR2, alliant
   *
   * Environmental variables are written as $(name).
   * Commands are written as $`command`.
   */

  [...]

  #if defined(_Windows) && !defined(FONTPATHSET)
  #  define FONTPATHSET
  static const struct path_table fontpath_tbl[] =
  {
  { "$(windir)\\fonts" },
  /* Ghostscript */
  { "c:\\gs\\fonts" },
  /* X11 */
  { "$(CYGWIN_ROOT)\\usr\\X11R6\\lib\\X11\\fonts\\Type1" },
  /* fpTeX */
  { "$`kpsewhich -expand-path=$HOMETEXMF`\\fonts\\type1!" },
  { "$`kpsewhich -expand-path=$TEXMFLOCAL`\\fonts\\type1!" },
  { "$`kpsewhich -expand-path=$TEXMFMAIN`\\fonts\\type1!" },
  { "$`kpsewhich -expand-path=$TEXMFDIST`\\fonts\\type1!" },
  { NULL }
  };
  #endif

  [...]

  /* Fallback: Should work for unix */
  #ifndef FONTPATHSET
  static const struct path_table fontpath_tbl[] =
  {
  /* teTeX or TeXLive */
  { "$`kpsexpand '$HOMETEXMF'`/fonts/type1!" },
  { "$`kpsexpand '$TEXMFLOCAL'`/fonts/type1!" },
  { "$`kpsexpand '$TEXMFMAIN'`/fonts/type1!" },
  { "$`kpsexpand '$TEXMFDIST'`/fonts/type1!" },
  /* Linux paths */
  { "/usr/X11R6/lib/X11/fonts/Type1" },
  { "/usr/X11R6/lib/X11/fonts/truetype" },
  /* HP-UX */
  { "/usr/lib/X11/fonts!"},
  /* Ghostscript */
  { "/usr/share/ghostscript/fonts" },
  { "/usr/local/share/ghostscript/fonts" },
  { NULL }
  };
  #endif

  [...]

switch (action) {
case ACTION_CLEAR:
/* Clear fontpath, fall through to init */
FPRINTF((stderr, "Clear fontpath\n"));
free(fontpath);
fontpath = p = last = NULL;
/* HBB 2726: 'limit' has to be initialized to NULL, too! */
limit = NULL;
case ACTION_INIT:
/* Init fontpath from environment */
FPRINTF((stderr, "Init fontpath from environment\n"));
assert(fontpath == NULL);
if (!fontpath)
{
char *envlib = getenv("GNUPLOT_FONTPATH");
if (envlib) {
/* get paths from environment */
int len = strlen(envlib);
fontpath = gp_strdup(envlib);
/* point to end of fontpath */
last = fontpath + len;
/* convert all PATHSEPs to \0 */
PATHSEP_TO_NUL(fontpath);
}
#if defined(HAVE_DIRENT_H) || defined(_Windows)
else {
/* set hardcoded paths */
const struct path_table *curr_fontpath = fontpath_tbl;

  [...]

in src/variable.c.  The above is taken from a recent CVS checkout, but
the 4.0.0 sources for the current Cygwin package have similar lines.

So gnuplot is using kpsexpand to locate some font files.

It looks like there are a couple of options.

One is to set GNUPLOT_FONTPATH in the environment before calling
gnuplot.

Another is to make a wrapper kpsexpand that looks for the real version
and does nothing if the real version is not present:

  #! /bin/sh
  if [ -x /usr/bin/kpsexpand ]; then
exec /usr/bin/kspexpand "$@"
  fi

(though you might want to add some comments about why this is needed).

If the real kpsexpand is not present, then chances are the font files
are not -either, so it should not matter that the corresponding
directories named in the fontpath are bogus.  You could install the
wrapper script in one of the directories in Octave's DEFAULT_EXEC_PATH
(for example, /usr/lib/octave/2.1.72/exec/i686-pc-cygwin, where a
couple of other scripts are already installed), then it would only be
found by Octave and should not introduce any other conflicts.

jwe

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

Re: octave-forge dependency?

[James R. Phillips]

Chris Taylor wrote:

>...the OP _doesn't_ want his configure scripts picking up tetex...

This is what the OP said:

"If I don't put miktex in the front of my path, then the configury stuff is
happy (finds tetex, uses tetex), but *I'm* not happy because *I* want to call
miktex binaries from my cygwin interactive shell."

I believe a reasonable interpretation of this is that he generally doesn't mind
if packages configure to use tetex and even use tetex, as long as he gets
miktex by default from the command line.  This is the situation my solution is
designed to address.  If, as you claim, he _cannot_ have packages configure to
use tetex, then I admit my solution does not work.


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

Re: octave-forge dependency?

[Igor Pechtchanski]

On Wed, 7 Dec 2005, Chris Taylor wrote:

> Two things: Firstly, the OP _doesn't_ want his configure scripts picking
> up tetex, ergo tetex must not be in the path.
> [snip]

As you noted, for tetex to not be in the PATH, it needs to not be
installed.

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

There's a third way -- read on.

> 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). Though
> you could perhaps persuade octave not to install the normal tetex using
> the setup database that tracks what is and isn't installed... (Not
> entirely clear on how that works at the moment though - Igor might be
> able to clear that up?)

The setup database is not sophisticated enough to track package
alternatives.  All it does is record which *packages* are installed.
It's possible to, as you say, hack it when your proposed octave-tetex
package is installed to record that the version of tetex is some
improbably high number, but since the only thing that programmatically
modifies the database is setup itself, this would have to be done by hand.
I don't think it's even possible to do this cleanly in a postinstall
script.

> It may be worth having an either or dependancy for octave..

Setup does not support this kind of dependencies.

> None of this is all that straightforward, but it would mean people
> weren't forced to install tetex..

The third alternative I mentioned is to split out the "legend" command
into a separate package, and have *that* package depend on tetex-bin.
This way, people who want to use octave without tetex (and thus without
"legend") can install the base octave-forge package, and those who do want
to use "legend" can install "octave-legend" with all the gory consequences
(i.e., dragging in tetex-bin).

However...

Chuck, since all "legend" needs is kpsexpand, why not simply make setup
convinced that tetex-bin *is* installed (hack installed.db by hand)?
That way, "legend" will even pick up the kpsexpand from MikTeX, and setup
will never try to install tetex-bin automatically...  This will solve your
particular problem right now, but can't be expected of each and every user
of octave-forge, of course.

HTH,
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. /DA

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

Re: octave-forge dependency?

[Chris Taylor]

James R. Phillips wrote:

Chris Taylor wrote:



This doesn't solve the core problem that configure will pick up the >presence


of cygwin's tetex and expect it - the cygwin tetex install >would need to be
masked entirely in order to use miktex and not >have configure expect tetex..


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.
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). Though 
you could perhaps persuade octave not to install the normal tetex using 
the setup database that tracks what is and isn't installed... (Not 
entirely clear on how that works at the moment though - Igor might be 
able to clear that up?)


It may be worth having an either or dependancy for octave.. tetex-bin or 
octave-tetex, the latter being the minimal set required to use 
octave-forge fully, and installing in a different path in order to 
separate it from the standard path. You'd then need to have some sort of 
wrapper that could tell octave where it was - an expansion of the basic 
script you gave would probably be sufficient - perhaps testing for it in 
/usr/bin, and if it didn't exist, appending or prepending the 
octave-tetex path. Of course, the octave-tetex would have to conflict 
with tetex-bin, and tetex-bin would have to effectively supplant it if 
it was selected, or was already installed...



None of this is all that straightforward, but it would mean people 
weren't forced to install tetex..


--

Spinning complacently in the darkness, covered and blinded by a blanket
of little lives, false security has lulled the madness of this world
into a slumber. Wake up! An eye is upon you, staring straight down and
keenly through, seeing all that you are and everything that you will
never be. Yes, an eye is upon you, an eye ready to blink. So face
forward, with arms wide open and mind reeling. Your future has
arrived... Are you ready to go?

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

Re: octave-forge dependency?

[Christopher Faylor]

On Wed, Dec 07, 2005 at 04:22:57PM +0100, Corinna Vinschen wrote:
>On Dec  6 13:47, James R. Phillips wrote:
>> FWIW, the 12-04 and 12-05 cygwin1.dll snapshots seem to cause
>> octave-2.1.72-1 to hang on exit, but only if some significant
>> computations and plots are done.  Just starting and then exiting
>> doesn't trigger the problem.  This is a regression relative to the
>> 11-30 snapshot.
>
>That's fine, but you remember vaguely what I wrote in my call for
>testing, right?  If you want the hang to persist in the next Cygwin
>version, just don't give us any more information.  What about basic
>debugging, strace, gdb, cygcheck output, ... a simple testcase?

It would be interesting to find out where this fails.  There are other
snapshots between 12-04 and 11-30.  Does it also fail with those?

cgf

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

Re: octave-forge dependency?

[James R. Phillips]

Chris Taylor wrote:

>This doesn't solve the core problem that configure will pick up the >presence
of cygwin's tetex and expect it - the cygwin tetex install >would need to be
masked entirely in order to use miktex and not >have configure expect tetex..


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

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

Re: octave-forge dependency?

[Corinna Vinschen]

On Dec  6 13:47, James R. Phillips wrote:
> FWIW, the 12-04 and 12-05 cygwin1.dll snapshots seem to cause
> octave-2.1.72-1 to hang on exit, but only if some significant
> computations and plots are done.  Just starting and then exiting
> doesn't trigger the problem.  This is a regression relative to the
> 11-30 snapshot.

That's fine, but you remember vaguely what I wrote in my call for
testing, right?  If you want the hang to persist in the next Cygwin
version, just don't give us any more information.  What about basic
debugging, strace, gdb, cygcheck output, ... a simple testcase?


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat, Inc.

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

Re: octave-forge dependency?

[Chris Taylor]

James R. Phillips wrote:

Charles Wilson wrote:



But apparently I can't use octave.



Hm, actually we wouldn't want to lose such a knowledgeable user.  We need users
like you in order to improve octave.

Would this work for you?  Prior to putting miktex at the front of your path,
say in your .profile, it should be possible to save the unmodified path in an
environmental variable, say PATH_FOR_OCTAVE.

Then write a short shell script named "octave" to start octave, and put it in
/usr/local/bin; something like

===
#!/bin/sh

export PATH=$PATH_FOR_OCTAVE
/usr/bin/octave
===

When typing "octave" from the command line, the shell script should be found in
the path prior to the octave binary in /usr/bin. octave/octave-forge should
then use the cygwin-native tetex binaries.  I don't see any reason why this
wouldn't work.

Hope you don't give up on octave.

jrp




This doesn't solve the core problem that configure will pick up the 
presence of cygwin's tetex and expect it - the cygwin tetex install 
would need to be masked entirely in order to use miktex and not have 
configure expect tetex..



Chris

--

Spinning complacently in the darkness, covered and blinded by a blanket
of little lives, false security has lulled the madness of this world
into a slumber. Wake up! An eye is upon you, staring straight down and
keenly through, seeing all that you are and everything that you will
never be. Yes, an eye is upon you, an eye ready to blink. So face
forward, with arms wide open and mind reeling. Your future has
arrived... Are you ready to go?

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

Re: octave-forge dependency?

[James R. Phillips]

Charles Wilson wrote:

>But apparently I can't use octave.

Hm, actually we wouldn't want to lose such a knowledgeable user.  We need users
like you in order to improve octave.

Would this work for you?  Prior to putting miktex at the front of your path,
say in your .profile, it should be possible to save the unmodified path in an
environmental variable, say PATH_FOR_OCTAVE.

Then write a short shell script named "octave" to start octave, and put it in
/usr/local/bin; something like

===
#!/bin/sh

export PATH=$PATH_FOR_OCTAVE
/usr/bin/octave
===

When typing "octave" from the command line, the shell script should be found in
the path prior to the octave binary in /usr/bin. octave/octave-forge should
then use the cygwin-native tetex binaries.  I don't see any reason why this
wouldn't work.

Hope you don't give up on octave.

jrp



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

Re: octave-forge dependency?

[Charles Wilson]

James R. Phillips wrote:

The octave-forge legend command requires tetex-bin.  This came up in:

http://www.octave.org/mailing-lists/help-octave/2005/4239


Ok, thanks, that makes sense. I had a feeling the texinfo/makeinfo 
subthread was a red herring.


I'll uninstall octave and all the, err, unwanted stuff, it forced into 
my installation and keep using matlab instead.


The problem is, if both miktex and tetex are installed on my machine:

If I put miktex in the front of PATH, the configury of some of the 
packages I maintain detects tetex -- but at runtime gets miktex 
executables, and barfs.  This happened in some of the automake testsuites.


If I don't put miktex in the front of my path, then the configury stuff 
is happy (finds tetex, uses tetex), but *I'm* not happy because *I* want 
to call miktex binaries from my cygwin interactive shell.


My solution was to NOT install tetex; thus configury happy (no findee 
tetex) and I'm happy.


But apparently I can't use octave.

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

Re: octave-forge dependency?

[James R. Phillips]

The octave-forge legend command requires tetex-bin.  This came up in:

http://www.octave.org/mailing-lists/help-octave/2005/4239

I promised to fix it, and I did.

Everyone who complains about long downloads should get broadband ;)

Everyone who complains about many files should get a bigger hard drive ;)

Actually I'm pleased others are actually using this stuff.  Still waiting for
an installation report from someone who has compiled optimized blas libraries
using the ATLAS subdirectory in the LAPACK source package.

FWIW, the 12-04 and 12-05 cygwin1.dll snapshots seem to cause octave-2.1.72-1
to hang on exit, but only if some significant computations and plots are done. 
Just starting and then exiting doesn't trigger the problem.  This is a
regression relative to the 11-30 snapshot.


jrp


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

Re: octave-forge dependency?

[John W. Eaton]

On  6-Dec-2005, Christopher Faylor wrote:

| On Tue, Dec 06, 2005 at 01:14:13AM -0500, John W. Eaton wrote:
| >On  6-Dec-2005, Charles Wilson wrote:
| >>Why does package octave-forge depend on tetex-bin?  As far as I can
| >>tell, octave-forge contains .oct and .m files, and few text and info
| >>files -- nothing there should need TeX.  I use MikTeX so I don't want
| >>to have cygwin-TeX installed, but this octave-forge dependency pulls in
| >>the whole mess for no good reason...
| >
| >Octave uses makeinfo to format docstrings.
| 
| makeinfo is in the texinfo package not the TeX package.

Sorry, I answered a bit hastily.  I don't see a reason for the
octave-forge package to have a direct dependency on tetex-bin.  But
doesn't the texinfo package depend on tetex in some way?  I guess not:

@ texinfo
sdesc: "Documentation system for on-line information and printed output"
category: Text Doc
requires: cygwin libiconv2 libintl3 libncurses8 _update-info-dir
version: 4.8-1
install: release/texinfo/texinfo-4.8-1.tar.bz2 695242 
41433bef576c2bccc7136ec6677f6457
source: release/texinfo/texinfo-4.8-1-src.tar.bz2 1474048 
ae84f762aae32d3356cfd8639ff608f8
[prev]
version: 4.7-2
install: release/texinfo/texinfo-4.7-2.tar.bz2 690192 
b0b7a4d4fb51cfe3d1b8b7db85463d1f
source: release/texinfo/texinfo-4.7-2-src.tar.bz2 1356848 
5529d19c02bd71abc13479e3ebaa8325

though I'm not sure why it doesn't.  Isn't TeX needed to make this
package fully functional?

jwe

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

Re: octave-forge dependency?

[Christopher Faylor]

On Tue, Dec 06, 2005 at 01:14:13AM -0500, John W. Eaton wrote:
>On  6-Dec-2005, Charles Wilson wrote:
>>Why does package octave-forge depend on tetex-bin?  As far as I can
>>tell, octave-forge contains .oct and .m files, and few text and info
>>files -- nothing there should need TeX.  I use MikTeX so I don't want
>>to have cygwin-TeX installed, but this octave-forge dependency pulls in
>>the whole mess for no good reason...
>
>Octave uses makeinfo to format docstrings.

makeinfo is in the texinfo package not the TeX package.

cgf

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

octave-forge dependency?

[John W. Eaton]

On  6-Dec-2005, Charles Wilson wrote:

| Why does package octave-forge depend on tetex-bin?  As far as I can 
| tell, octave-forge contains .oct and .m files, and few text and info 
| files -- nothing there should need TeX.  I use MikTeX so I don't want to 
| have cygwin-TeX installed, but this octave-forge dependency pulls in the 
| whole mess for no good reason...

Octave uses makeinfo to format docstrings.

jwe

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

octave-forge dependency?

[Charles Wilson]

Why does package octave-forge depend on tetex-bin?  As far as I can 
tell, octave-forge contains .oct and .m files, and few text and info 
files -- nothing there should need TeX.  I use MikTeX so I don't want to 
have cygwin-TeX installed, but this octave-forge dependency pulls in the 
whole mess for no good reason...


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