HN Explorer

Ask HN: Core GNU components (flex, libtool) in dismaintenance

12 points by eqvinox ↗ HN
In some way or another, most of us probably use software built in C with autotools and possibly containing flex/bison parsers. Just straight up GNU coreutils (`ls`!) needs at least the former.

All the more alarming that 2 core ecosystem components have fallen into "dismaintenance":

- Flex [https://github.com/westes/flex] - activity ebbed to almost zero around early 2018; year-old PRs piling up

- Libtool [https://savannah.gnu.org/projects/libtool/] - last release in 2015, sparse commit activity by a lone RedHat person

How could it come to these, and what can we do to address this? And what else might be falling into dismaintenance? (I only noticed these two because I tried submitting patches!)

(For libtool, yes, there are much better build systems nowadays, but it's still in use -automatically pulled in by autoconf/automake- by a huge number of packages; new build systems don't help, but maybe the libtool dependency can be surgically removed from autoconf/automake?)

6 comments

[ 5.6 ms ] story [ 28.0 ms ] thread
ryanmccullagh
I can confirm I have 2 PR's open for westes/flex - It looked to be that it was being maintained. I sent these PR's 2 years ago.
rurban
I'll see what I can do for flex. I already have the GNU perms.

And no, libtools cannot be removed. It's still required for any cross platform tool with shared libs

burfog
We built cross platform tools with shared libs long before libtools existed. Removal would be best.

Flex is OK. It doesn't produce clean warning-free idiomatic C99 (or even C11) source code. The historical defaults, for lex compatibility that isn't needed anymore, are not good.

hrgiger
I am currently digging around build tools, can you give some examples how did you manage your builds without libtools? Currently messing with LFS, its heavily using as far as I understand. Only openssl explained their decision why they didnt choose libtool path[0]

[https://www.openssl.org/docs/faq.html#MISC5] (Why aren't tools like 'autoconf' and 'libtool' or 'cmake' used?)

burfog
Plain old make will work. The older style would have a separate target for each platform that is supported. The newer style is more like how the Linux kernel build system works, with += operators in the Makefile to add options and put things in lists.

Last time I used it, I found libtool to be a real mess. It had shell scripts pretending to be object files. That is simply not acceptable. There were way too many layers of gunk, making it difficult to have good control over what was being created.

rurban
No, removal would be worst. You cannot harm thousands of projects just because you think you won't need it. I'm also annoyed for needing to do libtool -mode=execute gdb..., but that's life. It can be aliased to something shorter maybe.