Mailing List Archive

--------
In message <4e44b962-fa73-10af-8bea-9aa940438c46@schokola.de>, Nils Goroll writ
es:

>I understand that outer CFLAGS need to be passed to the inner configure for it
>to work, but why should the other configure need pass the CFLAGS it has itself
>determined?

About the only thing I have to contribute here is that I picked the
"distcheck" target because that's what DES told me ten years ago,
and Lasse repeated about five years ago...

If somethinge else makes more sense, I'm all for it.

Keep in mind that we don't actually need all vtest-contributors to run
the same target...

--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

_______________________________________________
varnish-dev mailing list
varnish-dev@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev

> Now for reasons which I do not understand, autoconf seems to create an
> environment where the second (inner) configure called via make distcheck gets
> passed the CFLAGS determined during the first (outer) configure run.

Today I've changed configure.ac and Makefile.am to save the external CFLAGS and
explicitly pass them to the inner configure explicitly (commits
cb00896414ba72c7cc10882c1be7e23dfb796dd3 and
d49afc041773f915e74a82c962063edde3e1d9eb).

This feels like a workaround to me, in particular because CFLAGS is just one of
many relevant environment variables which we touch. IMHO, a good solution would
restore all of the original environment for distcheck.

Any ideas?

Nils

_______________________________________________
varnish-dev mailing list
varnish-dev@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev

--------
In message <a10c3956-6af9-e82b-c7bc-1fa1e03451e6@schokola.de>, Nils Goroll writ
es:

>Any ideas?

Not apart from "get rid of autocrap sooner rather than later".

--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

_______________________________________________
varnish-dev mailing list
varnish-dev@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev

On Thu, Dec 8, 2016 at 10:23 PM, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
> --------
> In message <a10c3956-6af9-e82b-c7bc-1fa1e03451e6@schokola.de>, Nils Goroll writ
> es:
>
>>Any ideas?
>
> Not apart from "get rid of autocrap sooner rather than later".

I had a look at how we manage CFLAGS, including developer flags and
it's a big [1] mess. I have a definite plan on how to clean it up, and
will submit a pull request. There are unfortunately some special cases
that I will leave alone for now. And *then* I can look at Nils' specific
problem.

Now, my main concern is that we append flags to CFLAGS, overriding
presets that should take precedence (passing CFLAGS via the
environment or the configure command line). It may be related to Nils'
problem, but at this point I think not.

As a side note, I ran into E_ANONYMOUS_UNION_DECL (in struct suckaddr)
while building with suncc (in C11 but not C99), didn't get any further
because I realized I haven't had lunch yet. I think it should be ignored
when developer flags are enabled, leaving it to Nils for now.

Cheers,
Dridi

[1] it's a euphemism :p

_______________________________________________
varnish-dev mailing list
varnish-dev@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev

> 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

_______________________________________________
varnish-dev mailing list
varnish-dev@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev

On Fri, Dec 30, 2016 at 5:34 PM, Dridi Boukelmoune <dridi@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

_______________________________________________
varnish-dev mailing list
varnish-dev@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev

--------
In message <CABoVN9DKswgGkEVQ+Jb-HUvx1PNyyPc0o5+nrzZ=R732Q9gBiQ@mail.gmail.com>
, Dridi Boukelmoune writes:

Yes, we are probably poor users of autocrap.

But I don't want to make excuses for that.

We're trying to build 8 small binaries, three static and four dynamic
libraries.

We should not have to even think about build infrastructure *at all*.

*It* *should* *just* *work*.

And that is why I want to get rid of autocrap: It doesn't just work,
not even close.

>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.

Absolutely, and I'd love to have that going in.

The only change I ask is that each of the lib/bin subdirectories
have a trivial makefile along the lines of:

*:
cd ../.. && make $(*)

(no, make(1) doesn't grok that, but you get the idea...


--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

_______________________________________________
varnish-dev mailing list
varnish-dev@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev

On Thu, Jan 19, 2017 at 6:00 PM, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
> --------
> In message <CABoVN9DKswgGkEVQ+Jb-HUvx1PNyyPc0o5+nrzZ=R732Q9gBiQ@mail.gmail.com>
> , Dridi Boukelmoune writes:
>
> Yes, we are probably poor users of autocrap.
>
> But I don't want to make excuses for that.
>
> We're trying to build 8 small binaries, three static and four dynamic
> libraries.
>
> We should not have to even think about build infrastructure *at all*.
>
> *It* *should* *just* *work*.

I'm afraid compilers don't make it easy when it comes to just working
and portability. At least on the dependency management side pkg-config
does a great job (if *.pc files are properly written).

> And that is why I want to get rid of autocrap: It doesn't just work,
> not even close.

There are things from autotools themselves and from the
autoconf-archive that certainly don't just work, or even work.

>>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.
>
> Absolutely, and I'd love to have that going in.

So what's the goal? Are we still getting rid of autocrap?

> The only change I ask is that each of the lib/bin subdirectories
> have a trivial makefile along the lines of:
>
> *:
> cd ../.. && make $(*)
>
> (no, make(1) doesn't grok that, but you get the idea...

Yes, although make's design was very spot on IMO it also lacks many
useful things today. As for myself, I haven't felt the need to cd into
a sub-directory for a long time, so I would no longer hurt from having
a single Makefile.

Dridi

_______________________________________________
varnish-dev mailing list
varnish-dev@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev