autoconf madness

[Dridi Boukelmoune]

On Fri, Dec 30, 2016 at 5:34 PM, Dridi Boukelmoune <dridi at varni.sh> wrote:
>> Any ideas?
>
> Not yet, but I started another thread on github [1] so I suggest we
> move the discussion there. As far I'm concerned, I think I'm done
> with Varnish for this year ;)
>
> Cheers
>
> [1] https://github.com/varnishcache/varnish-cache/pull/2174

Just a quick (as in "no, I don't know how to be quick") note on my
non-progress on this issue.

I've been working on #2174 and I made significant progress but I
closed it and stopped all my autotools activities after the recent
loud and clear messages that "autocrap is the next thing to remove".
Not an exact quote, but probably close enough.

I don't care if we switch build systems, but I'm recommending one last
time to stick to autotools. I don't think I'm lost in the bazaar, and
I probably hate dealing with those tools as much as the next guy. But
most of the shit we get from autocrap is caused by ourselves, because
we are poor users on top of complaining (me included until recently
when I increased both my understanding and hatred of this mess).

I used my pet project cashpack as a test bed and managed to get CFLAGS
working with both combinations of old/recent versions of GCC or Clang,
suncc, and even pcc. Just when I thought it wasn't working, it turned
out that actually suncc 12.4 grew the -std and -pedantic flags
(properly rejected with 12.3).

My handling of warnings is very portable and is backed by autoconf.
The results can be seen on the current master [1] where basically I
throw CFLAGS at the compiler and end up only with the ones it
supports. In my case most of the shit I had to cope with was caused by
GCC and Clang being inconsistent back-stabbers. I also never had the
occasion to investigate all the CFLAGS workarounds in Varnish, but I'm
confident I can get rid of most of the cruft.

As a side note, suncc was of great help to better comply with C99.

I keep my `configure.ac` [2] as simple as possible, and even though it
may seem large in addition to `cashpack.m4` bear in mind I'm leaving
space in my code to keep it readable. Because m4 is the worst macro
language I have seen so far. Also my build system does a lot despite
[3] the small size of the project, in hindsight it's not even _that much_
code.

Same offer as last September: I can incrementally look after the build
system but after the recent (multiple) threats on autotools, I'm
putting my autoconf efforts on hold. I otherwise have the means to
test many things by myself thanks to Nils, and I can nudge every once
in a while to get a test done on FreeBSD. And in any case if I break
something on the master branch, `git revert` + angry mails at me
should be enough to fix it.

Also please note that Guillaume once submitted a patch for a
non-recursive automake build, which I think would also help contain
the complexity^Wmadness.

Cheers,
Dridi

[1] https://github.com/Dridi/cashpack/blob/b559be2/m4/cashpack.m4#L94-L137
[2] https://github.com/Dridi/cashpack/blob/b559be2/configure.ac
[3] integration with many tools, plus dependencies for interoperability tests