[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: DJGPP build (was: Re: lynx-dev Documentation patch)

From: Doug Kaufman
Subject: Re: DJGPP build (was: Re: lynx-dev Documentation patch)
Date: Tue, 20 Jan 2004 17:53:03 -0800 (PST)

On Wed, 21 Jan 2004, Leonid Pauzner wrote:

> I read the suggested patch and have several comments on it.

Thanks for taking the time to look.

> Several chunks of PDCurses patches seems unneccessary for DJGPP environment:

Which ones can we leave out?

> ^^^^
> IMHO, any djgpp/gcc installation always have  string.h

Yes, djgpp has it, but pdcurses uses a preset make file which doesn't
define HAVE_STRING_H. I would have to go back to see if missing this
just gave warnings or caused more serious errors. This wasn't needed
for pdcurses 2.4. Do you have an alternate suggestion to getting
string.h included in kernel.c, pdcutil.c, and pdcwin.c?

> > + clean:
> > +-    -del *.o
> > +-    -del curses.lib
> > +-    -del panel.lib
> > +-    -del *.exe
> > ++    -rm -f *.o
> > ++    -rm -f pdcurses.a
> > ++    -rm -f panel.a
> > ++    -rm -f *.exe
>         ^^^^^^
> can we live with vanilla 'del'?
> Some djgpp installation may be without fileutils (rm).

Sure. You could use del, but change curses.lib and panel.lib to
pdcurses.a and panel.a.

> Why not to put PDCurses lib & include files in DJGPP/lib & DJGPP/include
> like we do with SLANG?

I am not sure what you mean. The makefile.dsl has $(SLANGLIB) and
$(SLANGINC) for designating where the library is. The makefile.dos
file does specify paths for pdcurses. This may be the way Wayne
Buttles made the file initially. I don't think that the way the
file is designed has been changed; it has only had some tweaks
applied. Of historical interest, I think that Wayne wrote the original
makefile.dos. I believe that I modified it to use Slang and called
it makefile.dsl. I was the main person maintaining makefile.dos and
makefile.dsl after Wayne dropped out of lynx development. Bill Schiavo
did makefile.wsl for his Blynx port for blind users, but he hasn't
been active on this list for several years and his blynx site hasn't
been updated since February 1999.

> Also, I do not understand what do you mean by the absolute path
> /djgpp/pdcur26 on a DOS platform, shouldn't it be prefixed by a drive
> letter? Or you mean a relative path - relative to what?

The path starting with a slash on DOS refers to a path relative to
the root directory on the drive that you are on. The current drive
letter is used implicitly. None of this is new and has been there
for years. We could certainly make it a truly absolute path by using
"/dev/env/DJDIR" instead of "/djgpp". That form of the absolute path
wasn't available when the makefile was originally written.

> >      compile or place your compiled WATT-32 library in /djgpp/watt32.  If
> >      using the SLANG library, put libslang.a in your DJGPP/lib directory and
> > put
> >      slang.h and slcurses.h in your DJGPP/include directory, or in the

Now I see what you mean. This isn't a change. It has been this way for
at least two years. This is just to make compilation succeed without
modifying the makefiles as written. It should be easy for someone who
knows what they are doing to change the directories as they see fit.

It would be an interesting project to take the three DOS makefiles and
make them uniform in style. However, I don't know if they are really
supported. I haven't compiled using any of them for over two
years, since the configure script was tweaked to work with DJGPP
If no one is using or maintaining them, should we instead consider
dropping them from the distribution and suggest that anyone who wants
to compile their own lynx binary use the configure script?

> > -    --enable-default-colors \
> > +    --enable-color-style \
>        ^^^^^^^^^^^^^^^^^^^^
> A silly change! Require a comment at least.

I am not sure about this. This should be a suggestion of options for the
novice who doesn't understand or take the time to read about the
options. Color-style has now become fairly commonly used by those
compiling lynx. I don't know that that was true two years ago when this
was last revised. The makefiles need to be modified by anyone who wants
to decide what options to use. I don't object, however, to leaving out
--enable-color-style if that is what is felt to be the better default

> >      --enable-prettysrc \
> >      --enable-read-eta \
> >      --enable-source-cache \
> enable-source-cache and enable-prettysrc now assumed by default

Good point. We can drop those lines.

Doug Kaufman
Internet: address@hidden

; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]