Re: [Lynx-dev] configure-script issue

[Thomas Dickey]

On Thu, Feb 03, 2022 at 03:26:34PM -0500, Mouse wrote:
> I wrote, earlier today, of trying to rebuild a past lynx install,
> saying
> 
> > This led me to rediscover that the configure script for that version
> > appears to be broken.
> 
> I fetched the current .tar.bz2, which unpacked into lynx2.9.0dev.10.
> Turns out the configure script is still broken, just in a trivially
> different way.  (Aside from all the ways that inhere in using configure
> scripts at all, that is.)
> 
> Specifically, when I run it with CC set to cc -g, in order to get -g on
> all compiler runs, the configure script calls this broken.  The old
> script then claimed this was a misuse of $CC.  The modern script
> doesn't call it _mis_use, but it does still - like the old one -

someone complained about the word "misuse"

I created the macro after dealing with users who would put C preprocessor
options in $CC (which for lynx will cause it to not build the configuration
summary page as expected, for ncurses will cause interesting build failures,
etc) or would load up $CC with optimization/debugging options (similar
problems, with complaints when it didn't evaluate in the expected order).

A warning message is just a reminder...

CFLAGS is the proper place for compiler options (standard),

CPPFLAGS is the place for C preprocessor options (originally GNU make,
but adopted in autoconf -- autoconf introduced DEFS, unnecessarily)

dnl CF_CC_ENV_FLAGS version: 10 updated: 2020/12/31 18:40:20
dnl ---------------
dnl Check for user's environment-breakage by stuffing CFLAGS/CPPFLAGS content
dnl into CC.  This will not help with broken scripts that wrap the compiler
dnl with options, but eliminates a more common category of user confusion.
dnl
dnl In particular, it addresses the problem of being able to run the C
dnl preprocessor in a consistent manner.
dnl
dnl Caveat: this also disallows blanks in the pathname for the compiler, but
dnl the nuisance of having inconsistent settings for compiler and preprocessor
dnl outweighs that limitation.

> complain and pull the -g off $CC and put it...somewhere else; configure
> code is sufficiently twisted I'm not entirely sure where.
> 
> So if I'm going to end up building 2.9.0dev.10, I'm going to have to
> resurrect the kludge I used before: create a script (I called it cc-g)
> that runs cc -g "$@", and tell configure to use that.

I do that for compiler warnings, but not for optimization/debugging.
 
> But this leads me to ask: why do this?  Is there something wrong with
> wanting a specific option on _all_ cc runs?  Or is there some other way
> to specify that?  Doing this has worked with every other such thing
> I've tried, and it strikes me as remarkably obnoxious for the script to
> think it knows better than I do how the compiler should be run in my
> environment, forcing me to workarounds such as the cc-g script I
> sketched above.  (I notice other examples of this, such as the way it
> maps c[1-9][0-9] to clang with some option, if clang is detected;

that's because clang's c89/c99 wrappers are broken (especially on MacOS)
to the point that they've become unusable.  (I test-compile with c89,
c99, gcc with different levels of warnings, clang and any other compiler
which I have on a given machine).

https://invisible-island.net/personal/lint-tools.html#tool_clang

> fortunately, I'm not trying to use clang, so I can ignore that in
> practice - but there certainly are plenty of ways it could cause the
> build to break when just using what the user told it to would work.)
> 
> But lynx is so sane in so many other respects this quite stands out,
> leading me to ask what's behind it and why the complaint doesn't
> explain either why it's a bad idea to want to specify options on all cc
> runs or what the correct way to do so is.

I do this with all C programs - lynx isn't special in that regard.

-- 
Thomas E. Dickey <dickey@invisible-island.net>
https://invisible-island.net
ftp://ftp.invisible-island.net

signature.asc
Description: PGP signature