search

tcsh-org / tcsh

This is a read-only mirror of the tcsh code repository.
https://www.tcsh.org/
Other
229 stars 42 forks source link

Lukem/musl sbrk workaround #61

Closed lukem closed 1 year ago

lukem commented 1 year ago

Add a configure check for sbrk(N) working (for N>0), and define HAVE_WORKING_SBRK. Force SYSMALLOC unless HAVE_WORKING_SBRK

Per discussion on the mailing list.

I also did a few style cleanups in configure.ac

Note: I have not committed the result of autoreconf to regenerate aclocal.m4, config.h.in and configure; my build system isn't the same as the last system that was used to regen, and I wanted to reduce the diff skew.

suominen commented 1 year ago

Thanks, @lukem!

I reverted the changes to the quoting style (i.e. `quoted' vs. 'quoted') to avoid having a mixed style. I'm personally not opposed to changing the style, but if it is done, it should be done throughout.

I also reverted the quoting style change around AH_BOTTOM() to avoid empty lines in config.h.in — especially the trailing empty line.

Some of the whitespace changes to configure looked less readable than before, but it is probably next to impossible to have it generated "pretty" anyway.

So I ran autoreconf and committed the resulting changes to configure and config.h.in. If you have a NetBSD system around, you could get the latest autoconf from pkgsrc to get a version that matches.

lukem commented 1 year ago

The `..' quoting changes I made were just in the configure.ac source, which is what I usually edit.

Unfortunately the autoconf upstream macros seem to result in `..' quotes in the generated files such as configure and config.h (or equivalent).

In my own projects I don't mind the discrepancy in the quotes in the generated files given the source configure.ac is easier for me to use. That said, I'm not fussed if you didn't want that part of my change :)

suominen commented 1 year ago

I thought even configure.ac had more cases, but I guess it didn't — instead I must have just noted the generated file content. In the end, though, it feels better to go with the style autoconf is using, so I'll leave it as is for now.

(Maybe the vim syntax highlighting needs fixing? 😄)

lukem commented 1 year ago

Seems reasonable to leave as is.

As for vim; unlikely to change. I speculate that the underlying issue is the complexity of parsing m4, autoconf variant of m4, inline shell, and use of ` ... ' in strings that confuse the parse dealing with balanced sh ` or ' quotes.