Re: [EPIC] Regarding curses, and mandatory dependancies

2005-05-31 Thread RoboHak
I haven't been around much (too busy with work and life) but I thought 
I'd comment on this.  I do not see any reason not to make ncurses a 
requirement for epic5.  Everyone should expect changes in epic5, and 
this dependency should not cause any problems.  I cannot think of any 
system I've been on that does not have curses installed, and we already 
require either terminfo/curses or termcap.  Maybe we should take a poll 
to see if anyone uses epic on a system that does not have ncurses, just 
to see if this is an issue for anyone.


RoboHak

Jeremy Nelson wrote:

Well, I was going to have to bring this issue up at some point, and so it
might as well be now.

Up throughout its lifetime, epic has never had any "mandatory dependancies",
which just means another piece of software that absolutely must be installed
before epic will build.  EPIC has many "optional dependancies" (perl, tcl,
socks, ssl, and so on), but you're not required to take them.

But now I am at a place where it seems to really move forward with the 
interface, it is necessary to make epic a curses program, particularly to
use libpanel[1].  This makes a dependance on sysv curses (ncurses) a 
mandatory dependance.  This is a big step.


How do you all feel about making curses a mandatory dependancy for epic5?
System V Curses (ncurses) is a very widely deployed, but not necessarily 
universally available thing.


Jeremy

[1] libpanel is a library wrapper on top of sysv curses that implements a
3-dimensional multiple document interface (mdi).

___
List mailing list
List@epicsol.org
http://epicsol.org/mailman/listinfo/list



___
List mailing list
List@epicsol.org
http://epicsol.org/mailman/listinfo/list


Re: [EPIC] Regarding curses, and mandatory dependancies

2005-05-30 Thread Josh Paetzel
On Sunday 29 May 2005 22:05, Jeremy Nelson wrote:
> >Are you going to continue support for EPIC4 for those that don't
> > want and/or need a curses interface?
>
> EPIC4 is a finished project and only severe bug fixes will ever be
> made to it from this time forward.  It will not be ported to
> curses.
>
> >What sort of upgrade path would users have from EPIC5 -> EPIC5 w/
> >curses? Reinstall or some other magic glue?
>
> If all goes well, the upgrade will only require re-running
> configure and everything will Just Work(tm).  If you don't have a
> sysv curses installed (like ncurses), then configure won't work,
> and then you'd know you need to install ncurses to continue.  I can
> always add a note to that effect in the configure script...
>
> Jeremy

>From the FreeBSD ports perspective it's trivial to make the port 
depend on curses.

-- 
Thanks,

Josh Paetzel
 

___
List mailing list
List@epicsol.org
http://epicsol.org/mailman/listinfo/list


Re: [EPIC] Regarding curses, and mandatory dependancies

2005-05-29 Thread Jeremy Nelson
>Are you going to continue support for EPIC4 for those that don't want 
>and/or need a curses interface?  

EPIC4 is a finished project and only severe bug fixes will ever be made
to it from this time forward.  It will not be ported to curses.

>What sort of upgrade path would users have from EPIC5 -> EPIC5 w/ 
>curses? Reinstall or some other magic glue?

If all goes well, the upgrade will only require re-running configure and
everything will Just Work(tm).  If you don't have a sysv curses installed
(like ncurses), then configure won't work, and then you'd know you need
to install ncurses to continue.  I can always add a note to that effect 
in the configure script...

Jeremy
___
List mailing list
List@epicsol.org
http://epicsol.org/mailman/listinfo/list


Re: [EPIC] Regarding curses, and mandatory dependancies

2005-05-29 Thread Josh Paetzel
On Wednesday 25 May 2005 17:36, Jeremy Nelson wrote:
> Well, I was going to have to bring this issue up at some point, and
> so it might as well be now.
>
> Up throughout its lifetime, epic has never had any "mandatory
> dependancies", which just means another piece of software that
> absolutely must be installed before epic will build.  EPIC has many
> "optional dependancies" (perl, tcl, socks, ssl, and so on), but
> you're not required to take them.
>
> But now I am at a place where it seems to really move forward with
> the interface, it is necessary to make epic a curses program,
> particularly to use libpanel[1].  This makes a dependance on sysv
> curses (ncurses) a mandatory dependance.  This is a big step.
>
> How do you all feel about making curses a mandatory dependancy for
> epic5? System V Curses (ncurses) is a very widely deployed, but not
> necessarily universally available thing.
>
> Jeremy
>
> [1] libpanel is a library wrapper on top of sysv curses that
> implements a 3-dimensional multiple document interface (mdi).
>

Are you going to continue support for EPIC4 for those that don't want 
and/or need a curses interface?  

What sort of upgrade path would users have from EPIC5 -> EPIC5 w/ 
curses? Reinstall or some other magic glue?

-- 
Thanks,

Josh Paetzel
 
___
List mailing list
List@epicsol.org
http://epicsol.org/mailman/listinfo/list


[EPIC] Regarding curses, and mandatory dependancies

2005-05-25 Thread Jeremy Nelson
Well, I was going to have to bring this issue up at some point, and so it
might as well be now.

Up throughout its lifetime, epic has never had any "mandatory dependancies",
which just means another piece of software that absolutely must be installed
before epic will build.  EPIC has many "optional dependancies" (perl, tcl,
socks, ssl, and so on), but you're not required to take them.

But now I am at a place where it seems to really move forward with the 
interface, it is necessary to make epic a curses program, particularly to
use libpanel[1].  This makes a dependance on sysv curses (ncurses) a 
mandatory dependance.  This is a big step.

How do you all feel about making curses a mandatory dependancy for epic5?
System V Curses (ncurses) is a very widely deployed, but not necessarily 
universally available thing.

Jeremy

[1] libpanel is a library wrapper on top of sysv curses that implements a
3-dimensional multiple document interface (mdi).

___
List mailing list
List@epicsol.org
http://epicsol.org/mailman/listinfo/list