Re: [Lynx-dev] configure-script issue
Thomas Dickey dixit:
>I created the macro after dealing with users who would put C preprocessor
>options in $CC
I think that, if you even want to detect it, you should only warn for it.
We sell rope so the user can shoot himself into the foot, after all.
> (which for lynx will cause it to not build the configuration
>summary page as expected, for ncurses will cause interesting build failures,
>etc)
Directly inspecting the variables is error-prone anyway. Instead, you
should consider doing it like mksh’s configure script, which first
checks that the compiler works at all; in mksh’s example, this means
it successfully compiles and links…
/* evil apo'stroph in comment test */
#include
int main(void) { int t[2]; return (isatty(pipe(t))); }
… then checks that the compiler/linker fails correctly for… <<-EOF
#include
extern int thiswillneverbedefinedIhope(void);
int main(void) { return (isatty(0) +
#$expr
0
#else
/* force a failure: expr is false */
thiswillneverbedefinedIhope()
#endif
); }
EOF
… where $expr is 'if 0' in the first run, then uses this very
construct to test for the couple of CPPFLAGS that the configury
script needs to know about (e.g. to construct the regression
testsuite caller script’s list of categories to set).
“successfully compiles and links” means that…
| $CC $CFLAGS $Cg $CPPFLAGS $LDFLAGS $NOWARN conftest.c $LIBS
… succeeds and generates one of a.out, a.exe, conftest.exe or
conftest. (Here, $Cg is the configury-added "-g" or "-Og -g3"
or similar, $NOWARN is the empty string while this is being
tested.) For all compilers *except* “msc” it also means that
the errorlevel of the $CC command is 0.
I’ve so far found two compilers that fail it; “dec” may succeed
if adding ${ccpl}-non_shared to CFLAGS (should be LDFLAGS, now
that I see it), “dmc” if adding ${ccpl}/DELEXECUTABLE (where
ccpl is "-Wl," normally but "-Yl," on UWIN and "-Y " on Interix).
“msc” is ifdef _MSC_VER, “dmc” is ifdef __DMC__, “dec” is
if defined(__DECC) || (defined(__osf__) && !defined(__GNUC__)).
For mksh, isatty(3) is a required function; for lynx you’d maybe
use a different one.
> or would load up $CC with optimization/debugging options (similar
That’s the users’ problem.
In mksh/Build.sh I only add default optimisation/debugging options
if, at script entry, the result of doing…
allu=QWERTYUIOPASDFGHJKLZXCVBNM
alll=qwertyuiopasdfghjklzxcvbnm
alln=0123456789
i=`echo :"$orig_CFLAGS" | sed 's/^://' | tr -c -d $alll$allu$alln`
… is $i containing the empty string. (There’s a Build.sh flag to
explicitly enable debugging, which sets $Og (see above) to something
suitable for the compiler detected and adds -DDEBUG to CPPFLAGS, but
that’s orthogonal to this.) I am aware of GNU autotools liking to add
their own "-O2 -g" default flags, which is precisely why mksh’s does
not do that.
>problems, with complaints when it didn't evaluate in the expected order).
The order is somewhat canonical though.
${CPP:-$CC -E} $CPPFLAGS srcfn.c
$CC $CFLAGS $CPPFLAGS -c srcfn.c
$CC $CFLAGS $LDFLAGS -o tgtfn srcfn.o $LIBS
$CC $CFLAGS $CPPFLAGS $LDFLAGS -o tgtfn srcfn.c $LIBS
If $LDSTATIC is passed in (it’s usually either empty or "-static")
it’s folded into LDFLAGS (appended). I’m sure there’s a reason why
CPPFLAGS comes after CFLAGS here, but unless user errors are made
this should not matter.
Note that CPPFLAGS may *correctly* contain surprising (i.e. not -I,
-D, -U) flags, such as -Wdate-time which *is* a preprocessor option.
Having ported things to BSD ports (including autotools/libtool itself
to a BSD) as well as embedded buildsystems (multiple of them) I am
fully aware how difficult a task this is for GNU autotools. That’s why
I’m merely proposing this as a “please think about this”.
>> 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,
Might be useful to replace this with a compile/link-time test for the
brokenness and failing instead (ofc with a suitable message) so the user
knows about it and can fix that, also for other uses of the compiler.
bye,
//mirabilos (fitting .sig this time ☺)
--
11:56⎜«liwakura:#!/bin/mksh» also, i wanted to add mksh to my own distro │
i was disappointed that there is no makefile │ but somehow the Build.sh is
the least painful built system i've ever seen │ honours CC, {CPP,C,LD}FLAGS
properly │ looks cleary like done by someone who knows what they are doing
Re: [Lynx-dev] configure-script issue
>> Specifically, when I run it with CC set to cc -g, [...] > 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... Except it's not just a warning message. The script also insists on prying the options off $CC and putting them elsewhere. > CFLAGS is the proper place for compiler options (standard), > CPPFLAGS is the place for C preprocessor options [...] When I'm trying to turn debugging on, I've run into way too many build systems that will use some setting most of the time but then lose it other times. For example, some build procedures use CFLAGS when compiling .c to .o, but not when linking .o files together into an executable. The most reliable way I've found of getting -g set everywhere is to make it part of $CC. (It is at least somewhat important that the compilers I use ignore -g, rather than erroring out, when doing something for which it's not relevant.) I've even occasinoally run into some that don't provide a way to set CFLAGS, or make it obscure and undocumented enough that they might as well not. >> 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. For routine use, I do too: I have a script, wgcc, that runs gcc with a suitable set of options depending on the particular compiler/version in use. For example, one of the more heavily used of the lists of flags is -Werror -W -Wall -Wpointer-arith -Wcast-qual -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wno-uninitialized -Wno-sign-compare -Wno-missing-field-initializers -Wno-pointer-sign -Wno-format-zero-length. I don't always want -g, but I often do. When I was building that lynx, performance was very much secondary to debuggability. > I do this with all C programs - lynx isn't special in that regard. Then I guess I just haven't had occasion to build much else you maintain. :-) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: [Lynx-dev] configure-script issue
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 https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
