Hello,

> On Sun, Mar 14, 2004 at 06:01:37AM +0100, Alex de Kruijff wrote:
> > On Sun, Mar 14, 2004 at 05:52:04AM +0100, Alex de Kruijff wrote:
> > > On Thu, Mar 11, 2004 at 09:34:16PM -0600, Paul Seniura wrote:
>
> > > > I hope this is not too technical:
> > > > All BSDs (except for this 'Free' one) presently have tn3270.c
> > > > together with telnet.c for reasons that become apparent when
> > > > studying how it works and how it is compiled etc.  As they are
> > > > presently written, all of telnet[d].c and tn3270.c must use the
> > > > same macros and other source files from the same 'level' subdir.
> > > > That means if something changes for the sake of 'telnet', it had
> > > > better work with 'tn3270' also.
> >
> > Yes, this is too technical. I would have to study the file, which i'm
> > not going to. If you say that it couldn't posibly be a port, like perl5
> > can, then i will take your word for this.

> This shouldn't be an impassable obstacle to making a tn3270 port --
> there is precedent in the ports tree for having the port require
> various parts of the system sources to be present in order to build.
> See, for instance, the net/ng_netflow or the devel/linuxthreads ports.

I see how those check for certain files.

But tn3270's Makefile recursively copies a lot under
/src/contrib/telnet/ to its work dir.  I haven't seen many
ports do that sort of thing. ;)  If there are routines that
belong in library functions & such, shared or not, then it
could entail modifying the telnet stack itself -- DTRT to
follow standards y'know.

> Having a good, well maintained port available will go a long way
> towards persuading most committers that the tn3270 application should
> be restored to the base system.  Not all the way, but it will make a
> difference.

I'm likely to 'borrow' tn3270 sources from another BSD since they
don't seem to be having our problems.  And for that to follow, we'd
need to put it back where it belongs (under /src/contrib for us,
while other BSDs haven't moved it from /src/usr.bin). 
I'd only be doing that on this PC locally, of course
(I don't have nor want 'committer' status for lots of reasons ;) .
Once it all works, I'll open a PR and have others look at the patches.

Oh this will take quite a while.  This PC may take all week or longer
just to get caught up on all the commits from last Friday onward. ;)

>         Matthew

  --  thx, Paul Seniura.

_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to