Re: [Nmh-workers] Having configure Check for cc's -pedantic -ansi.

[David Levine]

Ralph wrote:

> Hi David,
>
> Worked well on a machine where I hadn't built it before, but was likely
> to have some of the optional development packages installed.

Yeah, the script doesn't check those dependencies in advance.  The build
doesn't take very long on modern machines so I think that's OK.  I'll add
a suggestion to check the MACHINES file for dependencies if configure
fails.

> I went with the defaults for all but the first prompt.

I should revisit the OAUTH, TLS, and SASL defaults based on what
configure now does with them.

> I then had to poke around for the log file.  (With my "just paste the
> commands I was told" hat on.)  Perhaps its path can be printed at the
> end?

Added, if any of:  it's not in the current directory (because the
sources were downloaded), the build failed, or -v was used.

> I wouldn't want to email the one here.  tools/showbuildenv captures the
> environment and that has personal information in it, e.g. paths can
> contain real-life data.  I'm wondering how useful env[] is, other than
> for the uname values stuffed in there by showbuildenv.

I replaced the showbuildenv with a few uname's and cat /etc/os-release
if it exists.  Looking at the buildbot hosts now, either that or none
of the files searched for in showbuildenv are used.

> It's a peer to configure, Makefile, etc?  So have it at the top level?

Sounds good to me.  Any objection?

> The `tail -4' output near the end, that has the ===..., has escape codes
> for colour BTW.

Feature!  I added a fix to not do that if TERM is unset or dumb, and
documented that in the comments at the top.

> The second time `sh build_nmh' is run the `git clone' fails because
> ./nmh exists and isn't empty.  The user doesn't know that immediately

Fixed.

> This is due to the new `D' option to ar(1) for deterministic mode.

I don't face this daily (on Fedora), though at least some of the
buildbot hosts do.  Not sure what to do about it.  Excise it from,
or override (assuming POSIX ar), ARFLAGS?

> I've pushed 4ac9784480441d2bebe8a2ad9584165bbf2ee345 to have configure
> edit flex's 2.6.1 output;  it already had logic for fixing earlier
> versions.

Should we remove -Wall -Wextra from CFLAGS and leave all that up to
the user?  Then we could remove the flex dependencies.  I'm tired of
trying to clean up flex's droppings.

> The `tags' target uses etags, not installed here.  It seems that's a
> default and nothing to do with nmh's use of autotools?

Right, and looking quickly, I don't see a way to disable it:

    If any C, C++ or Fortran 77 source code or headers are present,
    then ‘tags’ and ‘TAGS’ rules will be generated for the directory

David