lynx-dev
[Top][All Lists]
Advanced

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

Re: LYNX-DEV problems with current auto-config


From: Klaus Weide
Subject: Re: LYNX-DEV problems with current auto-config
Date: Tue, 5 Aug 1997 06:44:15 -0500 (CDT)

On Tue, 5 Aug 1997, T.E.Dickey wrote:
[kw:]
> > More generally, many of the compiler -D flags which were in Makefile
> > (now called Makefile.old) have disappeared from makefile[.in], since they
> > are now meant to be set by the configure script.  The (or, one) problem is

> I think that I got all of the -D flags moved (let me know if I missed one)

All the dired related ones, and a number of others (chartrans, various
settings for slang and curses locations), have moved to be handled by
the configure script.  Others (most or all were just mentioned in
Makefile, not set by default) still have to be set in makefile (such
diverse things as -DNSL_FORK, -DSOCKS, -DUNDERLINE_LINKS,
-DDECLARE_WAIS_LOGFILES, -DREVERSE_CLEAR_SCREEN_PROBLEM).  I don't think
you should try to move them all - I don't see the point.  If someone wants
or needs one of the more unusual options, it's not too much to ask that
they review makefile or makefile.in - or presumably for example

   export CFLAGS="-DUNDERLINE_LINKS" ./configure ...

should also work, for people who upgrade often and don't want to edit
makefile each time?

(It may still make sense to handle _some_ of those remaining flags with
configure, just probably not all.)

> > that the documentation of those flags is also disappearing... I don't
> > think the less-than-one-line explanation given by ./configure --help
> > is a good replacement (especially for some of the dired things).

> I added/expanded the same text to the README.configure that I removed from
> Makefile, since it documents the configure options.
> (Perhaps you would prefer that it be moved to makefile.in)

Ok, I didn't fully realize that you had essentially moved (and adapted) 
the descriptive text from makefile.in to README.configure.  My fault, the
documentation has not "disappeared".

I guess what I don't like about this is mostly that there is now a
disconnect between the various configure flags (for example,
--disable-dired-xpermit), and what they do for the actual compilation
(in this case, set -DNO_CHANGE_EXECUTE_PERMS).  Before, it was easy to
grep through the source files for NO_CHANGE_EXECUTE_PERMS to get an idea
what it does.  Now, the configure script intervenes as a black box and
there is no obvious connection between --disable-dired-xpermit and
NO_CHANGE_EXECUTE_PERMS.

I suggest that the README.configure text should mention the actual
preprocessor variables affected by the various --enable-* and --disable-*
and maybe --with-* options, at least for the simpler cases (it may be too
much for --with-screen).  For example

  ...
  --disable-full-paths                 (prevent defining LONG_LIST)
        Use this option to control whether full utility pathnames are used.
        By default, configure substitutes full pathnames.

  --disable-long-list                  (define NO_PARENT_DIR_REFERENCE)
        Use this option to disable long "ls -l" directory listings.
  ...

Also I would prefer those -D flags to still be mentioned in makefile.in,
maybe with just one line for each:

# The following defines can be used.
# Flags with a description of (see README.configure) should normally
# not be used manually here.  The configure script will add defines for
# them automatically.  They are listed here for completeness.
# 
# -DLONG_LIST      (see README.configure)
# -DNO_PARENT_DIR_REFERENCE (see README.configure)
# ...
# -DHP_TERMINAL    For DIM workaround to REVERSE problems on HP terminals.
# -DIGNORE_CTRL_C  Define if Control-C shouldn't exit lynx.
# ...


> I'd rather keep most of the configure --help listing one-per-line, since it's
> hard enough to read as it is.

Yes, I didn't mean the output of configure --help should become more
verbose.

> > I think even if auto-configuration works perfectly and takes account of
> > all the settings for which it makes sense, it should still be possible
> > to modify the generated makefile (especially the top one) and tweak it.
> That's still possible - that is why I left the assignments in the top-level
> makefile.

Ok. Do my suggestions sound reasonable for this?

   Klaus


;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;

reply via email to

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