Does not build on platforms for which ares_config.h has not been generated

[ortolot]

Hello,

After packaging pycares for Debian, I noticed that it failed to build on some non-Linux platforms, namely GNU/kFreeBSD and GNU/Hurd. While there are by no means priority targets, it is nice to have software that can build on these systems.

The reason for the failure is that setup_cares.py defines no include directory where the compiler would find ares_config.h. And, according to what I found, the reason for that is that the ares_config.h was pre-generated for a couple of platforms that does not include GNU/kFreeBSD and GNU/Hurd (which is not really surprising). :-)

If you generated config.h with an unmodified config.h.in and configure script from c-ares, or if you modified it but still have it, I could add it to the Debian package and use it to generate config.h (with some kind of Debian-specific patch). Ideally, that should rather be shipped with pycares itself, but I think you had a reason to pre-generate these ares_config.h. Perhaps you could ship it but leave it to the user or distro maintainer to re-generate them it they want to?

Regards,

Tanguy

[saghul]

Hi there! Thanks a lot for packaging pycares for Debian! 😍

If you generated config.h with an unmodified config.h.in and configure script from c-ares, or if you modified it but still have it, I could add it to the Debian package and use it to generate config.h (with some kind of Debian-specific patch). Ideally, that should rather be shipped with pycares itself, but I think you had a reason to pre-generate these ares_config.h. Perhaps you could ship it but leave it to the user or distro maintainer to re-generate them it they want to?

Those files were generated so long ago I don't even remember :-S I took them from what Node uses, in order to avoid having to use subprocesses and autotools to build pycares. I wouldn't mind adding them to pycares, but I have no way to test those platforms (nor much time at the moment, TBH). If you have working versions for those feel free to send a PR and I'll include it!

Out of curiosity: how did you get away with packaging it for Debian given I include a bundled and modified c-ares (for good reasons!) ? I thought this was against the policy.

[ortolot]

Saúl Ibarra Corretgé, 2016-09-07 02:21-0700:

Those files were generated so long ago I don't even remember :-S I took them from what Node uses, in order to avoid having to use subprocesses and autotools to build pycares. I wouldn't mind adding them to pycares, but I have no way to test those platforms (nor much time at the moment, TBH). If you have working versions for those feel free to send a PR and I'll include it!

I think I will do that: prepare a change that adds generated versions
for these platforms, plus the files to generate them manually for new
platforms if needed, since it is always better to have all the source.

Out of curiosity: how did you get away with packaging it for Debian given I include a bundled and modified c-ares (for good reasons!) ? I thought this was against the policy.

Bundling an existing library goes against the policy indeed, but you are
not: your c-ares is a fork! Still, you have to take care of updating it
if security flaws are discovered in the original…

Librement,

Tanguy

[ortolot]

Hello,

I have prepared a new version that can compile on OSes for which the
ares_config.h was not pre-generated, and I will soon upload to Debian.

What is does is that it runs the original c-ares configure script, which
I have added as debian add-on, along with all the other files it needs.
This generates ares_config.h, and also other files like a Makefile,
which I just discard.

Since you refresh files from c-ares from time to time anyway, do you
think you could grab the following ones as well (ares_build.h.in
ares_config.h.in config.guess config.sub configure install-sh
libcares.pc.in Makefile.in), and store them in a directory such as
deps/ares/src/config_source? Even if they are not used normally, this
way they would be there for people that want to regenerate
ares_config.h, for instance to add a new OS or to reflect changes to an
existing one.

Regards,

Tanguy

[saghul]

Hi!

The things the configure script figures out are not something that can change with time IIRC, so I'd rather sip the generated files instead, as we do now. On what platforms did you have to regerate the files? Wouldn't it be easier for Debian (or anyone else, for that matter) to not need any extra patches?

[ortolot]

Saúl Ibarra Corretgé, 2016-11-23 01:37-0800:

The things the configure script figures out are not something that can change with time IIRC, so I'd rather sip the generated files instead, as we do now. On what platforms did you have to regerate the files?

Currently, I had to do that for GNU/Hurd on i386, GNU/kFreeBSD on i386 and and GNU/kFreeBSD on amd64. But the same will happen on just every new platform, and by definition we cannot guess what they will be.

Wouldn't it be easier for Debian (or anyone else, for that matter) to not need any extra patches?

Yes, it is better not to use patches, which is why we only patch software when we need to, and in this case, we do, since it does not build without this. Is there a problem with shipping the generated files as you currently do, but in addition, provide the configure scripts and source files as well, for people that could need them? That would minimize the change introduced by Debian to make it work, to just running the configure script. Otherwise, I have no problem keeping the current patch as it is, but I think reducing the way we patch software is always a good thing… Librement,

…

--   __o                   On the road again, again…  _<_\,_   Tanguy         -+- Bernard Lavilliers -+- (_)|'(_)

[saghul]

Closing since there is nothing actionable and a long time has passed. If you still want to ship the config files, please send a PR and I'll take a look!