On 14-12-16 16:39, David Sommerseth wrote: > On 14/12/16 10:09, Gert Doering wrote: >> Hi, > >> On Wed, Dec 14, 2016 at 10:51:18AM +0200, Lev Stipakov wrote: >>> +/* + * Disable async-push if plugins are disabled + */ +#if >>> !defined(ENABLE_PLUGIN) && defined(ENABLE_ASYNC_PUSH) +#undef >>> ENABLE_ASYNC_PUSH +#endif + > >> That one gets a NAK from me, for the reasons given. > >> As long as we *have* --enable/--disable options in configure, they >> should be validated *there* and not silently ignored. > >> David's argument about "configure is for finding system dependent >> things and compiler settings" has some merits, but then we should >> get rid of all compile-time --enable/--disable settings. > > By this logic should we enforce users to add --disable-def-auth if > --disable-plugin is set? If so, then we should probably also do > something with --disable-plugin-auth-pam and > --disable-plugin-down-root. And with --disable-plugin-auth-pam, we > need to look at --enable-pam-dlopen as well.
No, unless the user specified --enable-def-auth. And yes, I think it would be nice if we would throw an error if the user did. "Fail-fast" is a really good habit. > And to put things in context of the async-push stuff. In the C code > we already check if --disable-def-auth is enabled or not. > > If we truly start to look into this for the other options, we will > have quite a good job ahead of us. Otherwise we end up with even more > mess where we are not even consistent. Sure, but "The other stuff is broken" is no argument to not add something that is not broken. > I say it again, configure.ac is *NOT* the place to do sanity checks on > which openvpn features depends on each-other. We have not done that > before, and we should not do it now. It just provides far more > non-production code to maintain, and more places to look for issues > when code we expect to to be compiled in isn't being compiled in. > This way leads is a rats nest and will cause much more maintenance > burden in the future, which I will not accept lightly. Yes we do. Just check the mbed TLS pkcs11 checking. That check has saved me some hours of re-running builds at the least. I wish we had more such checks. > Yes, I see the short-term convenience to solve that specific Trac > ticket. But it really isn't the right long-term solution. I respectfully disagree. I believe this *is* the right long-term fix, and we should aim at doing it this way. -Steffan
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
