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 _______________________________________________ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers