Comments on making contrib modules buildable from the main Makefile...
-------- Original Message -------- Subject: Re: --enable-smbk5pwd support Date: Mon, 12 May 2008 08:03:49 +0200 From: manu@netbsd.org (Emmanuel Dreyfus) To: hyc@symas.com (Howard Chu), ando@sys-net.it (Pierangelo Masarati)
Howard Chu hyc@symas.com wrote:
I have a couple reservations about this move. It's got some pretty major external dependencies. Anything that's integrated into the built-in code is expected to be fully autoconf'd, and this would require adding a lot of tests for Kerberos etc. Also, we generally have to provide a test script for any built-in components. And, we'd need to customize the enable switch for it, or something, to toggle KRB5 or Samba support. All in all I hate having to muck further with configure, and adding more tests to it that just slow things down.
Well, we can keep it a contrib thing, without full autoconf support, but help building it a bit. That will make packagers' life easier.
Here is another proposal: add a --enable-contrib-overlays flag, which would add servers/slapd/overlays/contrib.c to the built files. That file would contain something like this:
#ifdef CONTRIB_ADDPARTIAL #include "../../../contrib/slapd-modules/addpartial/addpartial.c" #endif
#ifdef CONTRIB_ALLOP #include "../../../contrib/slapd-modules/allop/allop.c" #endif
#ifdef CONTRIB_SMBK5PWD #include "../../../contrib/slapd-modules/smbk5pwd/smbk5pwd.c" #endif
And so on...
Packagers would just have one patch to that file, to do the right defines and includes required stuff so that it can build on their particular environement. A single patch to a simple file such as this one is much more easier to maintain than multiple patches on configure and Makefiles, which are fast moving targets.
----- "Howard Chu" hyc@symas.com wrote:
Comments on making contrib modules buildable from the main Makefile...
Making them more easily buildable also means they get more exposure, and potentially more impetus for long-term support and integration into the product, which I think is a plus.
--Quanah
#include "../../../contrib/slapd-modules/addpartial/addpartial.c" #include "../../../contrib/slapd-modules/allop/allop.c" #include "../../../contrib/slapd-modules/smbk5pwd/smbk5pwd.c"
Is it just me, or would this make building the modules as dynamic pretty painful?
Basically, if we're trying to get the contribs out into the ecosystem, it needs to be easy to package addpartial.so and allop.so as discrete components. It'd take some serious linker black magic to do that with a single source file.
Aaron Richton wrote:
#include "../../../contrib/slapd-modules/addpartial/addpartial.c" #include "../../../contrib/slapd-modules/allop/allop.c" #include "../../../contrib/slapd-modules/smbk5pwd/smbk5pwd.c"
Is it just me, or would this make building the modules as dynamic pretty painful?
Basically, if we're trying to get the contribs out into the ecosystem, it needs to be easy to package addpartial.so and allop.so as discrete components. It'd take some serious linker black magic to do that with a single source file.
Agreed, the above approach wouldn't be suitable.
Howard Chu hyc@symas.com wrote:
Agreed, the above approach wouldn't be suitable.
Then we need a Makefile in contrib/slapd-modules, and descend in that directory if --enable-contrib-overlays was given to configure.
I can draft a patch if there is a consensus on this approach.
Howard Chu writes:
Well, we can keep it a contrib thing, without full autoconf support, but help building it a bit. That will make packagers' life easier.
How about recursive configure? I think autoconf supports that. ./configure --contrib or --recursive would run contrib/configure, etc. Still needs to add config stuff, but keeps dependencies out of the main configure and doesn't slow it down for people who don't need it.
Hallvard B Furuseth h.b.furuseth@usit.uio.no wrote:
How about recursive configure? I think autoconf supports that. ./configure --contrib or --recursive would run contrib/configure, etc. Still needs to add config stuff, but keeps dependencies out of the main configure and doesn't slow it down for people who don't need it.
Well, the goal was to avoid autoconf hacking...
Emmanuel Dreyfus wrote:
Hallvard B Furusethh.b.furuseth@usit.uio.no wrote:
How about recursive configure? I think autoconf supports that. ./configure --contrib or --recursive would run contrib/configure, etc. Still needs to add config stuff, but keeps dependencies out of the main configure and doesn't slow it down for people who don't need it.
Well, the goal was to avoid autoconf hacking...
Keeping it in a nested configure script would be OK I think. One issue with that is we don't use a config-cache, so settings already detected by the top level script may not automatically propagate to the nested script.
Howard Chu wrote:
Comments on making contrib modules buildable from the main Makefile...
--contrib-enable-blah sounds good. Or a make contrib?
-
Aaron Richton -
Gavin Henry -
Hallvard B Furuseth -
Howard Chu -
manu＠netbsd.org -
Quanah Gibson-Mount